601405 - "ASSERTION: Must have parent here" with <marquee> root

Status: RESOLVED WORKSFORME

(Core :: XBL, defect)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: Must have parent here: 'aContent->GetParent()', file layout/base/nsCSSFrameConstructor.cpp, line 4545

###!!! ASSERTION: Have parent context and shouldn't: 'Error', file layout/base/nsFrameManager.cpp, line 624

Comment 1

[Jesse Ruderman]

Attachment: stack traces

Comment 2

[Boris Zbarsky [:bzbarsky]]

XBL is getting totally confused about its child lists and claiming that the <span id="s"> is still in the child list of the <div>, so we're trying to construct frames for it...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Why aren't we blocking the getAnonymous* in remote docs?

Comment 4

[Jesse Ruderman]

And making sure offsetParent doesn't return an anonymous element? ;)

Comment 5

[Boris Zbarsky [:bzbarsky]]

> And making sure offsetParent doesn't return an anonymous element? ;)

<sigh>.

We really need to have a security check here somewhere, we really do.  Or not implementing <marquee> with XBL.  This was why we forbid any xul on the web, right?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Could we make marquee's anonymous content native anonymous?
That would give security checks.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We can't yet break getAnonymous* for remote content without breaking at least video controls, possibly also XBL.

We'd have to do a lot of rewrite to fix it, more than I suspect we'll have time for in the FF4 time frame.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

video controls are native anonymous, AFAIK. Web pages can't access them.
Could we do something similar to marquee?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to comment #8)
> video controls are native anonymous, AFAIK. Web pages can't access them.

Yes, but that doesn't mean we can break getAnonymous* for <video>. Though if the contents is native anon, then I guess the calling code must be chrome code already, which might mean that we can make getAnonymous* restricted to chrome...

> Could we do something similar to marquee?

I don't know. One difference is that the webpage contents is rendered inside the <marquee>. Though from a DOM point of view they are not descendants of the binding contents, so it might be doable.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Video controls are native anon with XBL bound to the native anon nodes.

Marquee uses the XBL to do stuff to the marquee's kids.  We could put them in a native anon kid of marquee, but then we'd need to actually have those nodes look like they were kids of the native anon kid or something.....

Comment 11

[Jesse Ruderman]

Now triggers more assertions and a crash:

###!!! ASSERTION: Must have parent here: 'aContent->GetParent()', file layout/base/nsCSSFrameConstructor.cpp, line 4523

###!!! ASSERTION: This will end badly!: 'IsInDoc()', file nsIContent.h, line 866

###!!! ASSERTION: Losing track of existing primary frame: '!aFrame || !mPrimaryFrame || aFrame == mPrimaryFrame', file nsIContent.h, line 868

###!!! ASSERTION: Have parent context and shouldn't: 'Error', file layout/base/nsFrameManager.cpp, line 641

###!!! ASSERTION: Unexpected document; this will lead to incorrect behavior!: 'aElement->GetCurrentDoc() == Document()', file layout/base/RestyleTracker.cpp, line 291

Crash [@ nsStyleSet::ReparentStyleContext]

Comment 12

[Jesse Ruderman]

Attachment: stack traces

Comment 13

[Boris Zbarsky [:bzbarsky]]

I wonder whether Bobby's changes to move XBL to a separate compartment will help with this....

Comment 14

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky (:bz) from comment #13)
> I wonder whether Bobby's changes to move XBL to a separate compartment will
> help with this....

I hope so.

Comment 15

[Jesse Ruderman]

WFM