569012 - "ASSERTION: Not an element?" with nested XBL, contentEditable

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Jesse Ruderman]

Attachment: testcase (see steps in comment 0)

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

Comment 1

[Jesse Ruderman]

Attachment: stack trace for the assertion

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I suppose we could just bail out if GetInsertionPoint returns a non-element....

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.