1065920 - Modifying data attribute of <object> causes NS_ERROR_UNEXPECTED exception

Status: NEW

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

Description

[Duan Yao]

Attachment: object-modifying-exception.html

User Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20140811030203

Steps to reproduce:

1. create a html/xhtml/xml Document instance from XMLHttpRequest or DOMParser, which contains a <object> element.

2. modify the 'data' attribute of the <object>.

You can load the attachment to reproduce this issue.



Actual results:

A NS_ERROR_UNEXPECTED exception it thrown, though the element is modified as expected.


Expected results:

No exception should be thrown.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Testcase also hits

###!!! ASSERTION: LoadObject called while not bound to an active document: 'Not Reached', file /content/base/src/nsObjectLoadingContent.cpp, line 2034

Comment 2

[Duan Yao]

Attachment: object-embed-modifying-exception.xhtml

test cases for both <embed> and <object>

Comment 3

[Duan Yao]

Modifying 'src' attribute of <embed> has same issue, see the second attachment.

Comment 4

[Boris Zbarsky [:bzbarsky]]

John, can you take a look, please?

Comment 5

[Boris Zbarsky [:bzbarsky]]

In particular, the patch for bug 745030 is what made us propagate the return value of LoadObject to SetAttr callers.  That change looks wrong to me, and directly leads to this exception.

Comment 6

[John Schoenick [:johns]]

(In reply to Boris Zbarsky [:bz] from comment #5)
> In particular, the patch for bug 745030 is what made us propagate the return
> value of LoadObject to SetAttr callers.  That change looks wrong to me, and
> directly leads to this exception.

Yeah I'm not sure why that was done -- I don't think I was considering that SetAttr failures would propagate to content, and LoadObject shouldn't fail. The assertion is similarly bogus -- I it's meant to be checking that the owning document is active, not that it is bound to an active document.

Comment 7

[User Dderss]

I have a disasterously long start-up time and slow operation in current Beta, Mozilla 36. It pop-ups window how script "chrome://global/content/bindings/browser.xml" or "chrome://global/content/bindings/browser.xml" at certain random lines is hung and asks whether I wish to stop it or continue. 

(I never can determine actual string where the hung happens since those files are dynamic and by the time I open them the lines that were pointed during error message already make no sense, leading to "}" or to a commented lines.)

Then I see the following error in the browser console:

Exception { message: "", result: 2147549183, name: "NS_ERROR_UNEXPECTED", filename: "resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/highlighter.js", lineNumber: 454, columnNumber: 0, inner: null, data: null, stack: "CanvasFrameAnonymousContentHelper.prototype._insert@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/highlighter.js:454:22
CanvasFrameAnonymousContentHelper.prototype._onNavigate@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/highlighter.js:460:6
emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/event/core.js:97:8
TabActor.prototype._navigate@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1462:0
DebuggerProgressListener.prototype.onStateChange<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:2144:6
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:13
ContentRestoreInternal.prototype.restoreHistory@resource://app/modules/sessionstore/ContentRestore.jsm:130:4
MessageListener.receiveMessage@chrome://browser/content/content-sessionStore.js:129:8
", location: XPCWrappedNative_NoHelper }

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment 7 seems to have nothing to do with this bug.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.