Closed
Bug 569012
Opened 14 years ago
Closed 5 years ago
"ASSERTION: Not an element?" with nested XBL, contentEditable
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: assertion, testcase, Whiteboard: DUPEME)
Attachments
(2 files)
Steps:
1. Set layout.debug.enable_data_xbl to true
2. Load the testcase
3. Open a new tab in front of it (Cmd+T)
Result: about 30% of loads trigger
###!!! ASSERTION: Not an element?: 'IsElement()', file ../../dist/include/mozilla/dom/Element.h, line 60
|
Reporter | |
Comment 1•14 years ago
|
||
|
||
Comment 2•14 years ago
|
||
nsCSSFrameConstructor::GetInsertionPrevSibling ends up with a textnode as |container|.
And the reason that happens is that the aParentFrame passed to GetInsertionPrevSibling is an nsTextFrame. And that happens because the GetInsertionPoint on the binding manager returns a textnode. And that happens because someone changed the anonymous content and XBL can't actually deal with that (we have bugs on this). Which is why we need to stop exposing XBL anonymous content to untrusted script.
Whatever editor stuff is going on here is purely incidental.
Component: Editor → XBL
QA Contact: editor → xbl
Whiteboard: DUPEME
|
|
||
Comment 3•14 years ago
|
||
I suppose we could just bail out if GetInsertionPoint returns a non-element....
|
|
||
Comment 4•5 years ago
|
||
XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•