412350 - unexpected behavior when textarea is in anonymous content

Status: RESOLVED DUPLICATE of bug 296931

(Core :: XBL, defect)

Description

[aaronr]

Attachment: testcase

If I create a binding that contains a html:textarea and the children of the bound node are made the children of the anonymous textarea, I would exprect to see the simple text content of the bound node as the simple text content of the textarea.  I don't see this happening.  In the DOMInspector I see the html:textarea has one child, a text node that contains the simple text, but I don't see the text in the displayed textarea.

Also, if I right click on the displayed textarea I would expect to get the regular context menu for the html:textarea that includes cut/copy/paste, etc on it.  Instead I get the regular page context menu that has back/forward/reload, etc.

Comment 2

[aaronr]

Ok, I see how this is a duplicate as far as the text not showing up.  But what about the context menu piece?  Why would the fact the textarea has anonymous children vs real children have any bearing on why the editor context menu isn't showing up when the right mouse button is clicked over the displayed textarea?

Comment 3

[Boris Zbarsky [:bzbarsky]]

The context menu is put up by the chrome, not by the textarea.  The chrome looks at the event target.  Events get retargeted at anonymous content boundaries.  So it has nothing to do with the fact that the children are anonymous (and in fact in your case the children are _not_ anonymous nodes), but everything to do with the fact that the textarea itself is anonymous.

If that didn't happen, right-clicking on a textarea scrollbar would give you a scrollbar context menu, not a textarea content menu..

It's possible to completely redesign how the context menu works (e.g. start at the originalTarget, walk the parent chain, etc, etc).  But that's not an XBL core bug, for sure.

Comment 4

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

(In reply to comment #3)
> It's possible to completely redesign how the context menu works
'completely' is quite strong word. Walking parent chain is just one loop.
But sure, not an XBL bug, but Firefox chrome.

Comment 5

[Boris Zbarsky [:bzbarsky]]

But you can't walk the flattened tree parent chain from JS (you can barely do it from C++).  So yes, it would need some serious redesign somewhere.

Comment 6

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

(In reply to comment #5)
> But you can't walk the flattened tree parent chain from JS (you can barely do
> it from C++).
Sure you can in chrome.

Comment 7

[Boris Zbarsky [:bzbarsky]]

How, exactly?  Via boxobjects or something?

Comment 8

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

Sorry, your right. Not the full flattened tree, but enough to fix the contextmenu
bug (parent chain of elements in native anonymous content). 

Comment 9

[Boris Zbarsky [:bzbarsky]]

To fix the specific scrollbar thing, perhaps.  But not to fix the general "random widget bound by XBL, what do we do now?" issue.