Closed Bug 31426 Opened 26 years ago Closed 23 years ago

onBlur=close() and make it snappy

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: vince.webb, Assigned: saari)

References

Details

(Keywords: crash, testcase, Whiteboard: [nsbetadenied])

Attachments

(5 files)

<BODY onBlur=window.close()>
206 bytes, text/html
Details
A different test that shows it works OK
702 bytes, text/html
Details
stack trace, 5/21 PC/Linux (in nsContainerFrame::Destroy)
3.08 KB, text/plain
Details
Popup child window with <body onblur="window.close();">
801 bytes, text/html
Details
Parent/opener of the popup window that has onblur="window.close();"
1.06 KB, text/html
Details
<BODY onBlur=window.close()> The first Blur event gets lost and nothing happens. The window closes on the second Blur. Netscape 4 closes on the first.
The above relates to Mozilla 2000031013
The second attachment i.e. the test that works, applies the onBlur=close() in windows that were opened dyamically, thus it is closer to a real life use of onBlur=close(). Just why the test in the first attachment fails is a mystery to me.
vince@vincew.demon.co.uk - are you still seeing this problem on recent builds of Mozilla? Gerv
I tried running the 2 attachments again this time with 2000041309 id=6410 is as before, the window closes on the second blur event id=6496 was working last month, it crashes 2000041309 ............. Vince
Confirming, adding crash keyword (see previous comment). Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Upgrading severity, as this is a crash bug. Gerv
Severity: normal → critical
Changing OS to All. Crash reproduced on PC/Linux with 5/21 and 5/27 builds. Steps to reproduce: 1) load the second attachment (03/13/00 16:34) 2) click on the link to create new windows. Three little windows will appear. 3) click into one of them, and then move the mouse out of it. This will crash.
OS: Windows 95 → All
The most similar crash I could find is in bug 39889 "Crash on exit"
Just pulled and built on NT. I do not see a crash. Does Linux still crash? The blur bug is still there.
Tested on Linux with fresh pull & build on 2000-07-20. It does not crash, but using the second test case you cannot dismiss the popup windows at all. The console shows: JavaScript error: line 0: JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "<unknown>"] Since I cannot crash anymore I am taking away the crash keyword and dropping the severity to major.
Severity: critical → major
Keywords: crash
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
HTML 4.01 does not actually define that BODY element should have onblur/onfocus attributes. But since NS 4.x and IE do this, adding 4xp keyword.
Keywords: 4xp
I am starting to think the JS created windows do not get the focus/blur events when they are created. Once they are up, and if I click on one and then change to another window the blur event closes the window.
Assigning to saari
Assignee: joki → saari
Per heikki, saari, ckritzer: This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
Lads, you can't "future" a crashing bug, surely? Could you have another look at this one? Gerv
Keywords: crash
Gervase, please confirm that you do see a crash, and say the build & platform. I removed the crash keyword because it was no longer crashing. By the way, there are several crashers futured anyway... (or at least there were).
This bug has indeed gone away in today's build (2000-08-28-08). On the other hand, the bahavior that is expected (?) of onBlur in the second test case (03/10/ 00) seems to have been killed as well. Anyone have ideas here? Mac OS9 running PR2 case 1: Pr2 dies, crashes and burns. Mac OS9 running 2000-08-28-08 case 1: Closes window (with no way of opening another or quitting, may I add) as it should close window, with other side effects Mac OS9 running 4.74: Closes window. Wow.:) Mac OS9 running PR2 case 2: Windows do not close when onBlur should be called. Mac OS9 running 2000-08-28-08: Windows do not close when onBlur should be called. Mac OS9 running 4.74: Closes window when you jump to another window as it should. IOW, its working as it should. In any event, I'm no longer seeing a crash here.
Changing Platform to "All" since Mac OS 9 also seems to be affected by issues in onBlur.
Hardware: PC → All
Severity: major → critical
Keywords: nsbeta3
Uh oh... Tested on Linux commercial debug build (just pulled and built), and I see crash with test case 1. Steps to reproduce:
Marking as [nsbeta3-] a number of bugs that were already marked Future (but not [nsbeta3-]) because the Netscape engineer the bug is assigned to is overburdened. If you disagree with this decision, please provide information about customer and user impact, but please do not clear the [nsbeta3-] unless you are reassigning the bug to yourself and committing to a fix within the nsbeta3 timeframe.
Whiteboard: [nsbeta3-]
Doh, I see my comment didn't make it (bug in submit). It was supposed to say something like: open this bug report, open the test case into another window, click on the content area, click back into the first window -> crash.
Updating QA Contact.
QA Contact: ckritzer → lorca
Crash, but in an uncommon situation. Targeting Mozilla 0.9
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
changins Status for my reference. Was NSBETA3-.
Whiteboard: [nsbeta3-] → [nsbetadenied]
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
->joki, per saari's punt
Assignee: saari → joki
Status: ASSIGNED → NEW
Taking back and putting in the furture list after talking with Tom. He already has a dup of the crasher part of the bug (31847), so I'm removing the crash key work and making this depend on that.
Assignee: joki → saari
Depends on: 31847
Target Milestone: mozilla0.9 → Future
Related to bug 58419?
I believe this may be fixed. In testing 58419 (a bug on general window.close behavior) I seemed to get appropriate onblur=self.close() behavior. But saari knows more of the complex blur behavior so I'll let him decide if there is still some odd case where the blur does not fire.
I have tried both the test cases with 2001042604 under windows 95, a blur/focus issue remains. I don't want to tell anyone how to suck eggs here but running the tests was enlightening for me, I hope my observations are of use. I thought a window was either in focus or not, i.e. blurred. Mozilla demonstrates a 3rd state, highlighted but not in focus. The onBlur event is not being actioned unless the user has previously clicked in the CONTENT of the window to make sure it not only highlighted but also focussed. Regards ......... Vince
QA contact updated
QA Contact: gerardok → madhur
*** Bug 93800 has been marked as a duplicate of this bug. ***
I have run the second test case again using Mozilla 0.9.7 20011221 It is no longer necessary to click on the CONTENT of a window for it to become sufficiently focussed for the onBlur to get actioned. This is good. It seems to behave OK even though it is not the same as Netscape or IE. They both action the onBlur=window.close()on win0 and win1 as win1 and win2 are opened. ......... Vince
Keywords: nsbeta3
QA Contact: madhur → rakeshmishra
QA Contact: rakeshmishra → trix
This doesnt crash for me, also tested what was mentioned in comment 25 without crash. Remove crash keyword? 2002122704, XP. Though the close() still triggers twice. Seing: "Scripts may not close windows that were not opened by script." 2 times in the Javascript console.
I have run both test cases using Mozilla 1.2.1 20021130. The second works just fine, the same as Netscape 4 and IE. In the first test case the window does not get closed, nor does the user get prompted to ask if it should be closed.
Vince, the message you expect is in the javascript console
The first attachment (attachment 6410 [details]) is simply incorrect: you can't close a window which was not opened by a script or the last opened window. The second attachment has coding difficulties and is not a reduced testcase. var win = window.open('',name,features,''); win.document.writeln('<HTML><HEAD><TITLE>' + name + '</TITLE></HEAD>' - win.document.open(); is needed in there. http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-72161170 - forward slashes / are not escaped when constructing the string I do not know if this would cause the problem in the code; I also wonder if generating the document content and the document itself do not complicate the purpose of the testcase. The 3 windows are created as part of an on-going code being executed. The onblur event is not fired because of such execution. I question the relevancy of the testcase also; the summary of the bug is much more modest. Finally, onblur is not even a valid event attribute for the body element: http://www.w3.org/TR/html401/struct/global.html#edef-BODY Testcase coming anyway
This is the child popup window.
This test case WFM perfectly. XP Pro SP1, build 2002122408. For many reasons, I believe this bug should be resolved . I even wonder if it should not be resolved as WONTFIX or as INVALID. My 2 cents.
fails on 2003021808 win2k does not any windows in front of browser. It should bring atleast one - javascript console, dos prompt. I understand there is a security concern with pushing the browser all the way to the bottom of the list of open windows.
All testcases attached to bug WFM with 2003041416/trunk/W2K Marking such.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: testcase
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: