Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Four strange JS engine behaviors

28 views
Skip to first unread message

Panos Astithas

unread,
Jun 15, 2011, 9:10:48 AM6/15/11
to dev-tech-...@lists.mozilla.org
Hello,

in the Web Console bug 651501
(https://bugzilla.mozilla.org/show_bug.cgi?id=651501) we ran across a
few weird problems with the JS engine, and Dave Townsend suggested in
comment 40 that I consult some JS experts, so here I am!

1) 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. Is that expected?

2) I tried using Components.utils.getGlobalForObject to get the scope
for my aforementioned workaround, but it exhibits the same problem,
apparently.

3) scope.Object.getOwnPropertyDescriptor throws when testing native
object properties. The exceptions I got were usually
NS_ERROR_XPC_BAD_CONVERT_JS (this is the case for document.body for
instance) or NS_ERROR_XPC_BAD_OP_ON_WN_PROTO (this is the case for
document.prefix for instance). Is that a bug?

4) The window.history.next property is not available to web content,
so any access to it throws, but I'm wondering if a typeof check
(typeof window.history.next == "function") should be considered
equivalent as well? Furthermore shouldn't chrome code, like the web
console, have access to it?

Thanks in advance for any insight you can provide.

Cheers,
Panos

Boris Zbarsky

unread,
Jun 15, 2011, 12:45:32 PM6/15/11
to
On 6/15/11 9:10 AM, Panos Astithas wrote:
> Hello,

> 1) 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. Is that expected?
>
> 2) I tried using Components.utils.getGlobalForObject to get the scope
> for my aforementioned workaround, but it exhibits the same problem,
> apparently.

You filed https://bugzilla.mozilla.org/show_bug.cgi?id=664426 on this
already, right?

> 3) scope.Object.getOwnPropertyDescriptor throws when testing native
> object properties. The exceptions I got were usually
> NS_ERROR_XPC_BAD_CONVERT_JS (this is the case for document.body for
> instance) or NS_ERROR_XPC_BAD_OP_ON_WN_PROTO (this is the case for
> document.prefix for instance). Is that a bug?

https://bugzilla.mozilla.org/show_bug.cgi?id=560072

> 4) The window.history.next property is not available to web content,
> so any access to it throws, but I'm wondering if a typeof check
> (typeof window.history.next == "function") should be considered
> equivalent as well?

Yes, of course. That's a get followed by some other stuff, but it's the
_get_ that throws.

> Furthermore shouldn't chrome code, like the web
> console, have access to it?

Chrome code should.

Code executed in the web console typein does not run as chrome.

Note that the .next getter will throw on get even in chrome code if
there is not in fact a next entry. So you have to guard against that no
matter what.

-Boris

Boris Zbarsky

unread,
Jun 15, 2011, 2:35:38 PM6/15/11
to
On 6/15/11 12:45 PM, Boris Zbarsky wrote:
> On 6/15/11 9:10 AM, Panos Astithas wrote:
>> Hello,
>> 1) 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. Is that expected?
>>
>> 2) I tried using Components.utils.getGlobalForObject to get the scope
>> for my aforementioned workaround, but it exhibits the same problem,
>> apparently.
>
> You filed https://bugzilla.mozilla.org/show_bug.cgi?id=664426 on this
> already, right?

Or was that only for #2, with #1 remaining unfiled? If so, seems like
it should perhaps be filed....

-Boris

Panos Astithas

unread,
Jun 16, 2011, 7:01:02 AM6/16/11
to Boris Zbarsky, dev-tech-...@lists.mozilla.org
On Wed, Jun 15, 2011 at 7:45 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 6/15/11 9:10 AM, Panos Astithas wrote:
>>
>> Hello,
>> 1) 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. Is that expected?
>>
>> 2) I tried using Components.utils.getGlobalForObject to get the scope
>> for my aforementioned workaround, but it exhibits the same problem,
>> apparently.
>
> You filed https://bugzilla.mozilla.org/show_bug.cgi?id=664426 on this
> already, right?
> Or was that only for #2, with #1 remaining unfiled? If so, seems like it should perhaps be filed....

Yes that was for #2. I've filed bug 664689 for this.

>> 3) scope.Object.getOwnPropertyDescriptor throws when testing native
>> object properties. The exceptions I got were usually
>> NS_ERROR_XPC_BAD_CONVERT_JS (this is the case for document.body for
>> instance) or NS_ERROR_XPC_BAD_OP_ON_WN_PROTO (this is the case for
>> document.prefix for instance). Is that a bug?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=560072

I found bug 520882 shortly after posting, but this is even more accurate.

>> 4) The window.history.next property is not available to web content,
>> so any access to it throws, but I'm wondering if a typeof check
>> (typeof window.history.next == "function") should be considered
>> equivalent as well?
>
> Yes, of course.  That's a get followed by some other stuff, but it's the
> _get_ that throws.

OK, I just wondered whether typeof did some magic without executing the getter.

>> Furthermore shouldn't chrome code, like the web
>> console, have access to it?
>
> Chrome code should.
>
> Code executed in the web console typein does not run as chrome.

Understood, the code in question runs as chrome code.

> Note that the .next getter will throw on get even in chrome code if there is
> not in fact a next entry.  So you have to guard against that no matter what.

I wasn't aware of that, and most (all?) of my tests match that
profile. I'll try to verify if that was the reason for throwing.

Thanks for the very helpful pointers!

Panos

Boris Zbarsky

unread,
Jun 16, 2011, 11:47:28 AM6/16/11
to
On 6/16/11 7:01 AM, Panos Astithas wrote:
> OK, I just wondered whether typeof did some magic without executing the getter.

That would be a spec violation.

-Boris

0 new messages