Opening a window from the context menu in Windows 10 doesn't put focus on the browser window
Categories
(Core :: Widget: Win32, defect)
Tracking
()
People
(Reporter: austin.hill42, Unassigned)
References
Details
Attachments
(1 file)
4.41 MB,
image/gif
|
Details |
Steps to reproduce:
Right-click the icon in the taskbar and click any of "Open New Tab", "Open New Window", or "New Private Window".
Actual results:
The browser window/tab came up with the cursor in the search bar, but the window did not have focus. You have to click inside the window or alt-tab to bring it back into focus.
Expected results:
The browser window/tab should have come up with the cursor in the search bar and the window having focus.
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
This feels like an issue with the context menu, so I'll move this back to Firefox, but I could be wrong.
Comment 3•1 year ago
|
||
I was able to reproduce the issue on Win10x64 using Firefox build 121.0.
Issue reproduces back to 86.0a1(20210106155127).
Marking as new. If component is not correct please update. Thank you.
Comment 4•1 year ago
|
||
(In reply to Monica Chiorean from comment #3)
I was able to reproduce the issue on Win10x64 using Firefox build 121.0.
Issue reproduces back to 86.0a1(20210106155127).
Marking as new. If component is not correct please update. Thank you.
I can't reproduce in windows 11. I switch focus to a different app, right click the set of Firefox windows in the taskbar, click "open new window", and the new window takes focus - as soon as I type e.g. 'a' that letter appears in the address/search bar.
Can either of you provide a screencast of what exactly you're doing so I can figure out what I'm doing differently? This is assuming it's not a Windows 11 vs Windows 10 issue...
Also, are you seeing the same issue when opening links from external programs (assuming Firefox is set as the default browser) ?
Comment 5•1 year ago
•
|
||
New Tab and Private window have the focus on search bar, while new window does not. Recording is from Win10x64 using Firefox build 121.0. On Win11 with 121.0, I did not reproduce it.
If I open an external link from skype and Firefox is default, Firefox opens the link but search is not focused (Both Win10&11). Thank you.
Comment 6•1 year ago
|
||
Drew or Molly, could you help here? I can't repro at all on Windows 11. This smells like either a Windows thing (or a thing where we're not calling the right Windows APIs), or a race thing in frontend code where focus is supposed to be in the address bar but doesn't reliably end up there for the new window case (and where somehow on my machine, I never hit the "bad" case for the race). It's also confusing to me that in the screencast from Monica, the address bar does look like it has focus in terms of having a blue outline etc, but has no cursor. So something odd is happening.
Perhaps firefox profiler recordings of some kind could help elucidate what is happening when? But I'm not sure what events/markers could help track down what focus/foreground/activate call is/isn't working.
Reporter | ||
Comment 7•1 year ago
|
||
It does seem like an issue with the Windows API calls. I can't take a video right now, but I've tried other programs and some of them behave as expected whereas others also don't have focus. And to clarify - even when the search bar appears to have focus (highlighted and/or cursor) it doesn't accept input until you manually focus on the window.
Comment 8•1 year ago
|
||
Not reproducible with Win10 for me. Search bar has focus and accept input.
Comment 9•1 year ago
|
||
(In reply to austin.hill42 from comment #7)
It does seem like an issue with the Windows API calls. I can't take a video right now, but I've tried other programs and some of them behave as expected whereas others also don't have focus. And to clarify - even when the search bar appears to have focus (highlighted and/or cursor) it doesn't accept input until you manually focus on the window.
Thanks for clarifying - that's what I figured but always good to be sure. Out of interest, do you see the same thing when using e.g. the hamburger / app menu's "new window" entrypoint? Also, in terms of what the window's titlebar/toolbar looks like, is there any visual difference between its state after opening (not properly focused) and what it looks like after you click into the address bar to focus it "properly"? E.g. does the background colour or colours on the titlebar buttons in the top right change at all? (Trying to establish if Windows thinks the window has focus but the address bar doesn't, or if Windows thinks the window is not focused/active at all)
Comment 10•1 year ago
|
||
I can't say much for certain about this because I can't seem to reproduce it either, but I suspect there isn't much we can do, simply because our involvement in this process is pretty limited. In short, the taskbar commands work by starting a new instance of Firefox with the appropriate command line (which is really the only way that the taskbar supports for them to work). From there, we're just doing our normal remoting service thing, where the new instance hands that command line off to the existing instance (via a WM_COPYDATA
to a dedicated message window), and then it exits and the existing instance handles that command line the same way it ever would. Really the only behavior that's specific to the taskbar case is the taskbar itself, we're not doing anything special. So given that, I'm not sure what we would really do here.
Reporter | ||
Comment 11•1 year ago
|
||
(In reply to :Gijs (he/him) from comment #9)
(In reply to austin.hill42 from comment #7)
It does seem like an issue with the Windows API calls. I can't take a video right now, but I've tried other programs and some of them behave as expected whereas others also don't have focus. And to clarify - even when the search bar appears to have focus (highlighted and/or cursor) it doesn't accept input until you manually focus on the window.
Thanks for clarifying - that's what I figured but always good to be sure. Out of interest, do you see the same thing when using e.g. the hamburger / app menu's "new window" entrypoint? Also, in terms of what the window's titlebar/toolbar looks like, is there any visual difference between its state after opening (not properly focused) and what it looks like after you click into the address bar to focus it "properly"? E.g. does the background colour or colours on the titlebar buttons in the top right change at all? (Trying to establish if Windows thinks the window has focus but the address bar doesn't, or if Windows thinks the window is not focused/active at all)
Opening a new window from the FIrefox menu works just fine. When opening from the Windows context menu, the only visual difference is that the icon on the taskbar is not highlighted like it should be when a window has focus, otherwise it appears to be in focus.
(In reply to Molly Howell (she/her) [:mhowell] from comment #10)
I can't say much for certain about this because I can't seem to reproduce it either, but I suspect there isn't much we can do, simply because our involvement in this process is pretty limited. In short, the taskbar commands work by starting a new instance of Firefox with the appropriate command line (which is really the only way that the taskbar supports for them to work). From there, we're just doing our normal remoting service thing, where the new instance hands that command line off to the existing instance (via a
WM_COPYDATA
to a dedicated message window), and then it exits and the existing instance handles that command line the same way it ever would. Really the only behavior that's specific to the taskbar case is the taskbar itself, we're not doing anything special. So given that, I'm not sure what we would really do here.
If there's nothing you can do then go ahead and close this ticket. I just thought I'd open it since other programs have no problem getting focus from the taskbar context menu (of course, others do have the same problem), and launching Firefox from the explorer context menu ("Open with" -> Firefox), as well as via WIN+R -> "firefox" and powershell &"C:\Program Files\Mozilla Firefox\firefox.exe" has no problems with the window having focus, which seemed to point to an issue either within Firefox or with the way it interacts with Windows.
Comment 12•1 year ago
|
||
This seems to be Windows related and people are having an issue reproducing (and a question over whether any fix is possible) so putting in win32 for people who would know more about the specifics to make a call on closing / investigating more
Comment 13•1 year ago
|
||
I also can't reproduce this on Windows 10, but that's because I'm instead hitting bug 1818231 (even on non-private windows), wherein focus appears to be on the address bar, but all keyboard input is lost. I've been looking into that off and on; I suspect this may be a closely related failure state.
For those of you who can reproduce this bug as described: if you open a new window, and focus does not appear to be on the address bar (no blinking cursor; no heavy outline), what happens if you press Ctrl+W
or Alt+F4
?
Comment 14•1 year ago
|
||
On reread, I think this is entirely consistent with this being bug 1667477 (aka bug 1818231). I'm not sure what I might have misread to think it wasn't.
Closing as duplicate.
Updated•1 year ago
|
Description
•