Closed Bug 1874525 Opened 1 year ago Closed 1 year ago

Opening a window from the context menu in Windows 10 doesn't put focus on the browser window

Categories

(Core :: Widget: Win32, defect)

Firefox 121
x86_64
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1667477

People

(Reporter: austin.hill42, Unassigned)

References

Details

Attachments

(1 file)

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.

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.

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

This feels like an issue with the context menu, so I'll move this back to Firefox, but I could be wrong.

Component: DOM: UI Events & Focus Handling → Untriaged
Product: Core → Firefox

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.

Status: UNCONFIRMED → NEW
Component: Untriaged → New Tab Page
Ever confirmed: true
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

(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) ?

Component: New Tab Page → General
Flags: needinfo?(mchiorean)
Flags: needinfo?(austin.hill42)
Attached image 2024-01-23_19h00_52.gif

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.

Flags: needinfo?(mchiorean)

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.

Flags: needinfo?(mhowell)
Flags: needinfo?(adw)

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.

Flags: needinfo?(austin.hill42)

Not reproducible with Win10 for me. Search bar has focus and accept input.

(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)

Flags: needinfo?(austin.hill42)

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.

Flags: needinfo?(mhowell)

(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.

Flags: needinfo?(austin.hill42)

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

Component: General → Widget: Win32
Product: Firefox → Core

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?

See Also: → 1818231

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.

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1667477
Resolution: --- → DUPLICATE
Flags: needinfo?(adw)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: