Closed Bug 1687212 Opened 4 years ago Closed 4 years ago

Firefox is unresponsive to user input <60 seconds after startup

Categories

(Core :: Widget: Gtk, defect)

defect

Tracking

()

RESOLVED FIXED
87 Branch
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)

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
Attached file about:support (deleted) —
Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1685055

Set release status flags based on info from the regressing bug 1685055

Martin, could you look at it before the merge to beta next week? Thanks

Flags: needinfo?(stransky)

Sure. Asif, do you see that with basic compositor too?

Flags: needinfo?(stransky) → needinfo?(yoasif)

Martin, the issue is occurring in Basic as well. Standard WebRender is unaffected.

Flags: needinfo?(yoasif)

Can you run Firefox on terminal with Waland log enabled:

MOZ_LOG="WidgetWayand:5" firefox

and check where does it wait?

Flags: needinfo?(yoasif)

Do you see the missing response only after start or is that bug present with browsing?

Summary: Firefox is unresponsive to user input <60 seconds after startup when using sw-wr → Firefox is unresponsive to user input <60 seconds after startup

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?

Attached file log.txt.moz_log (obsolete) (deleted) —

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!

Flags: needinfo?(yoasif)

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.

Flags: needinfo?(yoasif)
Attached file log.txt.moz_log (deleted) —

Martin, I stopped Firefox (using control-c) in the attached log as soon as I encountered the issue. Hope this helps!

Attachment #9198373 - Attachment is obsolete: true
Flags: needinfo?(yoasif)

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.

Flags: needinfo?(yoasif)

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.

Flags: needinfo?(yoasif)

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

Flags: needinfo?(yoasif)

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.

Flags: needinfo?(yoasif)

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.

Flags: needinfo?(yoasif)
Attached file quit.txt.moz_log (obsolete) (deleted) —
Attached file force-quit.txt.moz_log (obsolete) (deleted) —

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!

Flags: needinfo?(yoasif)
Assignee: nobody → stransky
Status: NEW → ASSIGNED

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.

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/59e780d9359a [Wayland] Provide wayland buffer logging to wayland window surface, r=jhorak https://hg.mozilla.org/integration/autoland/rev/466211e554bc [Wayland] Remove UnlockWaylandBuffer() and related code as it's not used, r=jhorak
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Asif, can you please provide log from latest nightly? It contains extra logging for the missing buffers.
Thanks.

Flags: needinfo?(yoasif)
Target Milestone: 87 Branch → ---
Status: REOPENED → ASSIGNED

(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!

Flags: needinfo?(yoasif)
Attached file quit.txt.moz_log (deleted) —
Attachment #9199450 - Attachment is obsolete: true
Attached file force-quit.txt.moz_log (deleted) —
Attachment #9199451 - Attachment is obsolete: true

Thanks. The control-c from terminal is better. I did some painting rework at Bug 1667851 and I'll look at this one then.

Flags: needinfo?(stransky)
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/05098560d311 [Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r=jhorak
Status: ASSIGNED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

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:
Flags: needinfo?(stransky)
Attachment #9201124 - Flags: approval-mozilla-beta?

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.

Attachment #9201124 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Blocks: 1694038
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: