Closed Bug 62270 Opened 24 years ago Closed 21 years ago

Pop up window behind the parent one onUnload

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: minghua.li, Assigned: danm.moz)

References

Details

Attachments

(2 files)

HTML testcase for "Try 1" above
436 bytes, text/html
Details
HTML testcase for "Try 2" above
539 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) BuildID: Try 1: <body onUnload = "window.open('http://www.yahoo.com');"> will pop up a window, but behind the opener window. Previously, the opened window is in front of the opener window. If we just knock off the window with this onUnload event, a new window pops up and disappears right away. Try 2: <script language="javascript"> urlString = "daughterWin=window.open('http://www.yahoo.com');"; window.onunload= eval(new Function(urlString)); </script> has the same behavior as Try 1 above. <script language="javascript"> urlString = "daughterWin=window.open('http://www.yahoo.com');"; function redirect(){eval(urlString);} eval(window.onunload=redirect); </script> has the same behavior as above. In order to correct the problem I have tried to use: DaughterWin.focus() to bring the popup window to the front, and also tried Window.blur() to bring the parent window to be behind the daughter window. But neither of them works. I would appreciate if someone can help to solve this problem with Netscape 6. Reproducible: Always Steps to Reproduce: put this JavaScript into an HTML file and load it. Click reload button on the browser to generate the unload event. <script language="javascript"> urlString = "daughterWin=window.open('http://www.yahoo.com');"; window.onunload= eval(new Function(urlString)); </script> Actual Results: the daughter window pops up in the back Expected Results: the daughter window pops up to the front window.blur() and daughterWin.focus do not work too.
Duplicate of bug 53350 - "Parent window forces itself above child popup window" Minghua, I've cc'ed you on that bug so you can follow its progress - Note in particular this comment from bug 53350: ------- Additional Comments From John Morrison 2000-10-04 19:11 ------- relnote: workaround is to do the window.open in the body onload handler, instead of calling the window.open in an inline script. (I believe most popup ads are already launched via the onload handler, otherwise, popups would be disappearing on many more web pages). *** This bug has been marked as a duplicate of 53350 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Marking Verified -
Status: RESOLVED → VERIFIED
I need to re-open this bug because it is not the same as Bug 53350. Bug 53350 is about the problem with onload daughter window pop up, the Bug I reported is about onUnload daughter window pop up. onload and onUnload are completely different.onload != onUnload
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Reassigning to XP Apps, to match bug 53350. What the two bugs have in common is that window.open isn't working in-line. The current bug does raise a different problem, however: if window.open works inside an onLoad handler (as stated in bug 53350), but doesn't work inside an onUnload handler (as stated in this bug), then this is a new issue.
Assignee: rogerl → don
Component: Javascript Engine → XP Apps
QA Contact: pschwartau → sairuh
Reassigning to danm, to match bug 53350. However, I am unable to reproduce the bug with "Try 1" above. When I try it, the Yahoo window always comes up on top! Using a debug build 2000-12-01 (MN6 branch) on WinNT, and also a WinNT commercial build 20001105, from a while back. Will keep trying. Minghua, what date was your build?
Assignee: don → danm
Using debug builds 2000-12-01(MN6 branch) on WinNT, Linux. Confirming bug on WinNT. OK, I am able to reproduce this on WinNT (but not on Linux). On WinNT, if I click on either the "Try1" or the "Try2" attachment above, the daughter window opens behind the parent window. We expect Try2 to fail currently, because of bug 53350: window.open is not working when it is in-line. Try 1, on the other hand, uses window.open within the onUnload handler of the body element, yet still fails. On Linux, the daughter windows appear in front of the parent window for both Try 1 and Try 2. Observation: on WinNT, if I save the attachments locally, the behavior is more unpredictable. Sometimes the daughter window appears in front of the parent window, sometimes it doesn't...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Note: on WinNT, here is what IE4.7 and NN4.7 do on "Try1", "Try2" above. IE4.7: Try 1: doesn't even bring up a daughter window! Try 2: the daughter window comes up in front NN4.7: Try 1: the daughter window comes up in front Try 2: the daughter window comes up in front
QA Contact: sairuh → claudius
QA Contact: claudius → jrgm
note: seems related to bug 53350, bug 57841
Target Milestone: --- → Future
nav triage team: Nominating for nsbeta1. Need xptoolkit to comment whether or not they'll fix for next release of NS6
Keywords: nsbeta1
Blocks: 104166
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 unable to reproduce this bug with testcase 1 or testcase 2. but I thought these pop-unders were also blocked by Mozilla?
Thomas: if you didn't allow popups from bugzilla, you weren't testing this bug. Nevertheless, both testcases (attachments 1 and 2) present windows in the correct stacking order in my Suite 20040609 build and my Firefox 20040725 build. This was no doubt some focus/activation glitch that got sorted out sometime in the 3 1/2 years between now and the time this bug was filed. Closing WFM.
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → WORKSFORME
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: