408049 - Exception... "Component returned failure code: 0x805e000a [nsIDOMHTMLIFrameElement.src]

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Carsten Book [:Tomcat]]

Error: uncaught exception: [Exception... "Component returned failure code: 0x805e000a [nsIDOMHTMLIFrameElement.src]"  nsresult: "0x805e000a (<unknown>)"  location: "JS frame :: http://www.amazon.com/ :: <TOP_LEVEL> :: line 1845"  data: no]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

happen while loading amazon.com

Comment 1

[Wladimir Palant]

0x805e000a is NS_ERROR_CONTENT_BLOCKED, this exception generally occurs when a script tries to set iframe.src or window.location.href and that action is vetoed by a content policy (probably Adblock Plus in this particular case). IMO this behavior is wrong, frames blocked by content policies should behave exactly like frames that failed to load - the script should be allowed to continue without exceptions, instead an "error" event should be dispatched asynchronously.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So...  we currently treat security errors when setting .src by throwing as well, do we not?  Or errors creating a URI object, etc.  Why is this error code special?

Also, would the error want to be eaten inside docshell, or in the code that calls into docshell?  That is, should chrome that tries to do a load via nsIWebNavigation that is blocked by content policy be able to find out that this happened?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, and there would be no error event fired in any case; this is either an exception or a no-op from our point of view...

Comment 4

[Wladimir Palant]

The difference is that security errors are expected - a page trying to load file:/// expects to fail. Web pages rarely expect content policies however, if that one throws an exception it tends to break the web page (which is not reproducible for the web developers since those don't have the right configuration).

And - yes, it seems that you are right and nsIWebNavigation should continue to throw this error. This means that only the relevant callers should be changed: nsLocation::SetURI(), nsSHistory::InitiateLoad(), nsFrameLoader::ReallyStartLoading().

Comment 5

[Boris Zbarsky [:bzbarsky]]

I can't say I'm exactly happy scattering content-policy-specific nsresult checks through all those....  What about img.src, etc, etc?

I honestly think the design of content policy as using error codes (which become exceptions) to indicate load not allowed is not compatible with the way it's being used in practice (supposedly in a way that's "transparent" to the web page).

Comment 6

[Wladimir Palant]

img.src doesn't throw exceptions, neither do any other content policy invocations. This problem is limited to frames.

Comment 7

[Marcia Knous [:marcia]]

I just hit this error today when visiting a site: Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMHTMLIFrameElement.src]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: http://www.webmonkey.com/com.amg.condenet.webmonkey.ratings.WebmonkeyWidget/com.amg.condenet.webmonkey.ratings.WebmonkeyWidget.nocache.js :: maybeInjectFrame :: line 237"  data: no]

Comment 8

[Boris Zbarsky [:bzbarsky]]

Marcia, that sounds like a different issue (different error code in particular).

Wladimir, this is on my list to look at sometime, but it's certainly going to be several weeks.  If someone else produces a patch before then, I'd be happy to review....

Comment 9

[Wladimir Palant]

Setting frame.src no longer causes synchronous exceptions for blocked URLs in Firefox 49, I think this behavior changed because of E10S.