Closed Bug 252178 Opened 20 years ago Closed 15 years ago

browser losing focus after closing new window, shortcut keys become non-functional

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: logan+mozilla-bmo, Assigned: MatsPalmgren_bugz)

References

(Blocks 1 open bug)

Details

(Keywords: access) 

The browser focus seems to be lost or stuck in limbo after closing a newer
window. I'm unable to reproduce the problem when initially launching Firefox, it
only seems to happen after, say 15+ minutes of regular browsing.

How to reproduce:
1) Using an existing browser window, open a new window (ctrl-n, middle click on
url, etc).
2) Close the new window (nothing has to be loaded).
3) Now try ctrl-n or ctrl-l, nothing happens.

It seems the focus is still with the browser somewhere, but perhaps on a widget
that doesn't allow for some of these shortcut keys. Tab still functions, sending
you to the next item on the page. Tabbing once or clicking on the page itself
allows ctrl-l or ctrl-n to work again.

Dunno if this is a linux-only issue or maybe has something to do with my window
manager (openbox3). The closest thing I could find was bug 230097 and I'm not
sure that's the same thing.

I've asked on irc a few times... Noone else seems to experience this, but then
most seem to be using Windows. Hopefully I'm not crazy or causing this. :/
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040719
Firefox/0.9.1+

If you have the focus in e.g. an input (like urlbar/searchbar) in the first , it
will return there after you close the second window.
If you had no particular focus in the first one it won't know where to focus
after you close the second window.
Sounds all pretty logic to me.
I wouldn't like the focus to be automatically set to a default part of the browser.

invalid ?
If the initiating window started with the focus in the urlbar or on a link, it
doesn't matter; the end result is the same.
Does the first tab send you to the same place every time?  If so, where does it
go to?
If the new window was created by middle click or right click -> open link ...,
then it'll stay near that general area, sometimes actually backing up an object?
If ctrl-n, it starts at the top...
I cannot seem to repro this using 2004073008-0.9 on linux (fedora core 1 at the
moment).

1. in current window, tab to a link so that the focus ring appears around it.
2. open new window (ctrl+N).
3. close new window (ctrl+W).
4. hit tab in first window (step 1) to move focus to new link, or ctrl+L to move
to location bar.

actual results: I was able to tab to another link and move focus to location bar.
Assignee: firefox → aaronleventhal
Component: General → Accessibility
QA Contact: firefox.general → bugzilla
I should also make clear that I'm using focus follows mouse, not click to focus.
Click to focus (depending on click location), may very well (re)set the brower
focus.

Someone on the mozillazine forum brought this issue up tonight, he was sure it
started with 0.9, which for me was the first gtk2 build of anything Mozilla. So,
I wonder if it's just gtk2 builds? Maybe something to keep in mind...
I've been playing with the contributed gtk1 build of 0.9 for ~30 minutes now and
haven't had any problems, seems to be gtk2 only.
I've noticed this now, maybe because I just upgraded to latest CVS.  In mail,
when I double-click open a message, then close that window, I need to hit tab to
put focus back on the message list.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hehe, well at least I know it's not just me. :P

I'm not sure if my test with the gtk1 build was long enough. For the first time
tonight I was working ok for a good hour or so, usually it starts much sooner
than that. Perhaps it's the order or combination of certain things which causes it.

Wish I had some idea of where to start with this. I've never tried any gtk2
builds of Mozilla, but if it exists in Firefox it's probably there as well. If
that's the case, it might help to switch the product to Browser (get some more
eyeballs lookin at this one).
Blocks: focusnav
Keywords: access, sec508
ccing gtk2 people, driver-types.

This is a pretty serious problem for keyboard use of the app... And since GTK1
doesn't have the problem, there is some hope that it may be just an oversight in
the GTK2 widget code...
Flags: blocking-aviary1.0?
Mebbe bryner will take a look, he's my GTK hero.

/be
This happens to me all the time just opening new tabs.  Focus is nowhere.  Never
happens to me with tabs in seamonkey, interestingly enough.  Just firefox. 
gmail is the best way to display the problem.  Focus isn't anywhere that I can
tell, and the keybindings in gmail don't work.
I've been seeing this with seamonkey too. -> browser.
Component: Accessibility → Accessibility APIs
Product: Firefox → Browser
Version: unspecified → Trunk
Kyle, can someone on your team take this?
Assignee: aaronleventhal → kyle.yuan
Component: Accessibility APIs → Keyboard: Navigation
any chance of this being fixed in the next couple of weeks?  would need a patch
soon to consider for aviary 1.0 and 1.7.x
WFM.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/2004093

--enable-default-toolkit=gtk2 --enable-freetype2 --disable-xft --enable-debug 

default home page is http://www.mozilla.org/start/
is this working for anyone else now?
Nope.  Keyboard shortcuts on gmail are pretty much screwed.
(In reply to comment #17)
> is this working for anyone else now?

Kyle is on vacation still.
I meet the same problem with our internal gtk2-based mozilla 1.7 build. Playing
with the browser a while, ctrl-t to open a new tab, then ctrl-w to close it,
nothing happened. But it is not easily reproducible. Still looking.
Yeah, I think focus is in the url text area, not the browser area.  So ctrl-w is
interpreted as a command for the text area and doesn't bubble up to the menu.
If the URL bar had focus, window-close would still work via ctrl-W, as well as
ctrl-L.  (At least, those both work for me in ffox when the URL bar is focused.)
In my build and env, when I hit ctrl-w in the url bar, it deletes the previous
word in the url bar.  Emacs key bindings for the text editor?
Do you have your GNOME keyboard prefs set that way?  What exactly is your build?
if we get closer to reproducability and a patch renominate.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Yes, my GNOME prefs are explicitly set as emacs.  I'm not saying that this is
unexpected behaviour.  :)
Assignee: yuanyi21 → pete.zha
Assignee: zhayupeng → mats.palmgren
I think this should be fixed now with the new focus manager (bug 178324).
Please file a new bug if the problem still occurs in a trunk build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

-> WORKSFORME
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.