Bug 44406 – Application Cache crash when a fallback document has a manifest URL

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[K Chandrasekhar Omkar]

Created attachment 65081 [details]
Crash dump on Windows XP. Decompress password "apple"

Summary:
=======
Browser abruptly crashes, and the operating system (Windows 7) identifies it as a non-responsive program. 
Attempted to navigate to a link, namely "Test FALLBACK", in the webpage http://prx3.nokia-boston.com/AppCaching/ac_demo.html,  and the browser atonce crashed. Bug occured upon opening the URL in a tab, along with other sites. Also, reproduced when opening in a single seperate window.

Steps to Reproduce:
==================
1. Open the attached HTML page.
2. Click on the linked named "Test FALLBACK"
3. Disable network connectivity
4. Again, click on "Test FALLBACK"


Expected Results:
================
1. HTML page opens showing a list of steps, 3 images, links to FALLBACK, NETWORK tests. 
2. An error page with http status code 404, is shown.
3. There shouldn't be any network connected to the device/computer
4. A different error page should be shown. It indicates a cached resource specified in the manifest is being used while offline.

Actual Results:
==============
1. HTML page opened fine
2. Browser crashed immediately. Browser window faded to 50% translucent effect. Windows 7 operating system's error collecting window pops up showing the status as error data being collected.

Regression:   NOT APPLICABLE
==========

Notes:
======
1. Operating Systems: Windows 7
2. Bug occurred in the following scenarios
   i. When opening test URL within a tab, with various other webpages in the other tabs.
   ii.When test page is opened in a new browser instance alone, with no other tabs.
3. Intention while testing is to study HTML5-Offline Web Application behavior. While testing support for "FALLBACK", this bug has been observed.

[K Chandrasekhar Omkar]

Created attachment 65082 [details]
Crash dump on Windows 7. Decompress Password: "apple"

[K Chandrasekhar Omkar]

Created attachment 65083 [details]
HTML file used as test content

[K Chandrasekhar Omkar]

Created attachment 65084 [details]
Error screenshot on windows

[Alexey Proskuryakov]

<rdar://problem/8342904>

[Alexey Proskuryakov]

Created attachment 69402 [details]
proposed fix

Note that the test case is wrong - the fallback won't and shouldn't load per the current version of HTML5 spec. The reason is that it has a different manifest, so fallback resource of the main manifest won't be used for navigation.

[Alexey Proskuryakov]

Fixed in <http://trac.webkit.org/changeset/68896>.

> Note that the test case is wrong

I mean, the original one, not the one landed with the fix. But on the other hand, the test is great in that it uncovered this bug!

[K Chandrasekhar Omkar]

Hi Alex,

Thanks for your feedback. 

As per your comment #5, the fallback won't and shouldn't load as per the current version of HTML5 spec. The reason is that it has a different manifest, so fallback resource of the main manifest won't be used for navigation.

I'm sorry, but I couldn't understand two points in your comment #5:
1. How do you term a manifest a "main manifest"?
2. What do the terms "different manifest" and "it" refer to?

Kindly elaborate.

[Alexey Proskuryakov]

Sorry for being overly terse. Here is what's going on.

ac_demo.html has ac_demo.manifest as a manifest, and it lists ac_fallback.html as a fallback. But ac_fallback.html has a different manifest (ac_fallback.manifest).

So, when ac_demo.html is first loaded, a cache group is created, having ac_fallback.html as a fallback for "/". When you navigate to does_not_exist.html, the fallback entry is picked, loaded and parsed. As soon as parsing reaches manifest="ac_fallback.manifest", we mark the fallback entry in cache group associated with ac_demo.manifest as foreign, and restart navigation from scratch.

On the second attempt, fallback isn't used, because it's marked as foreign in cache group associated with ac_demo.manifest

This is all in strict conformance with HTML5, and also matches Firefox behavior. See the first paragraph of HTML5 section 6.6.5 for when cache entries are marked as foreign and navigation is restarted. Also, see step 16 in section 6.5.1 which says that foreign fallback entries aren't used for navigation.

[K Chandrasekhar Omkar]

Thanks a lot for making it more clear, and I agree with you. 

I'm glad for being able to interact with Webkit team.

Regards,
Omkar.