ChatZilla Broken - Does not display anything in the message window.

VERIFIED FIXED

Status

Other Applications
ChatZilla
VERIFIED FIXED
7 years ago
3 years ago

People

(Reporter: therube, Assigned: hunboy)

Tracking

({regression})

Trunk
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -, blocking-seamonkey2.1 final+)

Details

(Whiteboard: [cz-0.9.86.1])

Attachments

(6 attachments, 3 obsolete attachments)

(Reporter)

Description

7 years ago
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

7 years ago
Reproducible on my Fedora 13. As a workaround, right click on a tab and select Clear Tab.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All

Comment 2

7 years ago
Same regression range as Bug 604493 so probably also caused by the latest tracemonkey merge. Probably suspect is the new compartments feature.
Assignee: nobody → rginda
Severity: major → normal
Component: General → ChatZilla
Product: SeaMonkey → Other Applications
QA Contact: general → chatzilla
Version: unspecified → Trunk
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101022 Firefox/4.0b8pre

i see the same problem here, workaround of #1 works.
Should this block beta7? It's a pretty ugly compartments regression.
blocking2.0: --- → ?

Updated

7 years ago
Blocks: 580128
"blocking-seamonkey2.1=?":
The workaround is fine for developers, but would not be for release, I think.
blocking-seamonkey2.1: --- → ?
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

7 years ago
Created attachment 488439 [details] [diff] [review]
fix

You-re right Stefan. This patch fixes it for me.
Assignee: rginda → misak.bugzilla
Status: NEW → ASSIGNED
Attachment #488439 - Flags: superreview?(rginda)
Attachment #488439 - Flags: review?(rginda)

Updated

7 years ago
Attachment #488439 - Flags: superreview?(rginda)
Attachment #488439 - Flags: superreview?(gijskruitbosch+bugs)
Attachment #488439 - Flags: review?(rginda)
Attachment #488439 - Flags: review?(gijskruitbosch+bugs)

Comment 8

7 years ago
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.
Attachment #488439 - Flags: superreview?(gijskruitbosch+bugs)
Attachment #488439 - Flags: review?(gijskruitbosch+bugs)
Attachment #488439 - Flags: review-

Comment 9

7 years ago
I incorporated that patch in my SM 20101030 chatzilla.jar. Bless you Misak!

Comment 10

7 years ago
(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 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.?.
(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

7 years ago
(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

7 years ago
(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. :-)
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?
(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.
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.

Updated

7 years ago
Duplicate of this bug: 611717
(Assignee)

Comment 19

7 years ago
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.
(Assignee)

Comment 20

7 years ago
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
(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.
Depends on: 610390
(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

7 years ago
None of the above patches fixed this issue for me, I am using ChatZilla on Xulrunner-2.0b7
(Assignee)

Comment 24

7 years ago
(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
(Assignee)

Comment 25

7 years ago
(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.

Updated

7 years ago
Duplicate of this bug: 613658
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.
blocking-seamonkey2.1: ? → final+

Comment 28

7 years ago
My understanding is that the fix for bug 610390 should fix this one without any code changes, can anyone confirm on a nightly build?
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]
(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.
(Assignee)

Comment 31

7 years ago
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]
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
(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?
Keywords: regression

Comment 34

7 years ago
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?
blocking2.0: ? → -

Updated

7 years ago
Depends on: 620486
Depends on: 620487

Updated

7 years ago
No longer depends on: 620486

Updated

7 years ago
Depends on: 620486
No longer depends on: 610390, 620487

Updated

7 years ago
No longer depends on: 620486
Depends on: 620486
(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?
(In reply to comment #35)

We're currently waiting for bug 620486.
(Assignee)

Comment 37

6 years ago
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.
(Assignee)

Comment 38

6 years ago
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----------------------------------------
(Assignee)

Comment 39

6 years ago
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----------------------------------------
(Assignee)

Comment 40

6 years ago
Created attachment 506192 [details]
patch with wrapper

this one works from now after some bugfixes on the trunk.
Attachment #506192 - Flags: review?(samuel)
(Assignee)

Comment 41

6 years ago
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.
Attachment #506193 - Flags: review?(samuel)
(Assignee)

Comment 42

6 years ago
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

6 years ago
wrappedJSObject is invalid? can you elaborate on that?
(Assignee)

Comment 44

6 years ago
(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.
(Assignee)

Comment 45

6 years ago
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 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?
(Assignee)

Comment 47

6 years ago
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
(Assignee)

Updated

6 years ago
Attachment #506193 - Attachment is obsolete: true
Attachment #506193 - Attachment is patch: false
Attachment #506193 - Flags: review?(samuel)
(Assignee)

Updated

6 years ago
Attachment #490353 - Attachment is obsolete: true
Attachment #490353 - Attachment is patch: false
(Assignee)

Updated

6 years ago
Attachment #490335 - Attachment description: patch → patch without wrapper
(Assignee)

Updated

6 years ago
Attachment #506192 - Attachment is obsolete: true
Attachment #506192 - Attachment is patch: false
Attachment #506192 - Flags: review?(samuel)
(Assignee)

Comment 48

6 years ago
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
(Assignee)

Comment 49

6 years ago
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.
(Assignee)

Comment 50

6 years ago
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)
With Firefox 4 coming soon, is this going to be fixed?

Comment 52

6 years ago
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

6 years ago
(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

6 years ago
(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

6 years ago
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.
Attachment #517269 - Flags: review?

Comment 56

6 years ago
(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

6 years ago
(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.

Updated

6 years ago
Attachment #517269 - Flags: review? → review?(gijskruitbosch+bugs)

Comment 58

6 years ago
Well good luck then.

Comment 59

6 years ago
Comment on attachment 490335 [details] [diff] [review]
patch without wrapper

Per discussion on IRC, this is the best acceptable fix.
Attachment #490335 - Flags: review+

Comment 60

6 years ago
Comment on attachment 510210 [details] [diff] [review]
patch meta reorder

Per discussion on IRC, this is good to take as well.
Attachment #510210 - Flags: review+

Comment 61

6 years ago
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.
Attachment #517269 - Flags: review?(gijskruitbosch+bugs) → review-

Updated

6 years ago
Assignee: misak.bugzilla → utasir
http://hg.mozilla.org/chatzilla/rev/979c8305b12e
http://hg.mozilla.org/chatzilla/rev/673364eba045
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED

Updated

6 years ago
Whiteboard: [cz-0.9.86.1]

Updated

5 years ago
Duplicate of this bug: 571956
You need to log in before you can comment on or make changes to this bug.