Open Bug 1812622 Opened 3 years ago Updated 4 months ago

Occasionally semi-freeze/unresponsive and apparent lack of focus on startup

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Type:
defect

Tracking

()

Status:
ASSIGNED

People

(Reporter: standard8, Assigned: spohl)

References

Details

(Keywords: dogfood)

Attachments

(1 file)

Toolbar in disabled state
95.24 KB, image/png
Details

I see this quite a bit on my development builds, because I restart them frequently. I'm not sure if I've seen it on a production build mainly because I don't restart them as much.

I have seen this on both macOS 12.x and 13.x.

STR:

  1. Start up Firefox.
    -> I generally have session restored enabled.
    -> Devtools/browser console are not being opened.
  2. Try and interact in the content areas

Actual Results

  • The toolbars look like they are disabled/in the background.
  • Links in content are unresponsive, though sometimes you get a little bit of hover showing up.
  • You can load new pages and open new tabs e.g. by using the address bar - however they are unresponsive as well.

The only way out of this state is to switch to another application and back again.

Have you already been able to eliminate possible culprits such as extensions etc. by starting in safe mode for example?

Severity: -- → S3
Flags: needinfo?(standard8)
Priority: -- → P3

It happens in safe mode as well. I also removed my pinned tab. It probably happens about once in every 10 startups.

Flags: needinfo?(standard8)

There's also nothing obvious on the browser console.

It would be interesting to see if a startup profile shows anything out of the ordinary: https://profiler.firefox.com/docs/#/./guide-startup-shutdown?id=startup

I might have come across the same (or at least a very similar) issue. After restarting Nightly (after updating), all content was frozen. Selecting text, clicking links did not work (across all tabs and windows). The browser chrome however worked, ie. scrolling, switching tabs, right-click, etc. The cursor also indicated a link or a selectable text when hovering. I managed to create a profile, but it's not a startup profile (I started recording when I realized everything was frozen), so I don't know if it is too helpful.
Eventually it started working again. I can't recall if it was after switching to another app and back though...

I've been able to reproduce this consistently for a few times today, so I was able to grab a startup profile.

Firefox is starting up with the preferences pane visible. As can be seen around the 10s mark, scrolling works, but I'm unable to click on the content. Around 15s, I click to a different app and back again, and then I'm able to click the content.

After writing this comment, I tried it a few more times and haven't been able to reproduce. I'm not quite sure but time machine might have been running in the background. I'll try and keep an eye on that. (edit: just happened again without time machine).

Flags: needinfo?(spohl.mozilla.bugs)
See Also: → 1859876

Markus, could you take a look at the startup profile in comment 6?

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(mstange.moz)
See Also: → 1811488

In the profile I can see one call to inactiveWindowAcceptsMouseEvent from here so I think the real trouble is that the browser window doesn't have main state.

In other words, if we fix the issue that causes the window buttons to be gray, we'll fix the mouse input issue as well.

Flags: needinfo?(mstange.moz)

I'm going to make this the primary bug for all related and duplicate bugs.

Duplicate of this bug: 1880291
Duplicate of this bug: 1876291
Duplicate of this bug: 1865052
Duplicate of this bug: 1862607
Duplicate of this bug: 1859876
See Also: 1859876 →
Duplicate of this bug: 1811488
See Also: 1811488 →

Possible STR in bug 1811488 comment 4.

See Also: → 1879816

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

:spohl, could you consider increasing the severity of this bug to S2?

For more information, please visit BugBot documentation.

Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(spohl.mozilla.bugs)

Based on my personal periodic experiences of this bug, and from talking to claas about his experience hitting it (he seems to hit it quite frequently), I suspect this is some kind of race at startup that occurs when opening the Primary Password modal.

Note that for me the Primary Password modal appears and is responsive, i.e. I can type in and submit the password, but the rest of Firefox is unresponsive (to mouse interactions only).

I've seen this on my development profiles where the primary password is not enabled.

This bug was filed before bug 1865372 landed, which caused a similar regression that was fixed by bug 1879816. While bug 1865372 didn't cause this bug here, there is a good chance that the fix for bug 1879816 fixed this bug too. Mark (and anyone else experiencing this bug), could you keep an eye out for this and close this bug in case it was resolved by bug 1879816?

Flags: needinfo?(standard8)

Unfortunately I can still reproduce this on my development set-up. I'm vaguely wondering if this could be timing / session restore related - my normal dev profile does have session restore set up. However, it definitely isn't consistent as to when it appears.

Flags: needinfo?(standard8)
See Also: → 1885010

Here's another fresh profile: https://share.firefox.dev/3TU7rKi

