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

Status: NEW

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

Description

[Mark Banner (:standard8)]

Attachment: Toolbar in disabled state

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.

Comment 1

[Stephen A Pohl [:spohl]]

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

Comment 2

[Mark Banner (:standard8)]

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

Comment 3

[Mark Banner (:standard8)]

There's also nothing obvious on the browser console.

Comment 4

[Stephen A Pohl [:spohl]]

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

Comment 5

[Jan Jaeschke [:jjaschke]]

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

Comment 6

[Mark Banner (:standard8)]

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

Comment 7

[Stephen A Pohl [:spohl]]

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

Comment 8

[Markus Stange [:mstange]]

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.

Comment 9

[Stephen A Pohl [:spohl]]

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

Comment 16

[Stephen A Pohl [:spohl]]

Possible STR in bug 1811488 comment 4.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

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

• Bug 1859876: S2

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

For more information, please visit BugBot documentation.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 19

[Claas Augner [:claas]]

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

Comment 20

[Mark Banner (:standard8)]

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

Comment 21

[Stephen A Pohl [:spohl]]

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?

Comment 22

[Mark Banner (: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.

Comment 23

[Claas Augner [:claas]]

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

Comment 25

[Dave Townsend [:mossop]]

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

Comment 26

[Dave Townsend [:mossop]]

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