+++ 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

Test case: https://bugzilla.mozilla.org/attachment.cgi?id=497727

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>

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)

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

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.

Contrary to my original assumption this doesn't fix the instanceof issue.

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

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. ;-)