Bug 49292 – ApplicationCache - network namespace should take precedence over the fallback namespace.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Michael Nordman]

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel

See 6.6.6 Changes to the networking model, step 3
So URLs that fall into an online whitelist should not be subject to fallback'ing.

There are also some comments about relative priorities in section 6.6.3.3 Parsing cache manifests

<snip>
"If a resource is listed in the explicit section or as a fallback entry in the fallback section, the resource will always be taken from the cache, regardless of any other matching entries in the fallback namespaces or online whitelist namespaces.

When a fallback namespace and an online whitelist namespace overlap, the online whitelist namespace has priority.

The online whitelist wildcard flag is applied last, only for URLs that match neither the online whitelist namespace nor the fallback namespace and that are not listed in the explicit section."
</snip>


Although it looks like section 6.5.1 Navigating across documents, step 17 doesn't reflect those priorities. That omission feels like an oversight. For consistency i think the same priorities should be applied to main resource loads.

[Michael Nordman]

Chrome and Firefox 3.6 have the same bug so i suspect this was a (more) recent spec change.

[Alexey Proskuryakov]

Interesting. I guess we should find out if there was a good reason for spec change then.

[Michael Nordman]

(In reply to comment #2)
> Interesting. I guess we should find out if there was a good reason for spec change then.

The change seems like a good one. Developers are asking for this change.

One example... it allows a broad fallback namespace to be created with smaller holes in it for use with XHRs that should never be satisfied from the cache.

[Alexey Proskuryakov]

Yes, I agree with that. But can you find a public-html e-mail announcing the change?

[Michael Nordman]

(In reply to comment #4)
> Yes, I agree with that. But can you find a public-html e-mail announcing the change?

Ha... change history... good luck :)

There was a brief discussion of the relative priorities over a year ago.
http://www.mail-archive.com/[e-mail]/msg18212.html

I didn't see any notice of the change either.

[Alexey Proskuryakov]

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/023635.html

[Michael Nordman]

> 6.5.1 Navigating across documents, step 17 doesn't reflect those priorities

Mail has been sent to the whatwg list about the discrepancy between main vs sub resource loading.

[Michael Nordman]

Created attachment 73644 [details]
deflake

[Michael Nordman]

(In reply to comment #8)
> Created an attachment (id=73644) [details]
> deflake

ooops... i attached this patch to the wrong bug :(

[Michael Nordman]

Created attachment 74167 [details]
layoutTestOnly

This is just the layout test. The logic in webcore is not yet updated to handle this case so it shouldn't be committed just yet.  There's a chromium code change out for review that this test applies to... http://codereview.chromium.org/4807001/

Not sure of the best way to handle this patch with just the test? 

I guess we have a couple of options...

1. Wait until webcore implements this behavior too.
2. Put it in the appropriate skip lists until webcore implements this behavior.

[Alexey Proskuryakov]

>1. Wait until webcore implements this behavior too.

I believe it is a responsibility of whichever port decides to fork webkit.org sources to bring such improvements back to trunk. That's a precondition for accepting fork support code into webkit.org repository - and we have a massive amount of fork support code for application cache.

[Alexey Proskuryakov]

I've been alarmed by the word "wait", but I'm not actually sure if your intention is to work on both sides of the fix.

[Alexey Proskuryakov]

The test looks great, except for svn nits - please add newlines, and remove the executable bit.

\ No newline at end of file

___________________________________________________________________
Added: svn:executable
   + *

[Michael Nordman]

Created attachment 74173 [details]
layoutTestOnly

Fixed the svn-props (why did cygwin's svn do that) and the line endings. Also fixed up a couple of references to file names to match the actual file names.

(In reply to comment #12)
> I've been alarmed by the word "wait", but I'm not actually sure if your intention is to work on both sides of the fix.

About who does the webcore fix, its probably either you or me. I'm out for the next couple of weeks, so the soonest i could get to it would be then.

[Michael Nordman]

Created attachment 74174 [details]
layoutTestOnly

actually with the newline added this time

[Alexey Proskuryakov]

Comment on attachment 74174 [details]
layoutTestOnly

Looks good. I don't think there's a good reason to land this before code fixes land.

[Michael Nordman]

fyi: chromium change is landed
http://src.chromium.org/viewvc/chrome?view=rev&revision=66731

[Eric Seidel (no email)]

I've certainly landed failing tests before the fix. :)  Makes the fix more dramatic!

Unclear what the current state of this bug is...

[Alexey Proskuryakov]

I'm assuming that Michael will fix WebCore side - please do tell if that's a wrong assumption.

[Eric Seidel (no email)]

Attachment 74174 [details] was posted by a committer and has review+, assigning to Michael Nordman for commit.

[Michael Nordman]

Created attachment 84165 [details]
codeChange&layoutTest

[WebKit Commit Bot]

Comment on attachment 84165 [details]
codeChange&layoutTest

Clearing flags on attachment: 84165

Committed r80036: <http://trac.webkit.org/changeset/80036>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/80036 might have broken Leopard Intel Release (Build) and SnowLeopard Intel Release (Build)