Firefox is unresponsive to user input <60 seconds after startup
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox84 | --- | unaffected |
firefox85 | --- | unaffected |
firefox86 | --- | fixed |
firefox87 | --- | fixed |
People
(Reporter: yoasif, Assigned: stransky)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(7 files, 3 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details |
MOZ_ENABLE_WAYLAND=1 mozregression --good 2020-11-12 --pref "gfx.webrender.software:true"
Going to basically any web page (including about:support
) makes the browser unresponsive to user input - scrolling the page doesn't work, etc.
28:22.70 INFO: No more integration revisions, bisection finished.
28:22.70 INFO: Last good revision: 5c8f76f41e4ee8c3394cb75bac868312b6d5b6f6
28:22.70 INFO: First bad revision: 773f06221b1b1fa04d2dc0c6acefe61b4be7a5b8
28:22.70 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5c8f76f41e4ee8c3394cb75bac868312b6d5b6f6&tochange=773f06221b1b1fa04d2dc0c6acefe61b4be7a5b8
Reporter | ||
Comment 1•4 years ago
|
||
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Set release status flags based on info from the regressing bug 1685055
Comment 3•4 years ago
|
||
Martin, could you look at it before the merge to beta next week? Thanks
Assignee | ||
Comment 4•4 years ago
|
||
Sure. Asif, do you see that with basic compositor too?
Reporter | ||
Comment 5•4 years ago
|
||
Martin, the issue is occurring in Basic as well. Standard WebRender is unaffected.
Assignee | ||
Comment 6•4 years ago
|
||
Can you run Firefox on terminal with Waland log enabled:
MOZ_LOG="WidgetWayand:5" firefox
and check where does it wait?
Assignee | ||
Comment 7•4 years ago
|
||
Do you see the missing response only after start or is that bug present with browsing?
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
I think I saw something similar already. It looked like Firefox works on background (page elements can be clicked on) but web/UI was not updated. But popup windows worked so hamburger menu opened when I clicked on it. Can you confirm such behavior or do you see something different?
Reporter | ||
Comment 9•4 years ago
|
||
Martin, I can't really use the browser in basic or sw-wr modes as it is unusable shortly after beginning to browse.
It looked like Firefox works on background (page elements can be clicked on) but web/UI was not updated. But popup windows worked so hamburger menu opened when I clicked on it. Can you confirm such behavior or do you see something different?
I see this as well. I can reproduce it reliably by navigating to apple.com and scrolling up and down a few seconds. I am able to use the hamburger menu to open new windows, for example.
In the attached log, I opened the browser in basic mode, navigated to apple.com, scrolled up and down, encountered the browser getting stuck, then used the hamburger menu to open a new window and navigated to apple.com in the new window and repeated the issue.
Hope this helps!
Assignee | ||
Comment 10•4 years ago
|
||
Thanks. I tried with latest nightly but without luck. Can you try again and cut the log when the freeze happens? I need to see an exact place in the log when the freeze happens.
Reporter | ||
Comment 11•4 years ago
|
||
Martin, I stopped Firefox (using control-c) in the attached log as soon as I encountered the issue. Hope this helps!
Assignee | ||
Comment 12•4 years ago
|
||
Thanks. Unfortunately I don't see anything wrong there...can you try to open Firefox on one window and open a terminal with the log along it and see if the log is updated while Firefox is frozen? According the log there isn't any freeze or so. I'd expect waiting for Wayland Buffer or so.
Reporter | ||
Comment 13•4 years ago
|
||
The log doesn't stop when Firefox is frozen. The only time the log stops is when I fullscreen GNOME Terminal and Firefox is in the background. If I bring Firefox back to the foreground, the log resumes.
Assignee | ||
Comment 14•4 years ago
|
||
(In reply to Asif Youssuff from comment #13)
The log doesn't stop when Firefox is frozen. The only time the log stops is when I fullscreen GNOME Terminal and Firefox is in the background. If I bring Firefox back to the foreground, the log resumes.
Thanks! That means Firefox actually paints the web content but compositor does not show it. I inspected the log and the buffers seem to be attached correctly. Can you please try to dump wl_buffers which Firefox sends to compositor? And please use basic compositor, not sw-wr one.
Run Firefox on terminal as:
MOZ_WAYLAND_DUMP_WL_BUFFERS=1 MOZ_ENABLE_WAYLAND=1 firefox
You should have *.png files in your current working dir, the images contains painting which is send by Firefox to compositor. Please check if the screens are correct, i.e. there's some content which is expected to be painted (but the painting from some reason fails as you see).
Also which mutter version do you run?
Thanks.
Reporter | ||
Comment 15•4 years ago
|
||
Martin, running in Basic mode and with MOZ_WAYLAND_DUMP_WL_BUFFERS=1 runs very slowly and doesn't appear to stop responding. The browser remains responsive after a minute or two (while saving hundreds of images), unlike when dumping buffers is enabled.
The screenshots seem fine and correspond to what I see on the screen.
mutter-common is 3.38.2-1ubuntu1 - I am running a live session, so it is a consistent environment. mutter is not installed.
Updated•4 years ago
|
Assignee | ||
Comment 16•4 years ago
|
||
Thanks Asif. Right now I'm out of idea what can cause it...it's also interesting that you can reproduce it reliably.
Maybe Wayland log can help. Please run Firefox as:
WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayand:5" firefox
that will produce the wayland+widget log. Please leave it running for a short time when it's frozen (say 5 sec) and then quit the browser. I'd need to have the log small for better readability.
Thanks.
Reporter | ||
Comment 17•4 years ago
|
||
Reporter | ||
Comment 18•4 years ago
|
||
Reporter | ||
Comment 19•4 years ago
|
||
Martin, I took two logs because I was unsure if you wanted me to quit via Control-q or by exiting the app from the terminal it was launched from (Control-c).
Please see attached logs:
quit.txt.moz_log - quit using control-q
force-quit.txt.moz_log - quit from terminal using control-c
Hope this helps!
Assignee | ||
Comment 20•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 21•4 years ago
|
||
Depends on D103185
Assignee | ||
Comment 22•4 years ago
|
||
Thanks. From the log it looks like we're not getting new buffers so the painting is cached. But I'd need more log info so I did more logging to the buffer management code. I'll ask you for another log when the patch here is in nightly.
Thanks.
Comment 23•4 years ago
|
||
Comment 24•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/59e780d9359a
https://hg.mozilla.org/mozilla-central/rev/466211e554bc
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 25•4 years ago
|
||
Asif, can you please provide log from latest nightly? It contains extra logging for the missing buffers.
Thanks.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Reporter | ||
Comment 26•4 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #25)
Asif, can you please provide log from latest nightly? It contains extra logging for the missing buffers.
Thanks.
Martin, sure.
I took two logs because I was unsure if you wanted me to quit via Control-q or by exiting the app from the terminal it was launched from (Control-c).
Command used:
MOZ_LOG_FILE="log.txt" MOZ_ENABLE_WAYLAND=1 WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayland:5" ./firefox/firefox
Please see attached logs:
quit.txt.moz_log - quit using control-q
force-quit.txt.moz_log - quit from terminal using control-c
Hope this helps!
Reporter | ||
Comment 27•4 years ago
|
||
Reporter | ||
Comment 28•4 years ago
|
||
Assignee | ||
Comment 29•4 years ago
|
||
Thanks. The control-c from terminal is better. I did some painting rework at Bug 1667851 and I'll look at this one then.
Assignee | ||
Comment 30•4 years ago
|
||
Comment 31•4 years ago
|
||
Comment 32•4 years ago
|
||
bugherder |
Assignee | ||
Comment 33•4 years ago
|
||
Comment on attachment 9201124 [details]
Bug 1687212 [Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r?jhorak
Beta/Release Uplift Approval Request
- User impact if declined: Freezes on Wayland backend.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Only reorder commit flag setting to set it before it's checked.
- String changes made/needed:
Comment 34•4 years ago
|
||
Comment on attachment 9201124 [details]
Bug 1687212 [Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r?jhorak
Low risk for mozilla builds as we don't ship Wayland by default officially yet, approved for 86 beta 8, thanks.
Comment 35•4 years ago
|
||
bugherder uplift |
Description
•