During the profile, hovering over elements of webpages still caused a (very delayed) hover effect (here: hovering over the X/Twitter menu elements, which causes them to be highlighted).

Duplicate of this bug: 1940973

This seems to happen quite frequently when launching new profiles with the new profiles feature for some reason. See 1940973 for example.

I can reproduce this reasonably easily in a debug build, is there some diagnosis I can do to figure out what is going on?

Flags: needinfo?(mstange.moz)
Summary: Occasionally semi-freeze/unresponsive on startup → Occasionally semi-freeze/unresponsive and apparent lack of focus on startup

redirecting needinfo to Stephen

Flags: needinfo?(mstange.moz) → needinfo?(spohl.mozilla.bugs)
Duplicate of this bug: 1997841

Note that mochitests are quite heavily affected by this bug as well. I'm going to add blockers for those bugs that I'm aware of.

I would also like to know how to maybe do more logging. Stephen, Is there something that we can do around those lines?

https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1103
https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1048

Maybe we are not getting those notifications? Do we have to explicitly active the window (maybe that's done when --foreground is specified)? Could there be a race in that we are trying to do that too early and then its getting ignored?

Blocks: 1414495, 1868846

This has happened almost everytime I ran a development build today. How do we get some progress here?

Keywords: dogfood

Dave, if you can reproduce this almost every time I wonder if a breakpoint around the following lines could at least tell us if we get notified at all for applicationDidBecomeActive?

https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1103

Maybe that is not happening and an Instruments profile might help? Nevertheless it would be good to get some details from Stephen or Markus.

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #31)

Dave, if you can reproduce this almost every time I wonder if a breakpoint around the following lines could at least tell us if we get notified at all for applicationDidBecomeActive?

https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1103

Maybe that is not happening and an Instruments profile might help? Nevertheless it would be good to get some details from Stephen or Markus.

Yes, in the bad startup case this notification is not sent (until you refocus the app). In the good startup case it is sent.

I have this variably - sometimes it happens a lot, sometimes not. Like Dave, I use an external monitor (though my laptop lid is open).

I just had this happen for a bit when opening the browser toolbox using the menus. I was able to catch it with some logging and also determined that applicationDidBecomeActive was not sent when the problems occurred.

On startup I do get the following messages - however these appear regardless of if it works or not.

2025-11-06 13:48:09.167 Nightly GPU Helper[74055:1518702] Failure on line 688 in function id scheduleApplicationNotification(LSNotificationCode, NSWorkspaceNotificationCenter *): noErr == _LSModifyNotification(notificationID, 1, &code, 0, NULL, NULL, NULL)
2025-11-06 13:48:09.462 Nightly GPU Helper[74055:1518722] Connection Invalid error for service com.apple.hiservices-xpcservice.
2025-11-06 13:48:09.462 Nightly GPU Helper[74055:1518702] Error received in message reply handler: Connection invalid
Flags: needinfo?(spohl.mozilla.bugs)

Stephen do you have an update for this bug or any advice what to do to retrieve more information? Thanks!

Flags: needinfo?(spohl.mozilla.bugs)

I have not been able to make as much progress on this as I had hoped, but this bug is my top priority now. I should know more soon.

Flags: needinfo?(spohl.mozilla.bugs)
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED

I have been desperately trying to reproduce this with a local debug build since this is expected to speed up a fix quite a bit. Unfortunately, I have been unable to reproduce it so far. To be specific, I'm running macOS 26.2 Beta (25C5031i) with a local debug build based on current nightly. I'm going to set a few need-infos in the hopes that someone might be able to get me closer to a reproducible test case:

(In reply to Mark Banner (:standard8) from comment #33)

I just had this happen for a bit when opening the browser toolbox using the menus. I was able to catch it with some logging and also determined that applicationDidBecomeActive was not sent when the problems occurred.

@Mark: Could you clarify if you were able to reproduce this after browser startup, when opening the browser toolbox? And by "using the menus", are you referring to the main menu bar at the top of the screen, or some other menus?

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #34)

Stephen do you have an update for this bug or any advice what to do to retrieve more information? Thanks!

@Henrik: It sounds like you have been able to reproduce quite frequently with mochitests. Does this apply to running mochitests locally as well? Or only on try or CI? Any particular tests that have been showing this issue more than others?

(In reply to Dave Townsend [:mossop] from comment #30)

This has happened almost everytime I ran a development build today. How do we get some progress here?

@Dave: I have been unable to get the menu item to appear in the hamburger menu when I'm running with a local debug build. Assuming that creating and restarting into new profiles is still the most reliable way for you to reproduce this issue, would you happen to know how I can enable this in the hamburger menu? (I feel like I have asked you a similar question in a different bug before but I can't for the life of me find that bug again).

(In reply to Adrian Florinescu [:aflorinescu] from bug 1811488 comment #4)

Hit the same issue today on 116.0b5 Mac 13 with the Make browser default modal, at which point the entire browser seems unresponsive. Highly intermittent, but seems to be the same bug, since the workaround works - clicking on desktop restores the buttons functionality.

Although I've caught it on a new profile with no fancy steps, I'd reckon some race happens and it can be reliably reproduced with the following (about 1/10 occurence):

  1. Have 1 or 2 bogus logins for facebook.com.
  2. Set primary password.
  3. Have open a single facebook login tab.
  4. Type in address bar restart and select the quick action for restart (this is enabled on nightly and early beta)
  5. Cancel primary password modal and cancel make default modal
  6. Repeat the above STR until cancel make default modal buttons will not work.

The above steps will ensure that the primary password and the make default modal will appear in the same time and although I don't think this is a necesary step, it's what I could reduce it to in order to have some form of reliable STR.

I'm unable to get the "Make Default" dialog to appear with a local debug build. Checking this option in about:preferences seems to get reset every time that I restart the browser if I launched the build with ./mach run. Assuming that this is required to reproduce the lack of focus on startup, does anyone know how to make this dialog appear?

Flags: needinfo?(standard8)
Flags: needinfo?(hskupin)
Flags: needinfo?(dtownsend)
Flags: needinfo?(aflorinescu)

(In reply to Stephen A Pohl [:spohl] from comment #36)

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #34)

Stephen do you have an update for this bug or any advice what to do to retrieve more information? Thanks!

@Henrik: It sounds like you have been able to reproduce quite frequently with mochitests. Does this apply to running mochitests locally as well? Or only on try or CI? Any particular tests that have been showing this issue more than others?

Yes, I see this once in a while locally as well but not that pretty often as Mossop is seeing it for his mentioned STRs. There is no particular test which is mostly affected it's all of them. Note that I'm on MacOS 15.7.1 (24G231) in case it matters.

Flags: needinfo?(hskupin)

(In reply to Stephen A Pohl [:spohl] from comment #36)

(In reply to Mark Banner (:standard8) from comment #33)

I just had this happen for a bit when opening the browser toolbox using the menus. I was able to catch it with some logging and also determined that applicationDidBecomeActive was not sent when the problems occurred.

@Mark: Could you clarify if you were able to reproduce this after browser startup, when opening the browser toolbox? And by "using the menus", are you referring to the main menu bar at the top of the screen, or some other menus?

I don't think I've ever seen this after startup for the main Firefox. The browser toolbox I was opening from the main menu bar at the top of the screen.

Neither happen all the time for me. I do have session restore enabled on the profile, though I'm only ever restoring about 4-5 tabs.

Today I've had it a few times on that it has failed on start up, possibly more when the tab restored is about:preferences#search, but that could be co-incidence.

Flags: needinfo?(standard8)

@spohl
I've discussed with the team finding some simplified STR to reproduce it and besides it being v intermittent as originally specified:

  • it's not really specific to a mac version (reproduced on 13, 14, 15)
  • someone in our team also reported that the freeze startup behavior was observed on different non-firefox apps as well, like mail, chrome, etc. , so it might well be something problematic more indepth in the mac app startup process and not affecting only firefox
  • didn't figure better reduced STR
Flags: needinfo?(aflorinescu)

Stephen, would an instruments profile maybe help to gather more details? If yes which kind of profile should it be? Someone who can reproduce this regularly could try to create one.

Flags: needinfo?(spohl.mozilla.bugs)

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #40)

Stephen, would an instruments profile maybe help to gather more details? If yes which kind of profile should it be? Someone who can reproduce this regularly could try to create one.

I have not worked with instruments profiles before, so I can't confirm or deny right now if it would be helpful. I have been trying to get this to reproduce more reliably with a local build. If this fails I'm going to try and add logging to a build and ask for someone to run this until it reproduces.

Flags: needinfo?(spohl.mozilla.bugs)

(In reply to Stephen A Pohl [:spohl] from comment #36)

(In reply to Dave Townsend [:mossop] from comment #30)

This has happened almost everytime I ran a development build today. How do we get some progress here?

@Dave: I have been unable to get the menu item to appear in the hamburger menu when I'm running with a local debug build. Assuming that creating and restarting into new profiles is still the most reliable way for you to reproduce this issue, would you happen to know how I can enable this in the hamburger menu? (I feel like I have asked you a similar question in a different bug before but I can't for the life of me find that bug again).

Which menu item are you referring to?

Flags: needinfo?(dtownsend) → needinfo?(spohl.mozilla.bugs)

This most likely refers to the steps as given in the initial comment on bug 1940973. I also do not see the Profile item within the hamburger menu.

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #43)

This most likely refers to the steps as given in the initial comment on bug 1940973. I also do not see the Profile item within the hamburger menu.

Ah ok. If you're running development builds you have to use ./mach run -a in order to get that. Lately though I am not testing profiles, I just see this on normal startup.

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #29)

Note that mochitests are quite heavily affected by this bug as well. I'm going to add blockers for those bugs that I'm aware of.

I would also like to know how to maybe do more logging. Stephen, Is there something that we can do around those lines?

https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1103
https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1048

Maybe we are not getting those notifications? Do we have to explicitly active the window (maybe that's done when --foreground is specified)? Could there be a race in that we are trying to do that too early and then its getting ignored?

Henrik, I see that you added two blocking bugs when you wrote this comment. Would you be able to tell me how to easily kick these runs off? How often would you say these intermittent failures happen? Would I need to trigger the test a few times? 10 times? 20 times? It would be great to be able to send a few possible patches through try and test a few theories (or, at a minimum, add some logging). Thank you!

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(hskupin)

Alternatively, is there a way for you to run the tests with the MOZ_NO_GLOBAL_MOUSE_MONITOR environment variable set? I'd be curious to hear if this changes anything.

(In reply to Stephen A Pohl [:spohl] from comment #45)

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #29)

Note that mochitests are quite heavily affected by this bug as well. I'm going to add blockers for those bugs that I'm aware of.

I would also like to know how to maybe do more logging. Stephen, Is there something that we can do around those lines?

https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1103
https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1048

Maybe we are not getting those notifications? Do we have to explicitly active the window (maybe that's done when --foreground is specified)? Could there be a race in that we are trying to do that too early and then its getting ignored?

Henrik, I see that you added two blocking bugs when you wrote this comment. Would you be able to tell me how to easily kick these runs off? How often would you say these intermittent failures happen? Would I need to trigger the test a few times? 10 times? 20 times? It would be great to be able to send a few possible patches through try and test a few theories (or, at a minimum, add some logging). Thank you!

Henrik, I might have a patch soon that would be great to run through its paces. Could you tell me how to run this on try, CI or anywhere else? Or would you be able to test a patch by chance? Thank you!

Flags: needinfo?(hskupin)

Didn't mean to clear n-i. Please see comment 47.

Flags: needinfo?(hskupin)

Sorry for not replying but we had a work week last week. For me this issue is happening kinda rarely so maybe lets ask Mark and Dave if they have a better chance to test it with MOZ_NO_GLOBAL_MOUSE_MONITOR set.

When you want to test this patch on try just trigger the full set of browser chrome tests for MacOS (maybe with a small retry # as well). It should hopefully give us some feedback if the issue is no longer present.

Flags: needinfo?(standard8)
Flags: needinfo?(dtownsend)

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #49)

Sorry for not replying but we had a work week last week. For me this issue is happening kinda rarely so maybe lets ask Mark and Dave if they have a better chance to test it with MOZ_NO_GLOBAL_MOUSE_MONITOR set.

I just tested with MOZ_NO_GLOBAL_MOUSE_MONITOR set and still see the issue.

Note that in CI most (or even all) failures on macOS seem to actually be related to bug 2004631 where a system prompt is shown and stealing the focus to request the keychain password. I filed bug 2004631 to get this investigated and fixed.

Flags: needinfo?(hskupin)
See Also: → 2004631
Flags: needinfo?(dtownsend)

(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #51)

Note that in CI most (or even all) failures on macOS seem to actually be related to bug 2004631 where a system prompt is shown and stealing the focus to request the keychain password. I filed bug 2004631 to get this investigated and fixed.

Thank you for letting us know. Based on this, it sounds like the urgency behind this bug is no longer quite as high as previously thought but I am going to keep this bug on my radar. As you suggested, running with a logging patch applied might have to be the next step. My attempts at creating a situation where https://searchfox.org/firefox-main/rev/1a8c62b86277005f907151bc5389cf5c5091e76f/widget/cocoa/nsAppShell.mm#1088 does not get called have been unsuccessful.

Flags: needinfo?(standard8)
No longer blocks: 1868846
Duplicate of this bug: 1963802

bug 1963802 might have some pointers for debugging this further. I encountered a scenario where Firefox seemed non-responsive, but Cmd+Click seemed to work. I also pointed to some locations in the source code that resulted in observable differences.

And I still encounter this bug from time to time when starting Firefox with ./mach run

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: