delayed until toolbar buttons moused over

VERIFIED FIXED in mozilla0.8



18 years ago
18 years ago


(Reporter: hoju, Assigned: danm.moz)


Windows 2000

Firefox Tracking Flags

(Not tracked)




(2 attachments)



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

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

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

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


Comment 1

18 years ago
similar to bug 49120?

Comment 2

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

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.

Priority: P3 → P1

Comment 3

18 years ago
closing this bug.

Refer to bug 53683 for further problems with

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

Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 4

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


Comment 5

18 years ago
Ok, the behavior is back in build 2000100520 M18 Win32

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

Resolution: WORKSFORME → ---

Comment 6

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


Comment 7

18 years ago
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.
Ever confirmed: true
Looks like we're dropping events, or not delivering events correctly,
reassigning to danm.
Assignee: jst → danm

Comment 9

18 years ago
Created attachment 17783 [details]
testcase html file one

Comment 10

18 years ago
Created attachment 17784 [details]
test case html file two

Comment 11

18 years ago

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.


Comment 12

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

Comment 13

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

Comment 14

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

Comment 15

18 years ago
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.
Depends on: 56337
Target Milestone: --- → M19

Comment 16

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

Comment 17

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

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

Comment 19

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

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

Comment 21

18 years ago
This was more fallout from worker threads' occasionally going AWOL.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
Target Milestone: M19 → mozilla0.8

Comment 22

18 years ago
Verified with 2001-02-06-08-Mtrunk.
You need to log in before you can comment on or make changes to this bug.