1687212 - Firefox is unresponsive to user input <60 seconds after startup

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Asif Youssuff]

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

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

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

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

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

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

Comment 4

[Martin Stránský [:stransky] (ni? me)]

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

Comment 5

[Asif Youssuff]

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

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Can you run Firefox on terminal with Waland log enabled:

MOZ_LOG="WidgetWayand:5" firefox

and check where does it wait?

Comment 7

[Martin Stránský [:stransky] (ni? me)]

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

Comment 8

[Martin Stránský [:stransky] (ni? me)]

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?

Comment 9

[Asif Youssuff]

Attachment: log.txt.moz_log

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!

Comment 10

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 11

[Asif Youssuff]

Attachment: log.txt.moz_log

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

Comment 12

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 13

[Asif Youssuff]

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.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

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

Comment 15

[Asif Youssuff]

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.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 17

[Asif Youssuff]

Attachment: quit.txt.moz_log

Comment 18

[Asif Youssuff]

Attachment: force-quit.txt.moz_log

Comment 19

[Asif Youssuff]

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!

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1687212 [Wayland] Provide wayland buffer logging to wayland window surface, r?jhorak

Comment 21

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1687212 [Wayland] Remove UnlockWaylandBuffer() and related code as it's not used, r?jhorak

Depends on D103185

Comment 22

[Martin Stránský [:stransky] (ni? me)]

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

[Pulsebot]

Pushed by [e-mail]:
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

Comment 24

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/59e780d9359a
https://hg.mozilla.org/mozilla-central/rev/466211e554bc

Comment 25

[Martin Stránský [:stransky] (ni? me)]

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

Comment 26

[Asif Youssuff]

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

Comment 27

[Asif Youssuff]

Attachment: quit.txt.moz_log

Comment 28

[Asif Youssuff]

Attachment: force-quit.txt.moz_log

Comment 29

[Martin Stránský [:stransky] (ni? me)]

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

Comment 30

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1687212 [Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r?jhorak

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/05098560d311
[Wayland] Set mAttached flag before wl_surface_commit() to avoid potential race condition, r=jhorak

Comment 32

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/05098560d311

Comment 33

[Martin Stránský [:stransky] (ni? me)]

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

[Pascal Chevrel:pascalc (PTO until April 26)]

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

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/45beb340a539