Closed Bug 701326 Opened 13 years ago Closed 11 years ago

"Cannot modify properties of a WrappedNative" exception thrown when using XPCOM components exposed to content

Categories

(Add-on SDK Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: r.pelizzi, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0a2) Gecko/20111108 Firefox/9.0a2
Build ID: 20111108041000

Steps to reproduce:

I developed an XPCOM component and exposed it to content through the Javascript-global-property category. I attempted to call one of its methods in a content script.


Actual results:

I get this exception:
Traceback (most recent call last):
  File "resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-lib/timer.js", line 66, in notifyOnTimeout
    this._callback.apply(null, this._params);
  File "resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-lib/content/worker.js", line 119, in null
    callback.apply(null, params);
  File "/tmp/tmpzZBvEf.mozrunner/extensions/jid1-XP0gS3aaEwQe3w@jetpack//resources/jid1-xp0gs3aaewqe3w-at-jetpack-spider-data/content.js", line 4, in analyze
  File "/tmp/tmpzZBvEf.mozrunner/extensions/jid1-XP0gS3aaEwQe3w@jetpack//resources/jid1-xp0gs3aaewqe3w-at-jetpack-spider-data/jquery-1.6.2.js", line 273, in null
  File "/tmp/tmpzZBvEf.mozrunner/extensions/jid1-XP0gS3aaEwQe3w@jetpack//resources/jid1-xp0gs3aaewqe3w-at-jetpack-spider-data/jquery-1.6.2.js", line 655, in null
  File "/tmp/tmpzZBvEf.mozrunner/extensions/jid1-XP0gS3aaEwQe3w@jetpack//resources/jid1-xp0gs3aaewqe3w-at-jetpack-spider-data/content.js", line 15, in null
  File "/tmp/tmpzZBvEf.mozrunner/extensions/jid1-XP0gS3aaEwQe3w@jetpack//resources/jid1-xp0gs3aaewqe3w-at-jetpack-spider-data/content.js", line 106, in processScriptTag
  File "/tmp/tmpzZBvEf.mozrunner/extensions/jid1-XP0gS3aaEwQe3w@jetpack//resources/jid1-xp0gs3aaewqe3w-at-jetpack-spider-data/content.js", line 96, in processScript
  File "resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-data/content-proxy.js", line 721, in null
    return wrap(o, obj, name);
  File "resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-data/content-proxy.js", line 257, in wrap
    return getProxyForObject(value);
  File "resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-data/content-proxy.js", line 300, in getProxyForObject
    configurable : false});
[Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-lib/cuddlefish.js -> resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-lib/content/worker.js -> resource://jid1-xp0gs3aaewqe3w-at-jetpack-api-utils-data/content-proxy.js :: getProxyForObject :: line 300"  data: no]



Expected results:

I suppose I should have been able to use the property normally. I can access the property from the web console just fine.
I though I made an error writing my xpcom component or exposing it as a global property, so I tried with the sidebar property, which I used to learn how to expose my component to content. I just placed this call in one of my content scripts:
sidebar.IsSearchProviderInstalled("gffg");
The same exception is thrown. In the case of the sidebar, this is the obj argument passed to getProxyForObject:
[xpconnect wrapped (nsISupports, nsISidebar, nsISidebarExternal) @ 0x9feaed40 (native @ 0x9fe2ddc0)]
Alex, can you take a look at this?

Shane, I heard that there's a new method for extending the Navigator object that's exposed to everything. Would you be able to help Riccardo see if that would work for him?
Priority: -- → P2
for the record, wrapping the offending statement in a try clause and returning the object directly in case of an exception seems to solve the problem, but i don't know enough about jetpack internals: if you are proxying for security reasons, then my workaround is an epic fail :-)
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.

In this case, if the property value is normally returned, change of the property's value is successful. And, in older Tb, trashFolderName==correct string and isGMailServer==correct boolean was reurned(sometimes in my test though), and change of the value was succewsfull.
  
So, I guessed this is not problem in wrapper side. I guessed problem in object initialization by creator of the object in Tb(boolean property is not initialize as true or false. defined property name only. for example, var xx;obj["propname"]=xx;, where it should be obj["propname"]=false;)
However, almost all reports on same exception of "NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN" were closed as dup of bug 428602 even though problem report on different native object. Actually wrapper side only problem?
Flags: needinfo?
Flags: needinfo?
Removing priority so we can look at this in triage today. This doesn't feel like an SDK bug to me.
Priority: P2 → --
Can this be reproduced with a current version of the SDK now that content-proxies have been removed?
Flags: needinfo?
Not hearing back, let's close this for now. Reopen if it's still a problem with current versions of the SDK.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.