Closed Bug 837863 Opened 12 years ago Closed 12 years ago

"ASSERTION: Native should be the target!" with onerror, modified __proto__

Categories

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

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: assertion, testcase)

Attachments

(2 files)

Attached file testcase (deleted) —
###!!! ASSERTION: Native should be the target!: 'native == targetSupp', file dom/base/nsJSEnvironment.cpp, line 1472
Attached file stack (deleted) —
Hmm. "native" is an nsHTMLSharedElement (<head>). "targetSupp" is a mozilla::dom::HTMLSpanElement. When we call nsGenericHTMLElement::GetOnerror, "this" is the <span>, as expected. But in nsJSContext::JSObjectFromInterface we do this: 1468 nsCOMPtr<nsISupports> targetSupp = do_QueryInterface(aTarget); 1469 nsCOMPtr<nsISupports> native = 1470 nsContentUtils::XPConnect()->GetNativeOfWrapper(mContext, 1471 JSVAL_TO_OBJECT(v)); 1472 NS_ASSERTION(native == targetSupp, "Native should be the target!"); and the "native" ends up being the <head>, because <head> is on XPConnect bindings but <span> is not anymore, and GetNativeOfWrapper walks up the proto chain. Note that in this case v.toObject().getClass()->name is "HTMLSpanElement", so we have the right object and everything. At first glance, this assert is just bogus now. Bobby, Peter, what do you think?
And and for those who may not want to load the testcase, the important part is: var j = document.createElement("span"); j.__proto__ = document.createElement("head");
(In reply to Boris Zbarsky (:bz) from comment #2) > and the "native" ends up being the <head>, because <head> is on XPConnect > bindings but <span> is not anymore, and GetNativeOfWrapper walks up the > proto chain. Thankfully, that behavior is very close to going away, and will go away in bug 658909, at which point this assertion should be valid again.
Depends on: 658909
Will it be valid? After that bug I assume GetNativeOfWrapper will return null in this case, no?
Flags: needinfo?(bobbyholley+bmo)
(In reply to Boris Zbarsky (:bz) from comment #5) > Will it be valid? After that bug I assume GetNativeOfWrapper will return > null in this case, no? Hm, why would it return null? We have a native <span> element whose proto has been munged to point to a <head> element, right? As soon as we stop doing the wacky proto climbing behavior, we should just get the <span> native here, right? Or maybe I'm missing something?
Flags: needinfo?(bobbyholley+bmo)
Oh, GetNativeOfWrapper knows about WebIDL objects? OK. So what do we do in the meantime? Seems like this assert is interfering with fuzzing, so we should disable it until that bug lands or something...
Or alternately reorder GetNativeOfWrapper to check for WebIDL objects first?
Flags: needinfo?(bobbyholley+bmo)
(In reply to Boris Zbarsky (:bz) from comment #8) > Or alternately reorder GetNativeOfWrapper to check for WebIDL objects first? This might be more sane, but I'd marginally prefer to avoid munging this stuff until I land. Let's just disable or annotate the assert for now if it's causing problems?
Flags: needinfo?(bobbyholley+bmo)
Jesse, which works better for you?
Flags: needinfo?(jruderman)
This assertion isn't especially interfering with fuzzing. It's non-fatal, so I can just ignore it until this bug is fixed.
Flags: needinfo?(jruderman)
WFM on mozilla-central. (Fix by bug 658909?)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: