Closed Bug 387053 Opened 15 years ago Closed 15 years ago

DOM Inspector no longer attaches automatically when opened from Firefox

Categories

(Other Applications :: DOM Inspector, defect)

x86
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: mrbkap)

References

Details

(Keywords: regression)

Attachments

(1 file)

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.
************************************************************
* 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.
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.
Depends on: 384750
Attached patch Proposed fixSplinter Review
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.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #271156 - Flags: superreview?(jst)
Attachment #271156 - Flags: review?(sdwilsh)
Attachment #271156 - Flags: review?(neil)
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.
Attachment #271156 - Flags: review?(sdwilsh) → review+
Blocks: 384750
No longer depends on: 384750
Attachment #271156 - Flags: superreview?(jst) → superreview+
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(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.
Attachment #271156 - Flags: review?(neil) → review-
Yeah, see bug 387084. I'll back this bug's patch out when I check that bug's patch in, hopefully tomorrow.
I backed most of this patch out (though I did leave the newline at the end of hooks.js in the tree).
so, we are back to a working DOMi without the hack?
Yeah, we should be.
You need to log in before you can comment on or make changes to this bug.