Closed Bug 601405 Opened 14 years ago Closed 10 years ago

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

Categories

(Core :: XBL, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: assertion, testcase)

Attachments

(2 files, 1 obsolete file)

(deleted), application/xhtml+xml
Details
(deleted), text/plain
Details
Attached file testcase (deleted) —
###!!! 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
Attached file stack traces (obsolete) (deleted) —
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...
Component: Style System (CSS) → XBL
QA Contact: style-system → xbl
Why aren't we blocking the getAnonymous* in remote docs?
And making sure offsetParent doesn't return an anonymous element? ;)
> 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?
Could we make marquee's anonymous content native anonymous? That would give security checks.
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.
video controls are native anonymous, AFAIK. Web pages can't access them. Could we do something similar to marquee?
(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.
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.....
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]
Attached file stack traces (deleted) —
Attachment #480446 - Attachment is obsolete: true
I wonder whether Bobby's changes to move XBL to a separate compartment will help with this....
(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.
WFM
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: