[Webkit-unassigned] [Bug 60598] New: HTML5 Application Cache Update Failures on Page Refresh

Tue May 10 16:58:00 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=60598

           Summary: HTML5 Application Cache Update Failures on Page
                    Refresh
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
               URL: http://ogw.watercooler-inc.com
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Critical
          Priority: P1
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: ariedel at ariedel.org

Summary:

We have been able to reproduce various different HTML5 application/offline cache update bugs when a page is refreshed during a cache update. If a cache update is interrupted by refreshing the page midstream, expected cache events are not fired making it impossible to tell if files are actually being cached and making the use of event monitoring for things like cache update progress unreliable.

--------------------------------------------------

Expected Result:

If a cache update is interrupted midstream, a complete new cache update sequence should occur:

CHECKING
DOWNLOAD
PROGRESS
.........
CACHED

--------------------------------------------------

Observed Results:

Different results occur on Firefox desktop, Safari desktop, and Safari mobile. Tests were performed at  http://ogw.watercooler-inc.com using Firefox 4.0 (desktop) and Safari 5.0.5 (6533.21.1) (desktop).

Our index page includes a standard manifest attribute to enable offline caching:

<html manifest="/cache.manifest">

This initiates an offline cache update and so long as the update is not interrupted by refreshing the browser page, we receive JavaScript events from the application cache in the expected order: CHECKING, DOWNLOAD, PROGRESS, ......, PROGRESS, CACHED.

Firefox (Desktop)
-----------------------

On Firefox, there is a continuation of PROGRESS events for each file that had not been cached yet. For example, if 20 files were specified in the manifest and the page is refreshed after the 8th PROGRESS event is fired, 12 more PROGRESS events will be fired after the refresh. But, there is no initial CHECKING event after the refresh and there is no completing CACHED or UPDATEREADY event after the final PROGRESS event. If another page refresh is performed after this final PROGRESS event, the expected CHECKING and NOUPDATE events are fired.

Here is a view of the sequence of events:

[INITIAL PAGE LOAD]

CHECKING
DOWNLOADING
PROGRESS (8 times)

[REFRESH PAGE]

PROGRESS (12 times)
[END OF EVENT ACTIVITY]

[REFRESH PAGE AGAIN]

CHECKING
NOUPDATE
[END OF EVENT ACTIVITY]

Safari (Desktop)
----------------------

On Safari, things are worse. If the page is refreshed during the cache update, only a CHECKING event and a DOWNLOAD event are fired and then no additional activity occurs. Additional reloads of the page will yield the same result of only a CHECKING and DOWNLOAD event and nothing else. The only way to actually update the cache a this point seems to be to restart Safari. Upon restart, the complete sequence of regular expected events will occur: CHECKING, DOWNLOAD, PROGRESS, ......, PROGRESS, CACHED.

Here is a view of the sequence of events:

[INITIAL PAGE LOAD]

CHECKING
DOWNLOADING
PROGRESS (8 times)

[REFRESH PAGE]

CHECKING
DOWNLOADING
[END OF EVENT ACTIVITY]

[REFRESH PAGE AGAIN]

CHECKING
DOWNLOADING
[END OF EVENT ACTIVITY]

[RESTART SAFARI]
CHECKING
DOWNLOADING
PROGRESS
......
CACHED

-- 
Andy Riedel
Vice President, Mobile
Kabam, Inc.
(650) 784-9575
ariedel at kabam.com

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.