387053 - DOM Inspector no longer attaches automatically when opened from Firefox

Status: RESOLVED FIXED

(Other Applications :: DOM Inspector, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Load a page in a Firefox browser window.
2. Press Cmd+Shift+I

Expected: DOM Inspector opens, showing that document.

Result: DOM Inspector opens, but doesn't show any document.  (Workaround: attach to the document using the file menu.)

I noticed this bug while using a Mac trunk debug build from about an hour ago.  I think it's a regression from within the last few days.

Comment 1

[Shawn Wilsher :sdwilsh]

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Security Manager vetoed action"  nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: chrome://inspector/content/inspector.js :: anonymous :: line 162"  data: no]
************************************************************

I imagine that that is the culprit.  I'm not sure why this is suddenly happening.

Comment 2

[Shawn Wilsher :sdwilsh]

Works in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007070508 Minefield/3.0a7pre

No security warning then either.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

The problem is that DOMI sets xpcnativewrappers=no in its manifest, but the overlay itself is not affected by this. Therefore, the overlay, when it passes the document to DOMI code, passes XPCNativeWrappers. With the patch for bug 384750, XPCNativeWrapper throws if code that shouldn't have its hand on an implicit XPCNativeWrapper uses one. So DOMI gets dinged. The fix here is to pass the wrappedJSObject into the DOMI code, which means that now, DOMI will start getting XPCSafeJSObject wrappers instead.

I'm not sure how this all worked before, however, since the deep XPCNativeWrapper should have been propagating all the way through the DOMI code. I'm hoping that the same thing will prevent the XPCSafeJSObjectWrapper from having unexpected effects.

Comment 4

[Shawn Wilsher :sdwilsh]

Comment on attachment 271156 [details] [diff] [review]
Proposed fix

I'm ok with getting Neil's review post-landing so we can have a working DOMi in the nightly.  You can land this once you get sr.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 6

[[e-mail]]

(In reply to comment #3)
>The problem is that DOMI sets xpcnativewrappers=no in its manifest, but the
>overlay itself is not affected by this. Therefore, the overlay, when it passes
>the document to DOMI code, passes XPCNativeWrappers. With the patch for bug
>384750, XPCNativeWrapper throws if code that shouldn't have its hand on an
>mplicit XPCNativeWrapper uses one. So DOMI gets dinged. The fix here is to
>pass the wrappedJSObject into the DOMI code, which means that now, DOMI will
>start getting XPCSafeJSObject wrappers instead.
That's bad. If I use the Error Console (which runs from about:blank with the system principal so never uses native wrappers) I expect to be able to do stuff like top.opener.getBrowser().contentdocument.nodeType without getting dinged.

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Yeah, see bug 387084. I'll back this bug's patch out when I check that bug's patch in, hopefully tomorrow.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

I backed most of this patch out (though I did leave the newline at the end of hooks.js in the tree).

Comment 9

[Shawn Wilsher :sdwilsh]

so, we are back to a working DOMi without the hack?

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Yeah, we should be.