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
similar to bug 49120?
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
Priority: P3 → P1
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Works For Me: OS: Windows 98 Platform: PC Mozilla Build #: 2000100508
Status: RESOLVED → VERIFIED
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
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Looks like we're dropping events, or not delivering events correctly, reassigning to danm.
Assignee: jst → danm
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
Testcase on tries to open testcase two. So just save the files the same place...
*** Bug 57632 has been marked as a duplicate of this bug. ***
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
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.
Status: NEW → ASSIGNED
Depends on: 56337
Target Milestone: --- → M19
*** Bug 60522 has been marked as a duplicate of this bug. ***
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.
*** Bug 60338 has been marked as a duplicate of this bug. ***
Looks like the checkin for bugs 55032,56337,58404, and 60338 on 11/28/2000 14:38 increased Tinderbox leaks by 4 bytes.
'sokay. I added four bytes to the size of an object that was already leaking.
This was more fallout from worker threads' occasionally going AWOL.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Target Milestone: M19 → mozilla0.8
Verified with 2001-02-06-08-Mtrunk.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.