55032 - window.open delayed until toolbar buttons moused over

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Jacob Kjome]

This problem just showed its ugly head on yesterday's build.  Hadn't seen this 
before that.  That is, build 2000100208.  This is on the Mozilla M18 branch.  
Haven't tested NSPR3 branch.

Open the following URL:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15296

Now click on either "List all links on this page" or the "Open a normal page" 
links.

Notice that no browser pops up at all.  Now, go an mouseover any of the toolbar 
buttons including Back, Forward, Reload, Stop, Search, Print, and any of the 
tabs that hide/show the toolbar features.  The new window will then be created.

Note, there should be a scrollbar when opening the "List all links on this 
page" link, but there won't be now.  This was filed as bug 53683

http://bugzilla.mozilla.org/show_bug.cgi?id=53683

This is bizarre behavior.  This is an absolute MUST fix for RTM!!!!


Jake

Comment 1

[sean echevarria]

similar to bug 49120?

Comment 2

[Jacob Kjome]

This particular problem seems to be fixed, but now, when windows open, they are 
loaded initially with a gray-blue background (as if they are opening as an 
about:blank) and then they load the page they are supposed to load.

An even greater problem exists when dynamically writing data to the new 
window.  The data doesn't even get displayed.  See my comments here:

http://bugzilla.mozilla.org/show_bug.cgi?id=53683

You can try this out by trying the attachement that I made to that bug; the url 
of which is included in my initial description of this bug.

Jake

Comment 3

[Jacob Kjome]

closing this bug.

Refer to bug 53683 for further problems with window.open

See my previous comments for symptoms and a more detailed description is said 
bug.

Jake

Comment 4

[Keyser Sose]

Works For Me:
OS: Windows 98
Platform: PC
Mozilla Build #: 2000100508

Comment 5

[Jacob Kjome]

Ok, the behavior is back in build 2000100520 M18 Win32

you have to mouseover toolbar buttons in order to have a window.open pop up.

Jake

Comment 6

[Jacob Kjome]

Things are better now, but I found that if you keep opening the new window a 
good number of times, it gets back to the point where it delays until you 
mouseover the toolbar buttons.  It is as if there is some resource leak and it 
just isn't recovering.

Jake

Comment 7

[Bob Clary [:bc] (inactive)]

Confirmed with Mozilla 2000101320 on Win2k/SP1.

Visited URL above. Clicked on first link.  Opened window ok but without
scrollbars.  Did a back to the bug page and selected the URL again.  This time,
clicking the link did not open the window until moused over the toolbar buttons.

For scrollbar related issues see Bug 55334.

Comment 8

[Johnny Stenback (:jst)]

Looks like we're dropping events, or not delivering events correctly,
reassigning to danm.

Comment 9

[Henrik Gemal]

Attachment: testcase html file one

Comment 10

[Henrik Gemal]

Attachment: test case html file two

Comment 11

[Jacob Kjome]

Henrik, 

There seems to be a problem with the script in test case HTML file two:

"opener has no properties"

Also, I added you to the cc so you get this message.  Remove it from the cc 
field later if you like.

Jake

Comment 12

[Henrik Gemal]

Testcase on tries to open testcase two.
So just save the files the same place...

Comment 13

[Jesse Ruderman]

*** Bug 57632 has been marked as a duplicate of this bug. ***

Comment 14

[bht237]

Would http://bugzilla.mozilla.org/show_bug.cgi?id=60842 help?
Drops onload event. It has an extremely simple testcase that reproduces always.
Another simple one that drops an onload event and reproduces always is
http://bugzilla.mozilla.org/show_bug.cgi?id=57636

Comment 15

[Dan M]

This looks like more fallout from nsThreadPool's October 1st decision to delete 
"unused" worker threads. It's a little overzealous. The problem is understood; a 
fix is in the works.

Comment 16

[rusty.lynch]

*** Bug 60522 has been marked as a duplicate of this bug. ***

Comment 17

[rusty.lynch]

For what it's worth I can verify in my build that the changes in
nsThread.cpp/nsThread.h are the root of the problem. Where as the window.open
strangness is hard to reproduce in the full xul mozilla browser, TestGtkEmbed
produces the bug everytime.

Moving nsThread.cpp/nsThread.h to just before the Oct 1 checkin works fine, and
them updating to include the checkin reproduces the bug.

Comment 18

[rusty.lynch]

*** Bug 60338 has been marked as a duplicate of this bug. ***

Comment 19

[K Carter]

Looks like the checkin for bugs 55032,56337,58404, and 60338 on 11/28/2000 14:38 
increased Tinderbox leaks by 4 bytes.

Comment 20

[Dan M]

'sokay. I added four bytes to the size of an object that was already leaking.

Comment 21

[Dan M]

This was more fallout from worker threads' occasionally going AWOL.

Comment 22

[Prashant Desale]

Verified with 2001-02-06-08-Mtrunk.