Closed Bug 31426 Opened 25 years ago Closed 21 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: 21 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: