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).
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...
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. :)
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
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Component: Keyboard: Navigation → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.