Closed Bug 620486 Opened 9 years ago Closed 9 years ago

window.wrappedJSObject != window.wrappedJSObject

Categories

(Core :: XPConnect, defect, P2)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: gal, Assigned: gal)

References

Details

(Whiteboard: [firebug-p1][hardblocker] fixed-in-tracemonkey)

Attachments

(1 file, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #610390 +++

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre

The wrappedJSObjects returned by DOM nodes seem to return wrapped objects in such a way that each access returns a new wrapper which does not compare equal with any other wrappers for the same object. This problem extends to the wrappers returned by property accesses of the returned wrappers, such that the following always returns false:

  let (w = content.wrappedJSObject) w == w.parent || w.parent == w.parent;

despite the fact that content == content.parent && content.parent == content.parent;

This bug is in particular responsible for a conflict between Greasemonkey/Scriptish and Firebug:

http://code.google.com/p/fbug/issues/detail?id=3586
http://github.com/greasemonkey/greasemonkey/issues/issue/1211
https://github.com/erikvold/scriptish/issues/issue/116

Reproducible: Always
Blocks: 610390
No longer blocks: 605001
No longer depends on: 610390
Summary: Object wrappers no longer compare equal (among other things, window.wrappedJSObject != window.wrappedJSObject) → window.wrappedJSObject != window.wrappedJSObject
Assignee: nobody → gal
blocking2.0: beta8+ → beta9+
Duplicate of this bug: 620487
bug 610390 comment 30 also has a pretty simple testcase.
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>
<window title="Mozilla Bug 610390"
  onload="var doc = document.getElementById('ifr').contentDocument;
          alert(doc.wrappedJSObject == doc.wrappedJSObject)"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

  <iframe type="content" src="about:blank" id="ifr"/>
</window>
Blocks: 605001
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
No longer blocks: 605001, 610390
blocking2.0: beta9+ → betaN+
Was there a reason to remove everyone from the CC field for this bug?
Arguments for this blocking were given in bug 610390.  Those supporting this issue blocking the release (stated in bug 610390) include:
 * jst (comment 5)
 * Callek (comment 37)
 * bz (comment 38)
 * Kris Maglione (comment 40)
Fixing fields my automated script accidentally blanked. Apologies for the bugspam
Whiteboard: [firebug-p1]
Whiteboard: [firebug-p1] → [firebug-p1][hardblocker]
Dumb question: how do I run that xul test case?

Do I need to make a whole extension to stick it in? I tried pointing to it with a file:// URI, but even after setting dom.allow_XUL_XBL_for_file=true I'm not allowed to access .contentDocument.
(In reply to comment #9)
> Dumb question: how do I run that xul test case?
> 
> Do I need to make a whole extension to stick it in? I tried pointing to it with
> a file:// URI, but even after setting dom.allow_XUL_XBL_for_file=true I'm not
> allowed to access .contentDocument.

I have been wondering the same thing with XUL file attachments.
This is responsible for some Firebug issues with FF4, not to mention extensions that deal with content and do any comparisons (um... like mine).
I think I found the cause. Patch soon.
Attached patch patch (obsolete) — Splinter Review
Contrary to my original assumption this doesn't fix the instanceof issue.
Attachment #503556 - Flags: review?(mrbkap)
Attached patch patchSplinter Review
Attachment #503556 - Attachment is obsolete: true
Attachment #503556 - Flags: review?(mrbkap)
Attachment #503573 - Flags: review?(mrbkap)
Attachment #503573 - Flags: review?(mrbkap) → review+
Duplicate of this bug: 597872
Whiteboard: [firebug-p1][hardblocker] → [firebug-p1][hardblocker] fixed-in-tracemonkey
How long before this shows up in Minefield?
Chris, you merged this but it seems you missed marking it.

This is in mozilla-central and should be in tonights nightly.

http://hg.mozilla.org/mozilla-central/rev/a6bd34672545
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I think I may have hit another version of this bug.In the same code where we had this bug before:
                if (context.window == rootWindow)
                    return context;
I find that the test is false if the rootWindow comes from the outer most scope of a stack frame in jsd and it is a chrome URL in a content window.  The script filename URLs are http.

Does this ring a bell with anyone?

The test case I have is public but it's a dojo test case for a dojo extension for firebug so it is not exactly a reduced case. ;-)
You need to log in before you can comment on or make changes to this bug.