240187 - [unprivileged xul] textbox - copy, paste, cut, undo from context menu broken

Status: RESOLVED DUPLICATE of bug 228767

(Core :: XUL, defect)

Description

[Bill Dimm]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316

In an XUL program containing a <textbox>, the context menu items (from right
clicking within the textbox) largely don't work (even though they work fine in a
<textarea> in HTML).  I have seen this problem in Mozilla 1.7b on both Linux and
Windows.

Paste - seems to do nothing.  No matter how I copy text (with "Copy" context
menu item, or with CTRL-C), the Paste menu item does nothing.

Copy - If I use this context menu item to copy text, I can paste it to an xterm
window, but I cannot paste the text to another textbox within mozilla by any
means (i.e. not with "Paste" context menu item, or with CTRL-V).  Note that
copying text with CTRL-C and pasting with CTRL-V works fine, so the Copy context
menu item is doing something different from CTRL-C.

Cut - Same behavior as Copy.  Additionally, it does not remove the text that was
supposed to be cut.

Undo - seems to do nothing

Reproducible: Always
Steps to Reproduce:
1. See Details.
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a texbox in the Mozilla chrome or in some other XUL program?  Are there
any errors in the JS console?

Comment 2

[Bill Dimm]

(In reply to comment #1)
> Is this a texbox in the Mozilla chrome or in some other XUL program?  Are there
> any errors in the JS console?

It is not in the chrome -- just a very simple XUL program containing nothing but
two textboxes (and no JS).  The JS console does show errors whenever I
right-click on the textbox (hadn't thought to check!).  It says:

Error: uncaught exception: Permission denied to create wrapper for object of
class UnnamedClass

Comment 3

[Boris Zbarsky [:bzbarsky]]

Any chance you can attach the XUL involved to this bug?

Comment 4

[Bill Dimm]

Attachment: XUL code with two textboxes - copy/paste between them with context menu fails

This is the requested XUL code.  It just creates two textboxes so you can see
that  copy/paste between them with the context menu does not work.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I wonder what exact object is failing... I bet this is because the <textbox>
binding runs with content permissions and tries to do something that content
isn't allowed to do....

Comment 6

[[e-mail]]

bz, absolutely correct, content does not have command dispatcher access. Giving
it that access would effectively give it clipboard access. The reason why the
context menu appears to work in HTML inputs and textareas is becuase that
context menu is really owned by the chrome.

The only way this bug is ever going to be fixed is if it becomes possible to
change the security context of bound nodes to that of the CSS used to bind the
node. Then the CSS in (and only in) chrome://global/content/xul.css that binds
the context menu to textboxes (and editable menulists) would be able to give
that binding chrome privileges. Normal cross-site scripting controls should be
able to prevent the content document from accessing the privileged nodes.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, it would be easy to compile the binding in the chrome context when it's a
chrome binding (that's how I plan to fix bug 236839), but that does mean that
callers can call methods on the binding and run them with chrome priveleges....
that means that we'll have to do a careful security audit of all our bindings. 
Is it possible to have methods on a binding that are not public?

Comment 8

[[e-mail]]

(In reply to comment #7)
>Is it possible to have methods on a binding that are not public?
A binding is really a JavaScript prototype, so afaik the answer is no.

Privileged handlers might be sufficient to resolve this issue.

Comment 9

[Boris Zbarsky [:bzbarsky]]

But not to resolve bug 236839.

Comment 10

[Met - Martin Hassman]

Dupe of bug #228767 ?

Comment 11

[Adam Guthrie]

*** This bug has been marked as a duplicate of 228767 ***