472979 - NoScript extension does not work on trunk builds - Components.utils.lookupMethod() is broken

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Bill Gianopoulos [:WG9s]]

Beginning with the 20090107 nightly, the NoScript extension does not work correctly.  It blocks content just fine, but unblocking content does not work correctly.

left-clicking on a blocked element results in the error:

Error: browser is null
Source File: file:///C:/Documents%20and%20Settings/Spence/Application%20Data/Mozilla/Firefox/Profiles/oyyjxo2x.3.1%20Trunk/extensions/%7B73a6fe31-595d-460b-a920-fcc0f8843232%7D/components/noscriptService.js
Line: 3990

Doing an hg bisect returned the following:

The first bad revision is:
changeset:   23363:abaa242f2300
user:        Blake Kaplan <[e-mail]>
date:        Tue Jan 06 14:17:02 2009 -0500
summary:     Bug 470720 - Don't automatically unwrap XOWs or SJOWs in XPCNativeWrappers. r+sr=jst

Comment 1

[Bill Gianopoulos [:WG9s]]

I forgot to mention two other symptoms of the issue.

1.  It is also impossible to unblock individual elements via the context menu.
2.  If you select allow scripts form the host that is being blocked, that works.  However, you need to manually perform the required reload.  It is supposed to do that automatically.

Comment 2

[Bill Gianopoulos [:WG9s]]

According to the NoScript site, Components.utils.lookupMethod() is broken.

Comment 3

[Bill Gianopoulos [:WG9s]]

setting dependency on 472674 since I do not have permission to set it to block a security bug.

Comment 4

[Giorgio Maone [:ma1]]

More context: NoScript's service calls 

Components.utils.lookupMethod(win, "top")()

on a window retrieved from a DOM node with something like node.ownerDocument.defaultView, in order to obtain a wrapped-for-sure start point to consistently deal with component-set expandos.

Apparently now we already have a XPCNativeWrapper and this call fails with
Error: Could not convert JavaScript argument = NS_ERROR_XPC_BAD_CONVERT_JS
 
I worked around quick and dirt in 1.8.8.92 ( http://noscript.net/getit#devel ) with
try { ctx = this.lookupMethod(ctx, "top")(); } catch(e) { ctx = ctx.top; }

Not sure if this is the best work-around available (should I check for wrappedJSObject instead? suggestions are welcome), anyway this really looks like a dupe of bug 472674.

Comment 5

[Philip Chee]

I filed Bug 469844 because Flashblock has a problem with Components.utils.lookupMethod on trunk. Not sure if this is the same problem though. Giorgio?

Comment 6

[Giorgio Maone [:ma1]]

Phil, they seem two very different issues. 
You get a permission denied, probably due to your principal being a content one and not having privileges to reach Components.utils. 
I get a bad argument exception, probably due to lookupMethod chocking at an already wrapped object.

Comment 7

[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.