120209 - Extra blur generated when popup windows open

Status: VERIFIED FIXED

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

Description

[Brian Ryner (not reading)]

When a javascript popup window opens on Linux, we do something like:

focus html document
focus xul document
focus html document

whereas on win32, the first focus of the html document doesn't exist.  The net
effect of this is that any popup window that has an onblur handler that closes
the window (which appears to not be uncommon), will close immediately.

Sites that demonstrate this bug:

http://www.c2it.com  (from bug 107844)
http://www.panasonic.de/www/ProduktSrv/de/produkte/8431401440?InfoID=120708&RUBRIK=-1
  (from bug 104297)
http://www.desktop-fx.com/wallpaper/pat_texture_001.htm (from bug 109645)

CC'ing people from all of these bugs, since my crash fix now exposes this problem.

Comment 1

[[e-mail]]

two more sites from bug http://bugzilla.mozilla.org/show_bug.cgi?id=123591 :
http://www.parker.gr/engjotter.html and
http://www.vudumedia.com/butano/ganadores.htm

It seems that this is a commonly used technique ... 

Comment 2

[Brian Ryner (not reading)]

Ok, I believe I've tracked down what's going on here, and why this happens on
Linux but not Windows.

On windows, we get a synchronous focusing of the webshell window as a result of
showing the widget (i.e. from window.open()).  We then focus the HTML document
when window.focus() happens.   That's all fine.

On linux, focus does not happen synchronously when a window is shown.  So, we
continue executing the script and focus the HTML document.  Then, at some later
time, we get a NS_GOTFOCUS for the webshell window, followed by NS_ACTIVATE. 
This causes the toplevel document (the chrome document) to take focus; at that
point the onblur handler on the HTML document fires and the window is closed. 
Note that if no onblur handler was attached, the succeeding NS_ACTIVATE would
restore focus memory and focus the HTML document.  So, aside from DOM events
firing that shouldn't, focus will generally end up in the correct place.

saari and I talked about a possible fix which involves not firing a blur event
during NS_GOTFOCUS if the focus controller is suppressed and it also has a
different window as its focused window.

Comment 3

[Brian Ryner (not reading)]

Attachment: preliminary patch

This is the fix saari and I discussed (I think).  It seems to fix this problem
nicely, but it needs the usual battery of focus regression tests run against
it.

Comment 4

[Brian Ryner (not reading)]

I've been running with this patch in my tree for a couple of weeks and haven't
noticed any bad effects from it. saari, can you r=?

Comment 5

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 6

[John Morrison]

bryner, did you want to go forward with landing this patch?

Comment 7

[saari (gone)]

I'm doing a build right now on Mac, lemme run this through some quick tests and
I'll r=

Comment 8

[saari (gone)]

Comment on attachment 70193 [details] [diff] [review]
preliminary patch

Add some comments describing what you're doing and this bug number, and go for
it. I can't break anything testing on mac. r=saari with comments

Comment 9

[Darin Fisher]

Comment on attachment 70193 [details] [diff] [review]
preliminary patch

sr=darin (looks good)

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 70193 [details] [diff] [review]
preliminary patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 11

[Brian Ryner (not reading)]

checked in.

Comment 12

[Joe Chou]

Fix has been checked into Sun's 6.2.1 branch.

Comment 13

[Joe Chou]

*** Bug 124285 has been marked as a duplicate of this bug. ***

Comment 14

[R.K.Aa.]

with a 3 hour old CVS build, Linux, all links at
http://www.parker.gr/engjotter.html spawn a window that immediately closes
again. Is that another bug then?

Comment 15

[Brian Ryner (not reading)]

No, same bug.  Damn.

Comment 16

[Brian Ryner (not reading)]

Well, almost the same bug.

The difference here is that the popup window is opened via a mousedown handler,
so there is an odd ordering dependency because script event handlers are run
first.  In this case, the script event handler opens a new window and
deactivates the original window, then the anchor element takes focus and
deactivates the popup window, so it gets a blur.  It may be that we're actually
doing the right thing and this is poorly written HTML (certainly the problem
could be avoided if the author opened the popup via onclick instead of onmousedown).

Comment 17

[Peter Trudelle]

What is the impact of this bug on typical users?  Why would it be needed for MachV?

Comment 18

[Brian Ryner (not reading)]

I spun off the second issue to bug 131651.  Marking this bug Fixed.

Comment 19

[Rakesh Mishra]

verified on the trunk build 2002-04-25-10-trunk on Linux Red hat 7.2