[whatwg] Appcache feedback

Thu Dec 17 13:44:01 PST 2009

On Fri, 4 Dec 2009, Alexey Proskuryakov wrote:
>
> Recently, a new step was prepended to the application cache update 
> algorithm:
> 
> "1. Optionally, wait until the permission to start the application cache 
> download process has been obtained from the user and until the user 
> agent is confident that the network is available. This could include 
> doing nothing until the user explicitly opts-in to caching the site, or 
> could involve prompting the user for permission. The algorithm might 
> never get past this point. (This step is particularly intended to be 
> used by user agents running on severely space-constrained devices or in 
> highly privacy-sensitive environments)."
> 
> It's not clear if it's supposed to synchronous or not. The "doing 
> nothing" clause suggests that page loading can continue normally. On the 
> other hand, the algorithm says that asynchronous processing only begins 
> after step 2, which runs "atomically".

The application cache download process is always run in the background, 
not synchronously. (Well, step 2 runs synchronously relative to other 
invocations of the algorithm, but that's all.) I've tried to clarify the 
spec on this point.

On Fri, 4 Dec 2009, Michael Nordman wrote:
>
> My interpretation of this is that "atomically" is not to be read as 
> "synchronously" with regard to <html> tag parsing (which ultimately 
> initiates the update algorithm). Otherwise step 1 could leave a blank 
> page on the screen indefinitely (which is not the intent afaict).

Indeed.

(Note that step 2's reference to asynchronicity is not normative -- it's 
just restating requirements that are given elsewhere.)

On Wed, 16 Dec 2009, Joseph Pecoraro wrote:
>
> 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>

It depends on the network and on how much parsing the browser does per 
parser "task".

> 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.

This is one of several conforming sequence of events.

> 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.

You actually can't guarantee that you'll get them even then. Another 
conforming sequence of events would be:

1. The parser's first parsing task begins.

2. As soon as the manifest="" attribute is parsed, the application cache 
download process begins. It queues a task to dispatch the 'checking' 
event.

3. The parser's first parsing task ends.

4. The event loop spins, and runs the next task, which is the 'checking' 
event. No scripts have yet run, so no handlers are registered. Nothing 
happens.

5. The parser's second parsing task begins. It will parse the script, etc.

You can work around all this by checking the .status attribute when you 
first hook up the event listeners.

We could delay the application cache download process so that it doesn't 
start until after the 'load' event has fired. Does anyone have an opinion 
on this?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'