Browser can sometimes not take mouse input when Terms of Use screen is shown
Categories
(Firefox :: Messaging System, defect)
Tracking
()
People
(Reporter: robwu, Unassigned, NeedInfo)
Details
When I launch a local build of Firefox (on macOS 15.3.1) with ./mach run --temp-profile, a Terms of Use screen is sometimes shown. Often I can interact with it just fine, but sometimes it does not take any mouse input. Clicking, text selection - none of it works.
Here is what I have tried so far when I encountered the situation:
Switching to a different application and then back restores the ability to interact.
Opening a new window (Cmd+N) results in a new window where I can click on the address bar to open the autocomplete panel, but the cursor is not shown. Clicking inside the content area does not dismiss the autocomplete panel.
Pressing Cmd+A triggers the following error (an error which does not show up when I switched to a different application and then back):
console.error: "An error occurred executing the " "cmd_selectAll" " command: " [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIController.doCommand]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 121" data: no]
|
Reporter | |
Comment 1•17 days ago
|
||
I hit this issue again.
When I hold the Cmd button pressed, I can interact with the TOU screen, e.g. selecting text within.
When I press Cmd + T, a new tab opens (behind the TOU screen). So it looks like there is at least something handling keyboard shortcuts for this specific window.
|
|
Reporter | |
Comment 2•16 days ago
|
||
And again. While Cmd+T opens a tab, Cmd+W does not close it.
Now I tried interacting with all menus. All menu items in View were disabled.
When I tried hovering over the File menu, the following error was raised:
Uncaught TypeError: can't access property "selectedTabs", gBrowser is undefined
updateTabCloseCountState chrome://browser/content/browser.js:1883
onPopupShowing chrome://browser/content/browser.js:1894
<anonymous> chrome://browser/content/browser-menubar.js:164
When I open the Browser Console with Cmd+Shift+J, typing gBrowser shows that it is in fact defined with the expected value.
|
|
Reporter | |
Comment 3•16 days ago
|
||
The above (comment 2) could happen if browser.js is loaded via global-scripts.js, from macWindow.inc.xhtml.
When I encountered the non-responsive TOU screen again, I could click through and accept the TOS by pressing Cmd pressed while clicking. After doing that, I went to about:addons, and clicked to try and install a (recommended) add-on. But when the install prompt appeared, I could not approve the installation; an attempt to click results in the following message in the console (Cmd+Shift+J):
PopupNotifications._onButtonEvent: Button click happened before the window was focused / active
Inspired by the source of the message, I evaluated Services.focus.activeWindow, and it was null.
The activeWindow getter returns mActiveWindow, and the only setter of that is in nsFocusManager::WindowRaised.
Hey Rob, thanks for filing! Is this something that you're able to replicate outside of Nightly? Is this also intermittently or does this happen consistently? Other folks on our teams have encountered this issue (unrelated to ToS) with local builds/artifact builds.
|
|
Reporter | |
Comment 5•13 days ago
|
||
I haven't encountered this issue on Nightly, as the ToS screen is shown only once.
I'm developing a feature where running a new Firefox instance is part of my workflow. Before I filed this issue, I encountered the issue a handful of times, but over the past few days, I've encountered the issue more often than I can count on two hands. I tried reproducing it, but couldn't. Then I resumed my usual work, and hit the issue on the second try; I don't see any consistency in reproduction.
(In reply to Mimi Jung from comment #4)
Other folks on our teams have encountered this issue (unrelated to ToS) with local builds/artifact builds.
Interesting. Do their observations match what I described? Or are there things that are not in what I have mentioned?
Given the information so far, I think that asking people familiar with focus handling would be the best next step.
Gotcha, appreciate the details and apologies that this has been disrupting your workflow.
It's unclear yet if this is directly related to the ToS changes but I'm NI'ing you Meg in case there's anything that sticks out to you or if you can recall similar issues with local/artifact builds. Digging into the logs, it's unclear if this might be more suitable for Firefox > General and if it should be pulled into general triage.
Description
•