onBlur=close() and make it snappy




Event Handling
18 years ago
15 years ago


(Reporter: Vince Webb, Assigned: saari (gone))


({crash, testcase})

crash, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbetadenied])


(5 attachments)



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

Comment 1

18 years ago
Created attachment 6410 [details]
<BODY onBlur=window.close()>

Comment 2

18 years ago
The above relates to Mozilla 2000031013

Comment 3

18 years ago
Created attachment 6496 [details]
A different test that shows it works OK

Comment 4

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


Comment 6

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

Ever confirmed: true
Keywords: crash
Upgrading severity, as this is a crash bug.

Severity: normal → critical

Comment 9

18 years ago
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
Created attachment 9287 [details]
stack trace, 5/21 PC/Linux  (in nsContainerFrame::Destroy)
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:

Since I cannot crash anymore I am taking away the crash keyword and dropping the
severity to major.
Severity: critical → major
Keywords: crash

Comment 14

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

Comment 17

18 years ago
Assigning to saari
Assignee: joki → saari

Comment 18

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

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 

Comment 21

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

Comment 22

18 years ago
Changing Platform to "All" since Mac OS 9 also seems to be affected by issues in 
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.

Comment 26

17 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca

Comment 27

17 years ago
Crash, but in an uncommon situation. Targeting Mozilla 0.9
Target Milestone: Future → mozilla0.9

Comment 28

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

Comment 30

17 years ago
->joki, per saari's punt
Assignee: saari → joki

Comment 31

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

Comment 32

17 years ago
Related to bug 58419?

Comment 33

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

Comment 34

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

Comment 35

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 36

17 years ago
*** Bug 93800 has been marked as a duplicate of this bug. ***

Comment 37

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


16 years ago
QA Contact: madhur → rakeshmishra


15 years ago
QA Contact: rakeshmishra → trix

Comment 38

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

Comment 39

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

Comment 40

15 years ago
Vince, the message you expect is in the javascript console

Comment 41

15 years ago
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.
- 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:

Testcase coming anyway

Comment 42

15 years ago
Created attachment 110355 [details]
Popup child window with <body onblur="window.close();">

This is the child popup window.

Comment 43

15 years ago
Created attachment 110356 [details]
Parent/opener of the popup window that has onblur="window.close();"

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.

Comment 44

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

Comment 45

15 years ago
All testcases attached to bug WFM with 2003041416/trunk/W2K
Marking such.
Last Resolved: 15 years ago
Keywords: testcase
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.