178339 - "Open link in new window" causes window to partially lose focus

Status: NEW

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

Description

[slice1900]

Using Moz 1.2b (build id 2002101612) on Linux.  This has been happening as long
as I can remember but I haven't reported it until now since there were other
more annoying things to worry about and there were enough focus-related problems
coming and going I didn't want to mention it until now.  It is probably
occurring on more than just Linux, if no one else verifies it does/doesn't
happen on Windows in a day or two I'll check myself.

To reproduce:

Visit any web page with links, and make sure you can hit spacebar to scroll down
 (same behavior as the page down key)

Find a link you like, and using either the context menu item "open link in new
window" or the middle mouse button (if you have it configured to do the same
thing) create a new window.

Expected behavior:

You can mouse over to the old window to raise it to the front, and still be able
to hit spacebar to advance it.

Actual behavior:

Spacebar does nothing, but page up/down do work (which is why I claim that
"partial" focus has been lost)  This persists even after you close that new window.

You can click in that window to get full focus back, or hit another key to
initiate a fast find (I think that's what its called) where it'll find links for
you matching what you type.  Once you have hit a key there the spacebar
magically starts working again.  But page up/down strangely do not magically fix
the spacebar.  Yes, this is very strange, but it is a big annoyance to me since
I scroll forward using the spacebar most of the time, and have to constantly
click in the window to regain focus -- it makes browsing the hypermail
linux-kernel archives extremely painful for me :)

Compare and contrast with the behavior you get by selecting File->New to create
a new blank window.  Then if you mouse back over to the old window, you can
still use spacebar to advance it.

Comment 1

[slice1900]

This doesn't seem to occur on Windows.  I gave it a try with 1.2b on Windows XP,
and when I opened the new window the spacebar acted properly on the new window,
as is the case on Linux.  When I closed that window, the spacebar acted properly
on the old window, which is the expected behavior, so the bug I see on Linux is
not exhibited on the Windows version.

Comment 2

[Torben]

Focus issues are tracked in bug 140346, you should look there and try to find a
duplicate.

Comment 3

[slice1900]

Very interesting...

I was doing as you suggested, and checking the dependency tree for bug #140346
to see if I could see anything I could dup this bug to.  I did just as I
described in this bug, using a middle mouse click to open possible candidates in
a new window.  Much to my surprise, I didn't lose keyboard focus on the
dependency tree window!  I double checked and the bug was still present in the
linux-kernel hypermail archives at
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0211.1/index.html.  Maybe
someone who knows HTML better than I can figure out what is different about the
linux-kernel hypermail archives and the Bugzilla dependency tree and reduce this
problem down to a nice simple test case?

As far as my check for dups, I didn't find anything, though its possible bug
#159908 may be related (even though its a Windows bug, the fix for that may be
similar to the fix for this one)

Comment 4

[Ken Schar]

Hi there,

I just tried several times to duplicate this bug using nightly build 2003010308
on Linux and could not reproduce it at all.  Perhaps this bug has been sqaushed :-)

Can you test it on a more recent nightly build. If you don't have one you can
always download the latest at <ftp://ftp.mozilla.org/pub/mozilla/nightly/>, and
then let us know if you still see this problem?

Thanks!
  Ken

Comment 5

[slice1900]

Using the just released 1.3b, I still see this problem on the linux-kernel
hypermail archives as I described before.  Are you sure your test was done
exactly as I described, using the same URL?

Comment 6

[David Hogue]

Attachment: test case

Confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031013

I've narrowed it down to tags within the <a> </a> tags.  <strong> <em> and <b>
cause it.  Some image links seem to do it also.

Comment 7

[David Hogue]

Attachment: better test case

after some more experimenting I noticed that if I click on the bold text I get
the bug, however if I click on the plain text it works as expected.

This also occurs when middle-click opens in a new tab

Comment 8

[Asa Dotzler [:asa]]

->event handling

Comment 9

[slice1900]

David, excellent test case!  Who would have thought it had to do with bolded
versus non-bolded text?!

FYI, I still see this on Linux using 1.6a with David's test case (and the
linux-kernel hypermail archives, as always)

I'm sure this is low priority, but it one of those annoying things that detracts
from the user's experience.  Is the "polish" keyword still being used for things
like this?