664426 - Components.utils.getGlobalForObject does not work for content objects when invoked in chrome code

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Panos Astithas (he/him) [:past] (please ni?)]

In bug 651501 we ran across a weird problem with getGlobalForObject. Some preamble: Object.getOwnPropertyDescriptor(o,p) does not work the same when checking content- vs. chrome-provided objects. The web console runs with chrome privileges and I had to resort to using scope.Object.getOwnPropertyDescriptor(o,p), where scope is the global for o, to have it work for content. I tried using Components.utils.getGlobalForObject to get that scope object, but it exhibits the same problem, apparently. Is this expected behavior or is it a bug?

Comment 1

[Boris Zbarsky [:bzbarsky]]

So the actual issue here is what getOwnPropertyDescriptor should do on our security-wrapper proxies, right?  Is this an issue for all properties (and an issue for the safe object wrapper), or just an issue for XPConnect stuff on XrayWrapper?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Is this just bug 613315? I have a patch there that I've been meaning to land, though it needs a test...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sure looks like it...

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to comment #1)
> So the actual issue here is what getOwnPropertyDescriptor should do on our
> security-wrapper proxies, right?  Is this an issue for all properties (and
> an issue for the safe object wrapper), or just an issue for XPConnect stuff
> on XrayWrapper?

This is a separate issue AFAICT and I've filed bug 664689 as you suggested.

(In reply to comment #3)
>> (In reply to comment #2)
>> Is this just bug 613315? I have a patch there that I've been meaning to
>> land, though it needs a test...
>
> Sure looks like it...

Indeed it does. I'll try to apply both our patches from these bugs and if it works, I'll mark this as a duplicate.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to comment #4)
> (In reply to comment #3)
> >> (In reply to comment #2)
> >> Is this just bug 613315? I have a patch there that I've been meaning to
> >> land, though it needs a test...
> >
> > Sure looks like it...
> 
> Indeed it does. I'll try to apply both our patches from these bugs and if it
> works, I'll mark this as a duplicate.

It must have bitrotted a bit. This is what I get when autocompleting something or inspecting an object:

*** Compartment mismatch 0x1062b0c00 vs. 0x1260a2c00
Assertion failure: compartment mismatched, at /Users/past/src/devtools/js/src/jscntxtinlines.h:121
Segmentation fault

I'm testing with this simple patch against today's devtools repo:

--- a/toolkit/components/console/hudservice/PropertyPanel.jsm
+++ b/toolkit/components/console/hudservice/PropertyPanel.jsm
@@ -177,16 +177,17 @@ function isNativeFunction(aFunction)
  */
 function isNonNativeGetter(aScope, aObject, aProp) {
   if (typeof aObject != "object") {
     return false;
   }
   let desc;
   while (aObject) {
     try {
+      aScope = Cu.getGlobalForObject(aObject);
       if (desc = aScope.Object.getOwnPropertyDescriptor(aObject, aProp)) {
         break;
       }
     }
     catch (ex) {
       // Native getters throw here. See bug 520882.
       if (ex.name == "NS_ERROR_XPC_BAD_CONVERT_JS" ||
           ex.name == "NS_ERROR_XPC_BAD_OP_ON_WN_PROTO") {

Comment 6

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.