409786 - Custom added elements into toolbox.palette causes NS_ERROR_XPC_BAD_OP_ON_WN_PROTO

Status: RESOLVED INCOMPLETE

(Firefox :: Toolbars and Customization, defect)

Description

[antonglv]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

There is a bug in comparison with FF2.x versions - custom added from js code elements in toolbox.palette (toolbox id="navigator-toolbox") causes error NS_ERROR_XPC_BAD_OP_ON_WN_PROTO, and doesn't supposed action.

Reproducible: Always

Steps to Reproduce:
1. Open "Error console" and evaluate next js code (concatenate first in single line):
var tw=Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("navigator:browser");
var doc=tw.document;
var b=doc.createElementNS("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul","toolbarbutton");
b.setAttribute("label","test");doc.getElementById("navigator-toolbox").palette.appendChild(b);
2. Next open "Customize toolbars" dialog


Actual Results:  
There is no "test" labeled element in "Customize toolbars" dialog, as assumes; in "Error console" you can see error:
Error: uncaught exception: [Exception... "Illegal operation on WrappedNative prototype object"  nsresult: "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)"  location: "JS frame :: chrome://global/content/customizeToolbar.js :: setWrapperType :: line 452"  data: no]

Expected Results:  
In "Customize toolbars" dialog, as assumes, must appear element, which has label "test"; no errors in "Error console"

In FF2.x versions mentioned code doesn't cause error after "Customize toolbars" dialog opens, and shows needed element in the dialog.

// This is base feature of custombuttons[2]/customitems extensions

Comment 1

[George Dunham [SCClockDr]]

Attachment: Code snippets that show the work around

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020904 Minefield/3.0b4pre - Build ID: 2008020904

I believe I've found a means of working around this issue in Custom Buttons². I completely did away with creating a new button via document create. This work around requires that a initialized custombutton be available.
All element actions are supported in this work around.
1. Cloning to create a new custombutton.
2. Modifying the current custombutton.
3. Creating a brand new custombutton.
These new/modified buttons are immediately available to place in the Customize... toolbox without error.

The basic logic is to:
1. Determine a valid button was passed.
2. Retrieve one if none was passed. (create new)
3. Retrieve this button's palette node.
4. Create a new nodeOne via cloneNode(false)
5. Apply the Attributes/mods to this new node.
6. This is I believe the magic part. - Now clone the new modified node to yet another new nodeTwo. via cloneNode(true) - This will become the new custombutton bound to a toolbar.
7. Create a new button:
a. Insert nodeTwo into the appropriate toolbar.
b. Append nodeOne to the palette.
c. Remove the nodeTwo from its toolbar. - This leaves a properly wrapped item in the palette only.
8. For clone:
a. Insert nodeTwo into the appropriate toolbar.
b. Append nodeOne to the palette.
9. For Update/modify
a. Replace the original toolbar member with nodeTwo.
b. Replace the original palette member with nodeOne.

A Code snippet file with most of the pertinent functions is available at:
http://custombuttons2.pastebin.com/f451f3d8d 
The complete Extension Custom Buttons² that demonstrates this, is available at:
http://custombuttons2.com/forum/viewtopic.php?f=39&t=639

Comment 2

[Yury Semikhatsky]

