Last Comment Bug 605001 - ChatZilla Broken - Does not display anything in the message window.
: ChatZilla Broken - Does not display anything in the message window.
Status: VERIFIED FIXED
[cz-0.9.86.1]
: regression
Product: Other Applications
Classification: Client Software
Component: ChatZilla (show other bugs)
: Trunk
: All All
: -- normal with 10 votes (vote)
: ---
Assigned To: Robert Utasi [:hunboy]
:
:
Mentors:
: 571956 611717 613658 (view as bug list)
Depends on: 620486
Blocks: 580128
  Show dependency treegraph
 
Reported: 2010-10-17 08:13 PDT by therube
Modified: 2014-10-29 07:09 PDT (History)
41 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
-
final+


Attachments
fix (1.21 KB, patch)
2010-11-05 01:39 PDT, Misak Khachatryan
gijskruitbosch+bugs: review-
Details | Diff | Splinter Review
patch without wrapper (444 bytes, patch)
2010-11-12 21:44 PST, Robert Utasi [:hunboy]
bugzilla-mozilla-20000923: review+
Details | Diff | Splinter Review
alternative patch (531 bytes, text/plain)
2010-11-13 02:46 PST, Robert Utasi [:hunboy]
no flags Details
patch with wrapper (1.89 KB, text/plain)
2011-01-22 23:10 PST, Robert Utasi [:hunboy]
no flags Details
patch without wrapper (1.11 KB, text/plain)
2011-01-22 23:12 PST, Robert Utasi [:hunboy]
no flags Details
patch with wrapper (723 bytes, patch)
2011-02-03 17:19 PST, Robert Utasi [:hunboy]
no flags Details | Diff | Splinter Review
patch meta reorder (630 bytes, patch)
2011-02-06 21:54 PST, Robert Utasi [:hunboy]
bugzilla-mozilla-20000923: review+
Details | Diff | Splinter Review
testcase - NS_BINDING_ABORTED (3.97 KB, application/vnd.mozilla.xul+xml)
2011-02-07 17:34 PST, Robert Utasi [:hunboy]
no flags Details
alternative patch: unwrap DOMWindow (771 bytes, patch)
2011-03-06 08:51 PST, :Mook
mook.moz+mozbz: review-
Details | Diff | Splinter Review

Description therube 2010-10-17 08:13:58 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101017 Firefox/4.0b8pre SeaMonkey/2.1b2pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101017 Firefox/4.0b8pre SeaMonkey/2.1b2pre

 
Chatzilla "works" /except/ that nothing displays nor is echoed in the message window (content area).

That little problem aside, most other aspects of cZ seem to work.  The list of users will display.  You can enter comments, they are accepted (viewable from a different client).
 

Reproducible: Always

Steps to Reproduce:
 
1. open SeaMonkey
2. click the cZ icon
 
Actual Results:  
 
ChatZilla opens.
The *client* tab message window (content area) is empty (where normally there would be text).

Type '/attach moznet'.
A 'moznet' tab opens.
From within the moznet tab, type '/join seamonkey'.
A #seamonkey chat session opens.

The list of users does display.
Nothing displays in the message window.
Type something into the message line (input box) & hit return.
Nothing is echoed back & still nothing displays in the message window. (Though the message is accepted.  Can be verified from a different client that it does appear.)

Alternatively, opening irc://irc.mozilla.org/seamonkey returns the same results.
 

Expected Results:  
 
The message window (content area) should display messages (content).
 

 
20101013 works
20101014 broken

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a0cca0e817e8&tochange=047cb442023a
Comment 1 Misak Khachatryan 2010-10-17 08:49:25 PDT
Reproducible on my Fedora 13. As a workaround, right click on a tab and select Clear Tab.
Comment 2 Philip Chee 2010-10-17 11:01:19 PDT
Same regression range as Bug 604493 so probably also caused by the latest tracemonkey merge. Probably suspect is the new compartments feature.
Comment 3 Tim Maks van den Broek [:mad_maks] 2010-10-23 01:07:46 PDT
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101022 Firefox/4.0b8pre

