Open Bug 428602 Opened 16 years ago Updated 2 years ago

Cannot modify properties of a Wrapped Native (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)

Categories

(Toolkit :: UI Widgets, defect)

Product:
Toolkit
Component:
UI Widgets
Type:
defect

Tracking

()

People

(Reporter: marcia, Unassigned)

References

Details

(Whiteboard: [3.6RC1]) 

Seen while testing Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041107 Minefield/3.0pre.

Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 835"  data: no]
Not a core XBL issue.  Sounds like a bug in the binding.

Too bad the line number matches what was shipped in that build, and not anything in CVS.  :(
Component: XBL → XUL Widgets
Product: Core → Toolkit
QA Contact: xbl → xul.widgets
I can reproduce when I cause the content autocomplete popup to appear (say on google.com), then click somewhere else to dismiss the popup.

onxblpopuphiding in that file is:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/widgets/autocomplete.xml&rev=1.138#863

and in the content form autocomplete case, this.mInput is a nsFormFillController wrapping the HTMLInputElement. I'm not sure what changed that made this now throw an exception, though - a regression range would be useful.
Keywords: qawanted
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041215 Minefield/3.0pre ID:2008041215

I am able to reproduce this too, with the steps from comment 3.

Note, however, that to get the error I have to have hovered over an auto-complete item before clicking outside the drop-down to dismiss it. If I get the auto-complete drop-down to appear (by double clicking in the Google text input) and then I immediately click away, no error is thrown.

I have a range, but it's for a change in the error thrown, rather than for no error-->error.

20080306_1241_firefox-3.0b5pre.en-US.win32 throws:
  Error: this.mInput._focus is not a function
  Source File: chrome://global/content/bindings/autocomplete.xml
  Line: 831

20080306_1912_firefox-3.0b5pre.en-US.win32 throws:
  Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 828"  data: no]

Checkins to module PhoenixTinderbox between 2008-03-06 12:41 and 2008-03-06 19:12 : 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-06+12%3A41&maxdate=2008-03-06+19%3A12&cvsroot=%2Fcvsroot

If you want a range for: no "this.mInput._focus is not a function" error thrown --> "this.mInput._focus is not a function" error now thrown, then let me know and I'll go hunting tomorrow.
(In reply to comment #3)
> 20080306_1241_firefox-3.0b5pre.en-US.win32 throws:
>   Error: this.mInput._focus is not a function

> 20080306_1912_firefox-3.0b5pre.en-US.win32 throws:
>   Error: uncaught exception: [Exception... "Cannot modify properties of a
> WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)" 

Thanks Steve. That change looks like it was caused by the patch for bug 419725. It would be useful to know when this started throwing at all, but it probably doesn't matter that much - we probably shouldn't be doing what we're doing regardless of whether it throws an exception or not.
Oh, actually, we probably started throwing when the patch for bug 407359 landed. That patch assumes that mInput is a autocomplete.xml-implemented nsIAutocompleteInput, which isn't always the case (e.g. for content autocomplete, where we get the impl from nsFormFillController instead). The patch for bug 419725 just changed the error.

I suppose there a couple of ways to fix this - we could detect the underlying nsIAutocompleteInput implementation in that popuphiding handler somehow and behave differently based on that, or have content and chrome autocomplete use different popup implementations.
Keywords: qawanted
OS: Windows Vista → All
Hardware: PC → All
(In reply to comment #5)
> Oh, actually, we probably started throwing when the patch for bug 407359

Correct!

Nothing thrown: 20080123_1445_firefox-3.0b3pre.en-US.win32
"this.mInput._focus is not a function": 20080123_1608_firefox-3.0b3pre.en-US.win32

Checkins to module PhoenixTinderbox between 2008-01-23 14:45 and 2008-01-23 16:08 :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-23+14%3A45&maxdate=2008-01-23+16%3A08&cvsroot=%2Fcvsroot

--> bug 407359
Bug 445727 is a dupe with nice STR.
Blocks: mainscreena11y
The same  issue is still there.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090324 Minefield/3.6a1pre ID:20090324044213
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090324 Shiretoko/3.5b4pre ID:20090324045343
Same issue with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
This bug is still there/here/existing
Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 834"  data: no]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
This is still present in 3.6RC. Duping bug 540109 to this one.
Whiteboard: [3.6RC1]
Yes, and it isn't just annoying. I have jquery dialog and autocomplete, and when error pops up once, all code after autocomplete just stops working.

I want to have firefox history for non-autocomplete fields. Any solutions?
Still exist on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)
FWIW I just got this one or similar on today's nightly, Mozilla/5.0 (Windows NT 6.0; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre ID:20100916041016

Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 847"  data: no]
Confirming this 3 1/2 year old bug (with only one notation in the last year) is still happening in FF7.0.1. I have put up a test page to demonstrate it:
http://www.dayenu.com/interesting/ffpopupbug.htm

The specific error message written to the log now is:
Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"
nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"
location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 859"
data: no]
http://www.dayenu.com/interesting/ffpopupbug.htm gave me 3 errors on load and the mentioned error on submit with autocomplete popup open.

I'd copy my errors but my Error Console got flooded with onBeforeItemRemoved errors when i pasted that URI.

Firefox 10.0 (because the About screen doesn't say more).
I only see the "expected" error on 10.0; no load errors and no onBeforeItemRemoved (which is definitely not part of the test page). The error line number is now changed from 859 to 862.
OS X

Cannot modify properties of a WrappedNative
[Break On This Error] 	

Filtered chrome url chrome://global/content/bindings/autocomplete.xml
autocomplete.xml (line 864)
I found this error was created by an errant URL in a call to xhrGet.  By correcting the URL the error was resolved. In Chrome, the error was better identified in the response showing the errant URL.  In my case, I'd embedded an undefined value in the URL request by mistake like this:
http://localhost:9080undefinedjson/IssueSummaries

Perhaps because the port number was FUBAR, it causes this error to be reported?

Anyway, this error was a red herring reported back from the xhrGet call to a bad URL.

I'm using version 10.0.10 of Firefox.
As I wrote in bug 831664, I also observed same exception by atempting to change  two properties of an nsIMsgIncomingServer of Thundebird when the property value is "undefined".
  nsIMsgIncomingServer.trashFolderName (string) == undefined
  nsIMsgIncomingServer.isGMailServer   (boolean == undefined
  If change of this property value is attempted, the exception occurs.
The property acually doesn't exist, even when value should be set by Tb.
  for(var prop in msgFolder.server)
  { text = prop + " = " + msgFolder.server[prop]; Write text to Error Console; }
  => trashFolderName, isGMailServer, is not listed.
Reason of exception in this case looks for me "property doesn't exist".

In this case, when above value was shown by button click, the value was shown by a button click, but the value was not shown by next button click, althouh Thunderbird won't alter property value between the two button clicks.
In my test, probability of "the property is listed" was very low, although it was never ZERO.
If the property exists and value is normally returned, change of property value is successful.

So, I guessed this is not problem in wrapper side. I guessed problem in object initialization by creator of the object in Tb.
However, almost all reports on same exception of "NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN" were closed as dup of this bug, even though problem report on different native object.

Wrapper side problem? (fails to find property or propertyy value, fails to show property if not initialzed by value, ...)
Or object creator side problem? (fails to define property)
During test for bug 831664, funny phenomenon was observed.
(0) A customized ToolBar button does following.
(a) Write data of some wrapped objects and text messages to Error Console:
    - incomingServer.isGMailServer/trasfFolderName and some other attributes.
    - some properties of some other wrapped objects.
(b) Sometimes, change incomingServer.isGMailServer/trashFolderName value
    when value is normally returned.
(c) Sometimes, try to change incomingServer.isGMailServer/trashFolderName value
    even if it's undefined(=> Exception of this bug occurs)
(d) Sometimes, writes very-long/multi-line text to Error Console.
    var msg=new Array();for(var key in obj){msg[msg.length]=key+" = "+obj[key];}
    var text=msg.join("\n"); Write text to Error Console;

(1) After restart of Thunderbird, while doing (a)/(b)/(c), undefined is returned for isGMailServer/trashFolderName.
(2) When (d) is executed one or a few times("clear Error Console or not" seems irrelevant), isGMailServer/trashFolderName is normally returned suddenly for (a)/(b)/(c). Because isGMailServer/trashFolderName is not undefined, change of property value is successful.
(3) After (2), if (a)/(b)/(c) is executed after some other operations in Thunderbird(account switch, account collapse/expand etc.), undefined is suddenly returned again for isGMailServer/trashFolderName.
(4) After (3), if (d) is executed one(or a few) times, isGMailServer/trashFolderName is normally returned again for (a)/(b)/(c) => Returns to step (2).

Why wrapped object's property value depends on length of JavaScript string data and/or Error Console log data volume? 

Wrapper tries to refer to non-existent memory address, or object which is not released yet by Garbage Collector after Destroy Object?
(if garbage data is fortunately held at referred memory address, object's property is successfully shown.)
Or similar problem in object initialization/update by Thunderbird?
Phenomenon of bug 831664 was as follows.

  var Folder=window.GetFirstSelectedMsgFolder();
  var data=Folder.server.isGmailServer; => data is "undefined"
  var t=[];for(var xx in Folder.server){t[t.length]=xx+"="+Folder.server[xx];}
      => isGmailServer is not returned by enumerator
  If Folder.server.isGmailServer=true(or false) is atempted when undefined,
  Exception of this bug occurs because isGmailServer doesn't exist.

  After access of all properties of Folder(owner of Folder.server) by following,
       var u=[];for(var yy in Folder){u[u.length]=yy+"="+Folder[yy];}
  Folder.server.isGmailServer is returned normally, and value change is OK.

  Same phenomenon is also seen on som other properties of the Folder.server.   

Who is wrong? Wrapper? Creator of original object what is accessed by window.GetFirstSelectedMsgFolder() or window.GetFirstSelectedMsgFolder().server?
I checked with "never-defined property of existent wrapped object".

Requested following by test extesion where CurrentServer is [xpconnect wrapped nsIMsgIncomingServer],
  CurrentServer.ABCDEFGHIJKLMN=true;
and following exceptin was caught by try/catch(e).
> Try to change never-existent property of wrapped object for bug 831664
> Exception by CurrentServer.ABCDEFGHIJKLMN=true
> [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"

It looks for me simply a "misleading condition name".
If NS_ERROR_XPC_CANT_*CREATE*_PROP_ON_WN, no problem...
If such condition name, it's apparent that fault is in JS code who requestd property value change even though the property is undefined(i.e. non-existent),  if "creation of property via wrapped object" is not supported.
And, "why undefined is returned even though property should exist" is different problem from this bug, as seen in bug 831664.
> http://mxr.mozilla.org/comm-central/source/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp#481
> 481 XPC_WN_OnlyIWrite_SetPropertyStub(JSContext *cx, JSHandleObject obj, JSHandleId id, JSBool strict,
> 484     return XPC_WN_OnlyIWrite_AddPropertyStub(cx, obj, id, vp);
> http://mxr.mozilla.org/comm-central/source/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp#467
> 467 XPC_WN_OnlyIWrite_AddPropertyStub(JSContext *cx, JSHandleObject obj, JSHandleId id, JSMutableHandleValue vp)
> 473     // Allow only XPConnect to add/set the property
> 474     if (ccx.GetResolveName() == id)
> 475         return true;
> 477     return Throw(NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN, cx);

If apparent AddPropertyStub request for non-existent property, it should be NS_ERROR_XPC_CANT_CREATE_WN, or NS_ERROR_XPC_CANT_ADD_PROP_TO_WRAPPED_NATIVE, or one like NS_ERROR_XPC_CANT_CREATE_PROP_ON_WN.
If XPC_WN_OnlyIWrite_SetPropertyStub is called both when "setting of existent property" and "stting non-existent property" case, they should be separated to NS_ERROR_XPC_CANT_CREATE_WN(or NS_ERROR_XPC_CANT_ADD_PROP_TO_WRAPPED_NATIVE or one like NS_ERROR_XPC_CANT_CREATE_PROP_ON_WN) case and NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN case. 

> http://mxr.mozilla.org/comm-central/source/mozilla/xpcom/base/ErrorList.h#608
> 608   ERROR(NS_ERROR_XPC_CANT_CREATE_WN,                   FAILURE(25)),
> http://mxr.mozilla.org/comm-central/source/mozilla/xpcom/base/ErrorList.h#629
> 629   ERROR(NS_ERROR_XPC_CANT_ADD_PROP_TO_WRAPPED_NATIVE,  FAILURE(46)),
> http://mxr.mozilla.org/comm-central/source/mozilla/xpcom/base/ErrorList.h#635
> 635   ERROR(NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN,           FAILURE(52)),
See Also: → 1500895
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 10 duplicates.
:mstriemer, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mstriemer)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mstriemer)
You need to log in before you can comment on or make changes to this bug.