===================================================================
RCS file: /cvsroot/mozilla/toolkit/content/customizeToolbar.js,v
retrieving revision 1.45
diff -u -r1.45 customizeToolbar.js
--- customizeToolbar.js 29 Apr 2008 19:07:14 -0000      1.45
+++ customizeToolbar.js 20 May 2008 14:09:21 -0000
@@ -359,6 +359,7 @@
   while (templateNode) {
     // Check if the item is already in a toolbar before adding it to the palette.
     if (!(templateNode.id in currentItems)) {
+      templateNode = new XPCNativeWrapper(templateNode);
       var paletteItem = templateNode.cloneNode(true);

       if (rowSlot == kRowMax) {


This trick fixes the issue. So does the following:
===================================================================
RCS file: /cvsroot/mozilla/toolkit/content/customizeToolbar.js,v
retrieving revision 1.45
diff -u -r1.45 customizeToolbar.js
--- customizeToolbar.js 29 Apr 2008 19:07:14 -0000      1.45
+++ customizeToolbar.js 20 May 2008 14:11:03 -0000
@@ -269,6 +269,7 @@
   // XXX We need to call this AFTER the palette item has been appended
   // to the wrapper or else we crash dropping certain buttons on the
   // palette due to removal of the command and disabled attributes - JRH
+  aPaletteItem = new XPCNativeWrapper(aPaletteItem);
   cleanUpItemForPalette(aPaletteItem, wrapper);

   if (aSpacer)

Though,
var tw=Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("navigator:browser");
var doc=tw.document;
var
b=doc.createElementNS("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul","toolbarbutton");
b.setAttribute("label","test");doc.getElementById("navigator-toolbox").palette.appendChild(new XPCNativeWrapper(b));

doesn't work. 

Comment 3

[Mike Shaver (:shaver emeritus)]

Gavin, could you take a look here?  Be good to get in a 3.0.1

Comment 4

[Boris Zbarsky [:bzbarsky]]

peterv, any idea what's going on here?

Comment 5

[alta88]

for more on how to recreate this in a closely related scenario, see

http://groups.google.com/group/mozilla.dev.tech.dom/browse_thread/thread/0ed75a340548793d/29b798822b240ba8?#29b798822b240ba8

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

This bug hasn't gotten a lot of attention so I'm uncomfortable blocking the first branch release on it (especially with workaround code) but a regression fix is definitely wanted.

Can we get a regression range on this? STR in comment 0 should make it pretty easy to figure out when this stopped working.

Comment 7

[Ria Klaassen (not reading all bugmail)]

The error turned from: 
Error: uncaught exception: [Exception... "Node cannot be used in a document other than the one in which it was created"  code: "4" nsresult: "0x80530004 (NS_ERROR_DOM_WRONG_DOCUMENT_ERR)"  location: "chrome://global/content/customizeToolbar.js Line: 227"]

into:
Error: uncaught exception: [Exception... "Illegal operation on WrappedNative prototype object"  nsresult: "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)"  location: "JS frame :: chrome://global/content/customizeToolbar.js :: setWrapperType :: line 452"  data: no]

Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-11-24+13%3A00&maxdate=2006-11-24+23%3A00

Comment 8

[Philip Chee]

Ugh. Also see Bug 407725 (Toolbar customisation pointlessly removes, clones and adopts nodes)

Comment 9

[WADA:World Anti-bad-Duping Agency]

For "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)" case:
  Same phenomenon by same cause as Bug 360883? See also Bug 417004.
    Bug 360883 : f=confirm case.
    Test case attached to Bug 417004 : f=document.getlementById case.

Comment 10

[antonglv]

It seems I have found the bug's precondition. The Custom Buttons/Custom Buttons2 extensions bind xbl on toolbarbuttons in main window and in customizeToolbar.xul; customizeToolbar.js script fails on these binded toolbarbuttons when it tries access to 'localName', 'title' properties, or 'getAttribute', 'setAttribute', 'hasAttribute' or 'removeAttribute' methods (and possible other DOM properties/methods).

There is two workarounds: to define 'localName', 'title' properties and "xxxAttribute" methods in custombutton's xbl or to bind xbl when customizeToolbar.js script has finished.

But 'standard' bindings, i. e., xbl from Firefox chrome don't break customizeToolbars.js. Custom Buttons' bindings extends these FF's bindings. Why FF's bindings don't break customizeToolbar.js but Custom Button's binding does ?

Also, binded toolbarbuttons don't require DOM properties/methods definition in xbl if these placed in main window, no matter which xbl is binded to them - 'standard' or from extension chrome.

Comment 11

[Philip Chee]

Those are standard DOM properties and nodes. XBL shouldn't affect those I don't think.

Comment 12

[buovjaga]

Still confirmed in macOS 10.12, FF 50.0.2. I did it in Browser console after enabling chrome debugging features from the dev toolbar settings.

Comment 13

[Timea Cernea [:tbabos][inactive]]

Hey Boris,
Is this issue, especially the code snippet dropped in the browser console still relevant for today's Customize Toolbar? I am not getting errors in the browser console but I also don't see the new "test" element. So not quite sure what is going on here, please take a brief look on this when you have the time, thanks!

Comment 14

[Boris Zbarsky [:bzbarsky]]

I'm not sure why you're asking me... I don't know anything about what today's customize toolbar looks like, and I did not file this bug or say anything in it other than asking peterv whether he had any idea what's going on.

That said, the specific exception involved can no longer happen at all, ever since we switched DOM nodes to WebIDL bindings. Not sure what this means in terms of the original problem.

Comment 15

[Andrew McCreight [:mccr8]]

A bug this old doesn't seem very useful to leave around. As Boris said, the specific error can't happen any more.