495078 - Crash [@ NS_GetInnermostURI] with manifest attribute in file as child frame of chrome document

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Martijn Wargers (dead)]

Attachment: iframe document

When opening the upcoming file under a chrome url, Mozilla crashes.

http://crash-stats.mozilla.com/report/index/e1132097-01f7-4de7-8006-ca91c2090526?p=1
0  	xul.dll  	NS_GetInnermostURI  	 obj-firefox/dist/include/nsNetUtil.h:1428
1 	xul.dll 	nsOfflineCacheUpdateService::OfflineAppAllowedForURI 	uriloader/prefetch/nsOfflineCacheUpdate.cpp:2642
2 	xul.dll 	nsOfflineCacheUpdateService::OfflineAppAllowed 	uriloader/prefetch/nsOfflineCacheUpdate.cpp:2632
3 	xul.dll 	nsContentUtils::OfflineAppAllowed 	content/base/src/nsContentUtils.cpp:853
4 	xul.dll 	xul.dll@0x392f27 	
5 		@0x58003f

Comment 1

[Martijn Wargers (dead)]

Attachment: parentframe (open this one under chrome to crash)

Comment 2

[Martijn Wargers (dead)]

Attachment: test extension that creates a chrome directory under c:\\testfiles

This is a test extension that makes of C:\testfiles\ a chrome directory.
Put the files that I attached previously in that directoy and then go to: chrome://test/content/parentframe.htm to see the crash

Comment 3

[timeless]

Attachment: patch

Comment 4

[Boris Zbarsky [:bzbarsky]]

Why is aURI null there to start with?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Need a regression window and confirmation that this happens on branch.

Martijn, did you just find this or is it happening in the wild?

Comment 6

[timeless]

because the caller was passed the system principal and got its uri (null).

offline apis should not be available for code w/ the system principal, so it's correct for OfflineAppAllowed to chain the system principal's null uri to OfflineAppAllowedForURI and return false. As both are public apis and this isn't a critical path, there's no reason to have an additional check in OfflineAppAllowed.

beltzner: you don't need a regression window, i've marked the bug that introduced this code as a dependency it landed before we branched for 1.9.1 (see the bug 459822 comment 6).

Comment 7

[Martijn Wargers (dead)]

(In reply to comment #6)
> offline apis should not be available for code w/ the system principal, so it's

Why not? I was hoping I could use the offline apis from the local file system or at least from chrome, but both seem impossible.

Comment 8

[Honza Bambas (:mayhemer)]

"offline apis" for you means the offline cache defined by a cache manifest you refer with the manifest attribute? I don't see a reason to cache this way stuff on local disk (files and chrome). It just copies the files to the cache. Intention for the offline cache is to allow code and content (not data!) be run/accessible when you are offline from internet connection. chrome and files are accessible in such a situation w/o an offline caching.

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not blocking -- we shouldn't crash here, but it's uncommon and can be documented until we have some defense in place.  Fine to take for 3.5.1 if it's ready.

Comment 10

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/97c9c02d9694