[whatwg] [ApplicationCache] Clarify When Events Fire

Wed Dec 16 12:30:50 PST 2009

I'd like some clarification on exactly when the ApplicationCache events should fire.  Specifically the events that are likely to fire early, such as the "checking" or "downloading" events.

In "6.9.4 Downloading or updating an application cache", the specification currently says the following for the "checking" event (step 4):
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#dfnReturnLink-0

[[
  If these steps were invoked with a cache host, and the status of
  cache group is checking or downloading, then queue a task to fire
  a simple event named checking that is cancelable at the
  ApplicationCache singleton of that cache host. ...
]]

What should the proper behavior be in the following scenario:

  <!DOCTYPE html>
  <html manifest="appcache.manifest">
  <head>
    <title>Application Cache Bug</title>
    <script src="EXTERNAL_SCRIPT" type="text/javascript"></script>
    <script type="text/javascript">
      window.applicationCache.onchecking = function() {
        alert('checking');
      }
    </script>
  </head>
  <body>
    <h1>You should get an alert on reloads!</h1>
  </body>
  </html>

Firefox triggers the alert.
WebKit does not trigger the alert.

There is an open WebKit bug on this topic [1] which describes the thought process behind WebKit's behavior. Taken from the comments:

  1) As soon as body manifest attribute is processed, application
  cache update begins, and a zero-timer task to dispatch a checking
  event is posted for later execution.
  2) <script src="EXTERNAL_SCRIPT"> begins to load, blocking the inline
  script below that sets applicationCache.onchecking.
  3) While EXTERNAL_SCRIPT is being requested, the task from step 1
  fires, and the checking event gets dispatched, even though there is
  no listener set for it yet.
  4) Loading finally finishes with a failure, so main document parsing
  resumes. Onchecking listener gets set, but it's too late now.

I can see both interpretations as valid. As a developer, I prefer Firefox's implementation, because that would allow me put my applicationCache handlers inside an external script and still be sure that the handlers work properly. Otherwise, with WebKit's interpretation, it seems I am forced to use an inline script to ensure the main event thread doesn't fire the events before my handlers are added.

Can someone from Mozilla comment on how Firefox's implementation handles this?  It seems it defers Offline events until the <body> element is reached (I did a search and found nsGlobalWindow::FireOfflineStatusEvent). It looks like many of Firefox's tests depend on this type of behavior.

Thanks,
Joseph Pecoraro

[1]: https://bugs.webkit.org/show_bug.cgi?id=29690