Firefox on MacOS Tahoe "freezes" after closing and re-opening my laptop
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
People
(Reporter: leejasper851, Unassigned)
Details
Attachments
(1 file)
What a new window looks like when Firefox is frozen. It looks just like a Firefox window when unfocused.
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:146.0) Gecko/20100101 Firefox/146.0
Steps to reproduce:
I close (physically fold) my laptop screen, wait 10 seconds or longer, and reopen it.
Actual results:
I am using Firefox on my MacOS Tahoe. There is a persistent annoying issue where whenever I close (physically fold) my laptop screen and reopen it, Firefox will be frozen. It will be frozen in the sense that I am unable to interact with any tabs or anything until I manually quit Firefox and reopen it (which automatically reopens all my tabs), making it usable again. This doesn't happen every time I close and reopen my Mac, but it definitely happens the majority of the time and makes the browser hard to use.
I've attached a screenshot of what a new window looks like when Firefox is frozen. It looks just like a Firefox window when unfocused.
Notes:
- It doesn't entirely freeze Firefox. In fact, I can "switch" to a different tab by clicking on the tab and then shutting and reopening my laptop again. The new tab will show on reopening but Firefox will still be frozen. This process can be repeated.
- I can pretty consistently replicate the bug by shutting my laptop, waiting 10 seconds, and reopening it. This will almost always result in the freeze.
- The bug still happens if I'm not focused on the Firefox window but on a different app.
- The bug doesn't seem to happen if I just lock my screen but don't shut it closed.
Things I've tried that haven't fixed it:
- Updating my OS.
- Restarting my laptop.
- Disabling hardware acceleration.
- Disabling themes and extensions.
- Deleting and reinstalling Firefox, including deleting the user data in the "Library/Application Support" folder.
Expected results:
Firefox should be unfrozen and ready to use (without quitting and restarting the app) whenever I open my laptop.
|
||
Comment 1•4 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•4 months ago
|
||
Does this happen in Troubleshoot Mode (Help > Troubleshoot Mode...) or a new profile? If you switch to another app and back to Firefox, do things start working again? Or does only a restart of the browser fix things?
Thanks for the quick response!
The bug still happens in Troubleshoot Mode and in a new profile. And only a restart of the browser fixes things, switching to another app doesn't. In fact, even if I close my laptop while in another app and then open it, the bug will still occur and Firefox will be frozen when I switch to it.
|
|
||
Comment 4•4 months ago
|
||
It would be great if you could help us figure out if this is a regression. Could you run mozregression to see when this started happening? You can either choose to use the GUI tool, or simply run these three commands in a Terminal window:
sudo easy_install pip
sudo python3 -m pip install -U mozregression --ignore-installed
mozregression
A number of Firefox versions will open in succession to narrow down when this started occurring. Simply type "good" or "bad" in Terminal based on whether or not a build reproduces the bug. Once finished, please post the output from the last run. It should give a last good and first bad revision as well as a link to look at the changesets in that range. Thank you!
I ran it, here's the final output:
25:18.13 INFO: Narrowed integration regression window from [4888c6dd, 21887f76] (8 builds) to [df71a7a9, 21887f76] (2 builds) (~1 steps left) 25:18.13 INFO: No more integration revisions, bisection finished. 25:18.13 INFO: Last good revision: df71a7a93a7620c44f5b9f54e067292721fc802a 25:18.13 INFO: First bad revision: 21887f76141481defddd7ebfaa84b3fca1ccccc8 25:18.13 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=df71a7a93a7620c44f5b9f54e067292721fc802a&tochange=21887f76141481defddd7ebfaa84b3fca1ccccc8
|
|
||
Comment 6•4 months ago
|
||
Thank you! This looks to be a duplicate of bug 1985140 that was regressed by bug 1960109. If you agree, I will close this as a duplicate of bug 1985140.
Thanks, this does indeed seem to be the same bug. I read through both threads, but I'm not really familiar with the Bugzilla terminology or the inner workings of Firefox. My main question is: What is the current status of the bug being resolved, and is there any action I should take?
The page for bug 1985140 has at the top:
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- affected
firefox143 --- wontfix
firefox144 --- wontfix
firefox145 --- wontfix
firefox146 --- wontfix
firefox147 --- fix-optional
firefox148 --- affected
Does this mean I should expect the bug to be fixed when I update to firefox147 or firefox148?
Also, what does "regressed" mean in the context of one bug being regressed by another?
Thank you.
|
|
||
Comment 8•4 months ago
|
||
Thank you for confirming and I'm happy to answer your questions: "regressed by a bug" means that there was a code change, tracked in one bug, that triggered a new bug. In other words, the changes in bug 1960109 triggered bug 1985140 that you are experiencing. In terms of when to expect a fix: bug 1985140 has not been fixed yet but the final code review has just happened and the change should land shortly. This means that the fix is expected to land in Nightly 148 and there is a possibility that the changes will be uplifted to earlier versions, such as Beta 147 for example. But this will depend on the possible risk of yet other regressions, and it is sometimes preferable to let a change "ride the trains" in Nightly to see if any users report new issues stemming from the changes in bug 1985140. I hope this makes sense.
Description
•