i see the same problem here, workaround of #1 works.
Comment 4 Ryan VanderMeulen [:RyanVM] 2010-10-24 10:15:47 PDT
Should this block beta7? It's a pretty ugly compartments regression.
Comment 5 Serge Gautherie (:sgautherie) 2010-11-04 06:47:04 PDT
"blocking-seamonkey2.1=?":
The workaround is fine for developers, but would not be for release, I think.
Comment 6 Serge Gautherie (:sgautherie) 2010-11-04 06:56:14 PDT
Just to rule this out, could it be a bug 606366 -like issue?
http://mxr.mozilla.org/comm-central/search?string=.wrappedJSObject&case=1&find=%2Firc%2Fjs%2Flib%2F.*%5C.js%24
"Found 6 matching lines in 2 files"
Comment 7 Misak Khachatryan 2010-11-05 01:39:58 PDT
Created attachment 488439 [details] [diff] [review]
fix

You-re right Stefan. This patch fixes it for me.
Comment 8 :Gijs Kruitbosch 2010-11-05 04:03:04 PDT
Comment on attachment 488439 [details] [diff] [review]
fix

You don't need superreview. We're not that important. :-)

I'm 99.99% sure this change is totally backwards-incompatible. We're going to have to come up with something better.

Also, the check which you're removing seems really cautious and benign. Are you saying that right now, there's a wrappedJSObject property - we just can't use it? Because that sounds like a really, really crappy API.
Comment 9 Felix Miata 2010-11-05 04:14:55 PDT
I incorporated that patch in my SM 20101030 chatzilla.jar. Bless you Misak!
Comment 10 Misak Khachatryan 2010-11-05 05:57:03 PDT
(In reply to comment #8)
> I'm 99.99% sure this change is totally backwards-incompatible. We're going to
> have to come up with something better.

That's nice, because i removed only two instances of code with wrappedJSObject, removing other ones prevent Chatzilla to connect. So wrappedJSObject lying around somewhere.

> Also, the check which you're removing seems really cautious and benign. Are you
> saying that right now, there's a wrappedJSObject property - we just can't use
> it? Because that sounds like a really, really crappy API.

I know nothing. Just copied patch from bug 606366. I don't have real knowledge of all this stuff, trying to move things forward :)
Comment 11 Serge Gautherie (:sgautherie) 2010-11-05 07:39:18 PDT
Comment on attachment 488439 [details] [diff] [review]
fix

Ftr, this code was added in
http://hg.mozilla.org/chatzilla/rev/2a0f3de6c2dd
"Bug 370760 - Wrap calls to get content properties, and expand wrappers for theses."

***

Maybe a backward-compatible solution would be to pass the property too then try{} to access it in the functions.?.
Comment 12 Serge Gautherie (:sgautherie) 2010-11-05 07:41:45 PDT
(In reply to comment #8)
> Are you
> saying that right now, there's a wrappedJSObject property - we just can't use
> it? Because that sounds like a really, really crappy API.

You might want to read bug 580128. (I didn't.)
Comment 13 :Gijs Kruitbosch 2010-11-05 07:50:37 PDT
(In reply to comment #12)
> (In reply to comment #8)
> > Are you
> > saying that right now, there's a wrappedJSObject property - we just can't use
> > it? Because that sounds like a really, really crappy API.
> 
> You might want to read bug 580128. (I didn't.)

I read it but failed to understand it. CC-ing mrbkap, jorendorff, andreas gal.

Guys, is there some way we can still backwards-compatibly access properties in content browsers? I am confused - there's a wrappedJSObject, but it doesn't have the content properties? The talk of "brains" in the bug does not help me understand what's going on. :-)

(I appreciate links to explanations, but for now the most pressing is to get a bit of code for these property accesses that works on, at least 3.* and 4 (preferably 2 as well, but I can live without that if it's a massive pain))
Comment 14 :Gijs Kruitbosch 2010-11-05 07:51:32 PDT
(In reply to comment #10)
> (In reply to comment #8)
> > I'm 99.99% sure this change is totally backwards-incompatible. We're going to
> > have to come up with something better.
> 
> That's nice, because i removed only two instances of code with wrappedJSObject,
> removing other ones prevent Chatzilla to connect. So wrappedJSObject lying
> around somewhere.
> 
> > Also, the check which you're removing seems really cautious and benign. Are you
> > saying that right now, there's a wrappedJSObject property - we just can't use
> > it? Because that sounds like a really, really crappy API.
> 
> I know nothing. Just copied patch from bug 606366. I don't have real knowledge
> of all this stuff, trying to move things forward :)

It's appreciated, it got it on my radar at least. Thanks, and my apologies if I seemed harsh in my earlier comment. :-)
Comment 15 Jason Orendorff [:jorendorff] 2010-11-05 14:02:43 PDT
Just to add to the confusion: as far as I know, frame.contentWindow.wrappedJSObject should still work. mrbkap knows more.

What exactly is the change in behavior that's causing this bug?
Comment 16 Tony Mechelynck [:tonymec] 2010-11-06 00:34:37 PDT
(In reply to comment #1)
> Reproducible on my Fedora 13. As a workaround, right click on a tab and select
> Clear Tab.

This will make any new messages appear (on that tab only) but it will also erase (with no chance of looking at it) anything already displayed in that tab, e.g. the startup message in the client tab (with the links to known networks), the MOTD in a network tab, any already displayed replies in a query tab, etc.

I have an additional workaround (#3 below):
1. Connect and join to whatever
2. Clear every tab in turn
3. /reconnect-all (i.e. disconnect-reconnect) to redisplay the MOTD, the join messages etc.

It still doesn't redisplay the startup message on the client tab, of course.
Comment 17 neil@parkwaycc.co.uk 2010-11-06 11:13:07 PDT
XPConnect is seriously broken.

ChatZilla's main problem is that XrayWrappers no longer compare equal to their unwrapped object as they used to in previous versions of Gecko. I don't know if this is intentional, but in case it was, I tried to ensure that I was working with unwrapped objects throughout. Sadly they don't compare equal either.

Start by opening the JS console from a browser window:

>> top.opener.content
> [object XrayWRapper [object Window]]
>> top.opener.content.wrappedJSObject
> [object Window]
>> XPCNativeWrapper(top.opener.content.wrappedJSObject)
> [object XrayWRapper [object Window]]
>> XPCNativeWrapper(top.opener.content.wrappedJSObject) == top.opener.content
> true
>> XPCNativeWrapper(top.opener.content.wrappedJSObject).wrappedJSObject
> [object Window]
>> XPCNativeWrapper(top.opener.content.wrappedJSObject).wrappedJSObject == top.opener.content.wrappedJSObject
> false
Oops.

This is more fun on a debug build, since on a release build you can't see that the underlying object claims to be the same in both cases.
Comment 18 Cyrus Harmon 2010-11-12 10:19:57 PST
*** Bug 611717 has been marked as a duplicate of this bug. ***
Comment 19 Robert Utasi [:hunboy] 2010-11-12 21:44:06 PST
Created attachment 490335 [details] [diff] [review]
patch without wrapper

FF4.0b7 went wrong also and was released.

I tested it in Netscape7.2, FF1, FF1.5, FF2, FF3, FF3.5, FF3.6, FF4.0b6, FF4.0b7

seems to be ok.

only 1 thing is left I don't understand: b6 calls 5 times that function, but b7 calls only once during startup.
Comment 20 Robert Utasi [:hunboy] 2010-11-13 02:46:48 PST
Created attachment 490353 [details]
alternative patch

This one also works tested in all of clients as before, but not so Crappy API :)

I omitted the getContentWindow() calling for some reasons.

I did not make obsolete the first one, actually idk which one will be the more stable for the future, if the things change at the moment.



At getFrameForDOMWindow(window)     (window = webProgress.DOMWindow)

the frame.contentWindow in b7 is
either [object XrayWrapper [object window]] or [object Window]

and in b6 it is always
[object XPCNativewrapper [object Window]]

well, it simply dies in b7 at the first call because:
frame.contentWindow.wrappedJSObject != window

but frame.contentWindow == window

in other calls the .wrappedJSObject sometimes ==window sometimes not
Comment 21 Blake Kaplan (:mrbkap) 2010-11-15 11:47:20 PST
(In reply to comment #17)
> ChatZilla's main problem is that XrayWrappers no longer compare equal to their
> unwrapped object as they used to in previous versions of Gecko. I don't know if
> this is intentional, but in case it was, I tried to ensure that I was working
> with unwrapped objects throughout. Sadly they don't compare equal either.

bug 610390 tracks this last part. Can you report back on how hard it is to normalize one way or the other for == equality? It would be nice to not have xray wrappers compare equal with their "unwrapped" counterparts; but if it's too much of a burden, we could reverse that decision.
Comment 22 neil@parkwaycc.co.uk 2010-11-15 14:40:37 PST
(In reply to comment #21)
> (In reply to comment #17)
> > ChatZilla's main problem is that XrayWrappers no longer compare equal to their
> > unwrapped object as they used to in previous versions of Gecko. I don't know if
> > this is intentional, but in case it was, I tried to ensure that I was working
> > with unwrapped objects throughout. Sadly they don't compare equal either.
> bug 610390 tracks this last part. Can you report back on how hard it is to
> normalize one way or the other for == equality? It would be nice to not have
> xray wrappers compare equal with their "unwrapped" counterparts; but if it's
> too much of a burden, we could reverse that decision.
Currently one side is normalised to be the unwrapped object; the other is sometimes wrapped and sometimes unwrapped (I don't know the call stacks). Comparing wrapped counterparts would therefore be hardest. Comparing unwrapped objects would have been reasonably straightforward, if this had worked...
Comment 23 Hicham 2010-11-18 08:42:49 PST
None of the above patches fixed this issue for me, I am using ChatZilla on Xulrunner-2.0b7
Comment 24 Robert Utasi [:hunboy] 2010-11-18 11:35:54 PST
(In reply to comment #23)
> None of the above patches fixed this issue for me, I am using ChatZilla on
> Xulrunner-2.0b7

Patch the original zip file for XULRunner, and re-generate the chatzilla.exe

suggestion: before re-generating, delete the previous generatum totally perhaps in windows: from the ProgramFiles and from the AppData directory also. (named as ChatZilla subdirectory)

I tested it, works well : CTCP version reply “ChatZilla 0.9.86-2010110623-patch [XULRunner 2.0b8pre/20101117031547]” from utasir
Comment 25 Robert Utasi [:hunboy] 2010-11-18 13:42:40 PST
(In reply to comment #24)

> from the ProgramFiles and from the AppData directory also.

AppData/ChatZilla contains the logs(!) and prefs(!) for personal settings, so carefully(!) of course.
Comment 26 James Ross 2010-11-19 17:15:33 PST
*** Bug 613658 has been marked as a duplicate of this bug. ***
Comment 27 Justin Wood (:Callek) 2010-11-28 20:18:02 PST
I _really_ want cZ working ASAP, but only blocking final on this. [the dependant m-c bug is blocking Firefox beta8] so hopefully our next trunk release will have this fixed.
Comment 28 Glen Mailer 2010-12-07 11:19:51 PST
My understanding is that the fix for bug 610390 should fix this one without any code changes, can anyone confirm on a nightly build?
Comment 29 Luke Iliffe (Harlequin99) 2010-12-07 12:36:06 PST
I am using the win7(32) 2010-12-07 nightly; 
Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre
 
Which contains the fix for bug 610390 and can confirm this bug is *not* fixed. I am using the chatzilla version:
ChatZilla 0.9.86-2010081522 [Firefox 4.0b8pre/20101207030325]
Comment 30 Jens Hatlak (:InvisibleSmiley) 2010-12-07 12:44:32 PST
(In reply to comment #29)
> I am using the win7(32) 2010-12-07 nightly; 
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre
> 
> Which contains the fix for bug 610390 and can confirm this bug is *not* fixed.
> I am using the chatzilla version:
> ChatZilla 0.9.86-2010081522 [Firefox 4.0b8pre/20101207030325]

Same with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre SeaMonkey/2.1b2pre / ChatZilla 0.9.86 [SeaMonkey 2.1b2pre/20101207024811]. Comment 1 still applies.
Comment 31 Robert Utasi [:hunboy] 2010-12-07 12:50:01 PST
also negative on
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre
ChatZilla 0.9.86-2010110623 [Firefox 4.0b8pre/20101207033246]
Comment 32 Tony Mechelynck [:tonymec] 2010-12-07 12:56:25 PST
Yeah, FWIW I still see the bug on Linux on

Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre SeaMonkey/2.1b2pre - Build ID: 20101207033857

Here too, the comment #1 workaround still applies
Comment 33 Serge Gautherie (:sgautherie) 2010-12-07 15:43:27 PST
(In reply to comment #17)
> Start by opening the JS console from a browser window:
> 
> >> top.opener.content
> > [object XrayWRapper [object Window]]
> >> top.opener.content.wrappedJSObject
> > [object Window]
> >> XPCNativeWrapper(top.opener.content.wrappedJSObject)
> > [object XrayWRapper [object Window]]
> >> XPCNativeWrapper(top.opener.content.wrappedJSObject) == top.opener.content
> > true
> >> XPCNativeWrapper(top.opener.content.wrappedJSObject).wrappedJSObject
> > [object Window]
> >> XPCNativeWrapper(top.opener.content.wrappedJSObject).wrappedJSObject == top.opener.content.wrappedJSObject
> > false
> Oops.

[Mozilla/5.0 (Windows NT 5.0; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre SeaMonkey/2.1b2pre] (nightly)

Same results after bug 610390 fix.

(In reply to comment #21)
> bug 610390 tracks this last part.

Are the unchanged results expected or is bug 610390 fix incomplete?
Comment 34 Glen Mailer 2010-12-13 17:26:47 PST
Judging by the comments on bug 610390, this issue is similar but separate, and is still unfixed.

Is anyone able to produce a testcase for this, and submit it as a bug to core XPConnect?
Comment 35 Tony Mechelynck [:tonymec] 2011-01-06 20:51:17 PST
(In reply to comment #34)
> Judging by the comments on bug 610390, this issue is similar but separate, and
> is still unfixed.
> 
> Is anyone able to produce a testcase for this, and submit it as a bug to core
> XPConnect?

A testcase for the present bug? Sure: see comment #0 above, "Steps to Reproduce". You could even add that using /clear in any tab (which ought not to be needed) makes the content of that particular tab display normally from that point on. Of course, messages earlier than the /clear won't be displayed, but they can still be found in the log if logging is in use.

Or did you mean some other kind of testcase?
Comment 36 Serge Gautherie (:sgautherie) 2011-01-07 03:59:41 PST
(In reply to comment #35)

We're currently waiting for bug 620486.
Comment 37 Robert Utasi [:hunboy] 2011-01-15 14:09:14 PST
This problem comes from the progresslistener.
When we open a new tab (perhaps join a channel):

For some reasons the Gecko2.0 calls onStateChange() 5 times instead of 3.
(without patch only once, because failed by wrapper)

And the frame.contentWindow.wrappedJSObject is fake with about:blank at
startup. And weirdly later it switches to the correct one.

Later 1 more problem, the eventhandler is called uselessly, or too early.

***************************************************************************
Gecko2.0 nsIWebProgressListener onStateChange() is called 5(!!!) times
***************************************************************************

--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Is this that window we need?: FALSE wrapped (UGGG)
Is this the current view?: FALSE
Is this same as was before?: JUST STARTED
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Is this that window we need?: FALSE wrapped
Is this the current view?: FALSE
Is this same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------


****** (new current view from now - the freshly opened one)

Channel view for “#test2” opened.
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Is this that window we need?: TRUE wrapped (OH WELLL)
Is this the current view?: TRUE
Is this same as was before?: FALSE (UPPSSS!!!!!!!)
NOT initialized
--------------------------BLOCK END----------------------------------------
Couldn't find a content window or its initOutputWindow function. This is BAD!
(well, its initOutputWindow function)
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Is this that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Is this that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
YOU (utasir) have joined #test2


***************************************************************************
Gecko1.9.2 nsIWebProgressListener onStateChange() is called 3(!!!) times
***************************************************************************

--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Is this that window we need?: TRUE wrapped
Is this the current view?: FALSE
Is this same as was before?: JUST STARTED
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Is this that window we need?: TRUE wrapped
Is this the current view?: FALSE
Is this same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------


****** (new current view from now - the freshly opened one)

Channel view for “#test2” opened.
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Is this that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
YOU (firefox) have joined #test2

this one works.
Comment 38 Robert Utasi [:hunboy] 2011-01-22 22:56:01 PST
more analyze: when we open a new view:
All of Gecko2.0 calls onStateChange()
contains irrelevant calls also where no comparison to wrappedJSObject

--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 65552: STATE_STOP
Status: 2152398850 - NS_BINDING_ABORTED (???)
> Is this wrappedJSObject that window we need?: FALSE wrapped
Is this the current view?: FALSE
Is this wrappedJSObject same as was before?: JUST STRATED
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 131088: STATE_STOP IS_DOCUMENT
Status: 2152398850 - NS_BINDING_ABORTED (???)
Is this wrappedJSObject that window we need?: FALSE wrapped
Is this the current view?: FALSE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Status: 2152398850 - NS_BINDING_ABORTED (???)
> Is this wrappedJSObject that window we need?: FALSE wrapped (dies here)
Is this the current view?: FALSE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: about:blank
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: FALSE wrapped
Is this the current view?: FALSE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
> New view opens
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: FALSE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: FALSE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
> Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
> Is this wrappedJSObject same as was before?: FALSE
NOT initialized
> Why does it change?
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 196612: STATE_TRANSFERRING IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
> Status: 2152398850 - NS_BINDING_ABORTED (why does it happen?)
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 131088: STATE_STOP IS_DOCUMENT
> Status: 2152398850 - NS_BINDING_ABORTED (why does it happen?)
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
> Status: 2152398850 - NS_BINDING_ABORTED (why does it happen?)
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
> dd: Couldn't find a content window or its initOutputWindow function.
> This is BAD!
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 196612: STATE_TRANSFERRING IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65540: STATE_TRANSFERRING
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 131088: STATE_STOP IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
Comment 39 Robert Utasi [:hunboy] 2011-01-22 22:59:10 PST
almost same issue with syncOutputFrame, but that works by manual call
/sync-output on an existing view, because the wrappedJSObject is
correct already at that time.

BUT, also throws dd!!!!

--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: JUST STARTED
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 196612: STATE_TRANSFERRING IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
> Status: 2152398850 - NS_BINDING_ABORTED (why does it happen?)
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 131088: STATE_STOP IS_DOCUMENT
> Status: 2152398850 - NS_BINDING_ABORTED (why does it happen?)
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
> Status: 2152398850 - NS_BINDING_ABORTED (why does it happen?)
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
> dd: Couldn't find a content window or its initOutputWindow function.
> This is BAD!
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 983041: STATE_START IS_NETWORK IS_REQUEST IS_WINDOW IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 196612: STATE_TRANSFERRING IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65540: STATE_TRANSFERRING
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
NOT initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65552: STATE_STOP
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 131088: STATE_STOP IS_DOCUMENT
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 786448: STATE_STOP IS_NETWORK IS_REQUEST IS_WINDOW
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
--------------------------BLOCK START--------------------------------------
Location: chrome://chatzilla/content/output-window.html
StateFlags: 65537: STATE_START
Status: 0
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this the current view?: TRUE
Is this wrappedJSObject same as was before?: TRUE
initialized
--------------------------BLOCK END----------------------------------------
Comment 40 Robert Utasi [:hunboy] 2011-01-22 23:10:32 PST
Created attachment 506192 [details]
patch with wrapper

this one works from now after some bugfixes on the trunk.
Comment 41 Robert Utasi [:hunboy] 2011-01-22 23:12:33 PST
Created attachment 506193 [details]
patch without wrapper

this one basically same as my first patch here months ago, just added NS_BINDING_ABORTED ignrance. I just reupload because in my opinion this one correct also: window to window.
Comment 42 Robert Utasi [:hunboy] 2011-01-22 23:20:32 PST
at the attachment 506192 [details] the comparison works, although the wrappedJSObject is invalid, but at least comparable, so good for ident the window we need to check if still exists or already not.

If these 2 patches still not good, then someone would need file 2 new bugs with proper english, explanation, and component. These are:

1. Why the wrappedJSObject is invalid at startup? (and changes to correct later)

2. Why this throws NS_BINDING_ABORTED permanently every time when we call the frame.loadURL() function?
Comment 43 Andreas Gal :gal 2011-01-22 23:25:54 PST
wrappedJSObject is invalid? can you elaborate on that?
Comment 44 Robert Utasi [:hunboy] 2011-01-22 23:43:11 PST
(In reply to comment #43)
> wrappedJSObject is invalid? can you elaborate on that?

Adreas: please see Comment 38. that is what I'm talking about. it will be valid only at the 7th call of onStateChange because changes. This handler is for ident the correct and existing window we need, if doesn't find, removes that from the listener. This is the problem. On previous versions this wrappedJSObject was same and correct (I mean frame.contentWindow.wrappedJSObject == webProgress.DOMWindow. this is the original code.). Now changes during the startup.
Comment 45 Robert Utasi [:hunboy] 2011-01-23 20:55:12 PST
Andreas: to continue the Comment 44, it will be valid (I mean
frame.contentWindow.wrappedJSObject == webProgress.DOMWindow. this is the
original code.), when it will be outerized.

just a short debug with more info based on Comment 38:

------6th call------------BLOCK START--------------------------------------
Is this wrappedJSObject that window we need?: FALSE wrapped
Is this wrappedJSObject same as was before?: TRUE
What is frame.contentWindow?: [object XrayWrapper [object Window]]
--------------------------BLOCK END----------------------------------------
------7th call------------BLOCK START--------------------------------------
Is this wrappedJSObject that window we need?: TRUE wrapped
Is this wrappedJSObject same as was before?: FALSE
What is frame.contentWindow?: [object Window]
--------------------------BLOCK END----------------------------------------

(So it's an answer to my question "why does it change?" because outerized)
Comment 46 neil@parkwaycc.co.uk 2011-02-03 14:09:46 PST
Comment on attachment 506192 [details]
patch with wrapper

>+    // The "in" operator does not detect wrappedJSObject, so don't bother.
>+    if (webProgress.DOMWindow.wrappedJSObject)
>+        window = webProgress.DOMWindow.wrappedJSObject;
>+    else window = webProgress.DOMWindow;
[I would have put this code in getFrameForDOMWindow instead.]

>                 // This should totally never ever happen. It will if we get in a
>                 // fight with xpcnativewrappers, though. Oops:
>+
>+                // Or after all? NS_BINDING_ABORTED
>+                // The async request cancelled coz it was aborted by some user
>+                // action or it can be some redirect issue. OR rather we get in
>+                // a fight with xpcnativewrappers in Gecko2.0, though. Oops:
>+                if(status == 0x804B0002)
>+                    return;
Out of interest, what does this do?
Comment 47 Robert Utasi [:hunboy] 2011-02-03 15:09:06 PST
Neil: the first part is a syncronisation with the getContentWindow() function from the utils.js. But you are right. This is better:

function getFrameForDOMWindow(window)
{
    var tempwindow;
    // The "in" operator does not detect wrappedJSObject, so don't bother.
    if (window.wrappedJSObject)
        tempwindow = window.wrappedJSObject;
    else tempwindow = window;

    var frame;
    for (var i = 0; i < client.deck.childNodes.length; i++)
    {
        frame = client.deck.childNodes[i];
        if (getContentWindow(frame) == tempwindow)
            return frame;
    }
    return undefined;
}

***

The second part is for pointing to the NS_BINDING_ABORTED problem. Basically not nessesary, except if we want to ignore the dd itself. I had talked to Samuel and uploaded to present the problem itself.

***

(all of patches are backups only, these 2 ones will be r- -ed, I have HG-ed files without NS_BINDING_ABORTED ignorance also (and 1 more as backup-backup), but not nessesary uploading them at the moment.)

***

We still have 2 (blocker) problems (short summary):

1. window.wrappedJSObject != window (although it's not === ) ( Comment 21 )
2. XUL element browser.loadURI() throws 0x804B0002 NS_BINDING_ABORTED
Comment 48 Robert Utasi [:hunboy] 2011-02-03 17:19:06 PST
Created attachment 509651 [details] [diff] [review]
patch with wrapper

backup - modification based on Neil's instructions.
First xulrunner trunk where works: XULRunner 2.0b10pre/20110116030325
Comment 49 Robert Utasi [:hunboy] 2011-02-06 21:54:06 PST
Created attachment 510210 [details] [diff] [review]
patch meta reorder

pratial fix for NS_BINDING_ABORTED problem. It fixes the 2nd series of NS_BINDING_ABORTED, which made the dd. A simple reorder in the html file, meta tag is the first.
Comment 50 Robert Utasi [:hunboy] 2011-02-07 17:34:07 PST
Created attachment 510473 [details]
testcase - NS_BINDING_ABORTED

simplified (so much as possible)

The lately meta tag (content-type) causes NS_BINDING_ABORTED
The html code is embedded with enough long space-sequence. Border case sample.
Tested on: XULRunner 2.0b12pre/20110207030345 (WinXP)
Comment 51 Tim Maks van den Broek [:mad_maks] 2011-02-28 04:37:27 PST
With Firefox 4 coming soon, is this going to be fixed?
Comment 52 John J. Barton 2011-03-05 21:24:05 PST
I'm running the 0.9.86 code in chromebug on FF4.0. The function getContentWindow() is called from getFrameForDOMWindow, but for this purpose it is not correct. (I think getContentWindow() is incorrect altogether).

getFrameForDOMWindow(window) is trying find the client.deck.childNode that whose contentWindow matches the argument. The argument is webProgress.DOMWindow. That object an 'outer window', the API seen by chrome looking at content.  childNode[0].contentWindow is also an 'outer window'.  So we could just say:
    var frame = client.deck.childNodes[i]
    if (frame.contentWindow === window)
       return frame;

The 'patch without wrapper' is the correct one. I think it was blown off course by bug 620486
Comment 53 :Gijs Kruitbosch 2011-03-05 22:56:01 PST
(In reply to comment #52)
> I'm running the 0.9.86 code in chromebug on FF4.0. The function
> getContentWindow() is called from getFrameForDOMWindow, but for this purpose it
> is not correct. (I think getContentWindow() is incorrect altogether).
> 
> getFrameForDOMWindow(window) is trying find the client.deck.childNode that
> whose contentWindow matches the argument. The argument is
> webProgress.DOMWindow. That object an 'outer window', the API seen by chrome
> looking at content.  childNode[0].contentWindow is also an 'outer window'.  So
> we could just say:
>     var frame = client.deck.childNodes[i]
>     if (frame.contentWindow === window)
>        return frame;
> 
> The 'patch without wrapper' is the correct one. I think it was blown off course
> by bug 620486

Do all of your assertions hold on 3.*? Because I don't think so. Additionally, I'm fairly sure the deck.childNode comparisons are not the only case where we use this code.
Comment 54 John J. Barton 2011-03-06 08:32:46 PST
(In reply to comment #53)
> Do all of your assertions hold on 3.*? Because I don't think so. 

The jsWrappedObject property has not changed in a long time as far as I am aware. What has changed is our understanding of what this property means. The documentation and explanations of this property are extra-ordinarily bad and we've all tried to puzzled it out with mixed success. DOM object reference X has two APIs: "X.*" (outer) and "X.wrappedJSObject.*" (inner). They are different, so it never makes sense to compare them.

Except for jsd, I don't believe any nsIDOMWindow reference from XPCOM gives 'inner' API references. The only time you need wrappedJSObject is if you need to look at the values set on DOM objects by JavaScript in the window containing the DOM object.  Those cases should be rare.

(Older code for 'components' uses another property called wrappedJSObject to pass references between components. This property has the same name, similar behavior, but is not related!).

> Additionally,
> I'm fairly sure the deck.childNode comparisons are not the only case where we
> use this code.

I suppose then that they are incorrect as well, but I did not look in to that case.  Based on my experience with doing very much the same kinds of things in Firebug, I guess this kind of code succeeds because ultimately two .wrappedJSObject-s get compared for equality through references which obscure the test. But accessing the inner window is not necessary for most of the things we do and all the funky if (X.wrappedJSObject) X = X.wrappedJSObject code will burn you sooner or later.  I have the scars, that's why I recognize it ;-).
Comment 55 :Mook 2011-03-06 08:51:23 PST
Created attachment 517269 [details] [diff] [review]
alternative patch: unwrap DOMWindow

This does similar things without changing other callsites.

As johnjbarton mentioned, getFrameForDOMWindow is getting a wrapped window (via webProgress.DOMWindow), but it's comparing against the result of getContentWindow() which is unwrapped. This just unwraps everything in comparisons.

Attachment 510210 [details] [diff] fixes the NS_BINDING_ABORTED part - the HTML5 parser defaults to being on now; if it sees a <meta charset> past the first 1024 bytes from the start of the file, it will restart the parse <http://mxr.mozilla.org/mozilla-central/source/parser/html/nsHtml5StreamParser.cpp#932> which is causing the extra state_start/state_stop in the web progress listener.  Since this happens before the assignment to initOutputWindow <http://hg.mozilla.org/chatzilla/file/d5c0d1565064/xul/content/output-window.js#l93> we get a useless warning.
Comment 56 John J. Barton 2011-03-06 08:55:28 PST
(In reply to comment #55)
> Created attachment 517269 [details] [diff] [review]
...
> As johnjbarton mentioned, getFrameForDOMWindow is getting a wrapped window (via
> webProgress.DOMWindow), but it's comparing against the result of
> getContentWindow() which is unwrapped. This just unwraps everything in
> comparisons.

But the correct fix is to unwrap nothing.
jjb
Comment 57 James Ross 2011-03-06 09:01:59 PST
(In reply to comment #56)
> But the correct fix is to unwrap nothing.

Thank you for playing, now please stop making comments about a codebase you do not understand.
Comment 58 John J. Barton 2011-03-06 09:10:55 PST
Well good luck then.
Comment 59 James Ross 2011-03-06 09:50:23 PST
Comment on attachment 490335 [details] [diff] [review]
patch without wrapper

Per discussion on IRC, this is the best acceptable fix.
Comment 60 James Ross 2011-03-06 09:50:44 PST
Comment on attachment 510210 [details] [diff] [review]
patch meta reorder

Per discussion on IRC, this is good to take as well.
Comment 61 :Mook 2011-03-06 09:52:42 PST
Comment on attachment 517269 [details] [diff] [review]
alternative patch: unwrap DOMWindow

Sorry; per IRC discussion with Silver and hunboy, attachment 490335 [details] [diff] [review] is better - it stop unwrapping both sides and is slightly clearer.
Comment 63 Tony Mechelynck [:tonymec] 2011-03-11 15:13:28 PST
Tested on "Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre SeaMonkey/2.1b3pre" ID:20110311003004

The bug has now disappeared. :-) :-) :-) => VERIFIED.
Comment 64 James Ross 2012-07-05 09:52:28 PDT
*** Bug 571956 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.