676051 - ApplicationCache - doesn't pick the "most appropriate" cache when there are multiple candidates

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Gert]

Remark: this bug also existed in Google Chrome and was fixed there in M12: http://code.google.com/p/chromium/issues/detail?id=68479; note that the Firefox bug report below uses URLs that are different from the Google Chrome bug report.


Reproduceable with Firefox version 6 beta 4.

To reproduce:
1. Open http://dictionarymid.sourceforge.net/WebApp/playground/dictionaries/step1url
2. Accept loading to application cache and wait for application cache to be loaded (min approx. 30 seconds)
3. Open http://dictionarymid.sourceforge.net/WebApp/playground/dictionaries/step3url

On step 3 the following exception is thrown:
Exception bei XMLHttpRequest.send: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://dictionarymid.sourceforge.net/WebApp/playground/Apps/translationlayergwt/0DFD596AF51F4CC7A00293FBD296E92A.cache.html :: readFileJS :: line 1956"  data: no]


Expected behaviour on step 3: The URL from step 3 is correctly loaded, no error occurs.


Additional information:
a) step1url and step3url refer to web apps with different data files (c1,d1 below), but the same html/js files (c2,d2,c3,d3 below).
b) The js files are largely GWT generated code (Google Web Toolkit)
c) The step1url "application cache" comprises: 
	c1) files from the step1url directory
	c2) files from the directory '../../Apps/translationlayergwt' (the GWT files)
        c3) files from the directory '../../Apps/mini_hmi'
d) The step3url "application cache" comprises: 
	d1) files from the step3url directory
	d2) files from the directory '../../Apps/translationlayergwt' (the GWT files)
        d3) files from the directory '../../Apps/mini_hmi'

	Important note: c2 and d2 are the identical files. Also c3 and d3 are identical files.

e) On opening, step1url reads per XMLHttpRequestSend the file 
	step1url/dictionary/DictionaryForMIDs.properties [part of c1]
e) On opening, step3url reads per XMLHttpRequestSend the file 
	step3url/dictionary/DictionaryForMIDs.properties [part of d1] -> here the exception occurs

From the Google Chrome bug report, I assume that also Firefox does pick the files from the wrong application cache.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110802 Firefox/8.0a1 ID:20110802030845 too.

Against Firefox 6 I got a one-time & non-reproducible Crash when testing:
bp-b9adbb62-a48a-4ca3-a4f7-a426c2110802
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsTArray<nsHttpHeaderArray::nsEntry,nsTArrayDefaultAllocator>::IndexOf<nsHttpAtom,nsHttpHeaderArray::nsEntry::MatchHeader>(nsHttpAtom const&,unsigned int,nsHttpHeaderArray::nsEntry::MatchHeader const&) 	obj-firefox/dist/include/nsTArray.h:529
1 	xul.dll 	nsHttpChannel::AddCacheEntryHeaders(nsICacheEntryDescriptor*) 	netwerk/protocol/http/nsHttpChannel.cpp:3067
2 	xul.dll 	xul.dll@0xe0293f

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

Still confirmed against Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110912 Firefox/9.0a1 ID:20110912030829 => NEW.

Comment 3

[Gert]

Gentlemen,

I just checked with Firefox 11.0, and the problem still exists there.

Best regards,
Gert

Comment 4

[Patrick McManus [:mcmanus]]

appcache is going away