Closed
Bug 252178
Opened 21 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)
Tracking
()
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. :/
Comment 1•21 years ago
|
||
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.
Comment 3•21 years ago
|
||
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...
Comment 5•21 years ago
|
||
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.
Comment 8•20 years ago
|
||
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).
Updated•20 years ago
|
Comment 10•20 years ago
|
||
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?
Comment 11•20 years ago
|
||
Mebbe bryner will take a look, he's my GTK hero.
/be
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
I've been seeing this with seamonkey too. -> browser.
Component: Accessibility → Accessibility APIs
Product: Firefox → Browser
Version: unspecified → Trunk
Comment 14•20 years ago
|
||
Kyle, can someone on your team take this?
Assignee: aaronleventhal → kyle.yuan
Component: Accessibility APIs → Keyboard: Navigation
Comment 15•20 years ago
|
||
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
Comment 16•20 years ago
|
||
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/
Comment 17•20 years ago
|
||
is this working for anyone else now?
Comment 18•20 years ago
|
||
Nope. Keyboard shortcuts on gmail are pretty much screwed.
Comment 19•20 years ago
|
||
(In reply to comment #17)
> is this working for anyone else now?
Kyle is on vacation still.
Comment 20•20 years ago
|
||
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.
Comment 21•20 years ago
|
||
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.
Comment 22•20 years ago
|
||
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.)
Comment 23•20 years ago
|
||
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?
Comment 24•20 years ago
|
||
Do you have your GNOME keyboard prefs set that way? What exactly is your build?
Comment 25•20 years ago
|
||
if we get closer to reproducability and a patch renominate.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 26•20 years ago
|
||
Yes, my GNOME prefs are explicitly set as emacs. I'm not saying that this is
unexpected behaviour. :)
Updated•19 years ago
|
Assignee: zhayupeng → mats.palmgren
Assignee | ||
Comment 27•15 years ago
|
||
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
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Comment 28•6 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•