1879987 - Firefox UI hangs for a long time after moving the window [ GetScreenBounds() / gdk_window_get_root_origin()]

Status: RESOLVED FIXED

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

Description

[mirh]

When I move the browser window on the desktop, the menus just get stuck.
And while webpages still proceed on their own, you cannot interact with them.
This can continue from.. I don't know, 15 to 60 seconds probably?

(I'm not sure what happened to the bugzilla form then - anyway I'm on Manjaro with the Nvidia 545.29.06 drivers. I'm also using the latest stable KDE under X11)

Comment 1

[mirh]

Of note that resizing the window (or enabling and disabling fullscreen) doesn't seem to have any particular performance hit, other than those normal few seconds to presumably recalculate the tab strip sizes and all.

Comment 2

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

This bug was moved into the Performance component.

:mirh, could you make sure the following information is on this bug?

• For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 3

[mirh]

Attachment: support.txt

https://share.firefox.dev/3T3osm4

Btw, after leaving the "just launched" browser open for a full night, and after having tried to simultaneously open like 20 Wikipedia pages.. I think I can rule out the amount of time elapsed or the amount alone of tabs loaded has anything to do with the problem.

Conversely after opening just a dozen Pixiv tabs, I could reproduce the slowdown immediately (even though it's like a few seconds now after a clean start, as opposed to the very bad numbers I mentioned in the OP). Bug 1855859 suggests this may not be so surprising (or who knows, perhaps it's a X11 bug?) but what I'm still missing is why this only happens after some "content" has been opened.

Comment 4

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

Thanks for the profile, mirh, and sorry for the delay in analysis.

This profile is very helpful - I can see the main thread being stuck for several seconds at a time. Firefox appears to be stuck waiting on a reply from the X server, and is polling until that reply comes in.

Moving to the Widget :: Gtk component so that our Gtk folk can take a look.

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Impact on browser: Renders browser effectively unusable
Impact on site: Causes noticeable jank
Configuration: Specific but common
Websites affected: Rare

Comment 5

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

Looks like we're blocked at gdk_window_get_root_origin() call.

Comment 6

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

As a workaround you can use Wayland backend which implements gdk_window_get_root_origin() differently.

Comment 7

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

We may try to cache gdk_window_get_root_origin() values.

Comment 8

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

Attachment: Bug 1879987 [Linux] Cache gdk_window_get_root_origin() window position at nsWindow::GetScreenBounds() r?emilio

Comment 9

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

Let's try the caching:
https://treeherder.mozilla.org/jobs?repo=try&revision=14bc75101b444d60d27c6cb9417f2fcf69a2fa98

Comment 10

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

Attachment: Bug 1879987 [Linux] Cache gdk_window_get_origin() window position at nsWindow::WidgetToScreenOffset() r?emilio

Depends on D204191

Comment 11

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

try: https://treeherder.mozilla.org/jobs?repo=try&revision=33aa3be0b673e6ab20a5e2e69606963affe8d920

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3d46becb9ecd
[Linux] Cache gdk_window_get_root_origin() window position at nsWindow::GetScreenBounds() r=emilio

Comment 13

[Cosmin Sabou [:CosminS]]

Backed out for mochitest failures on test_popupReflowPos.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=3d46becb9ecd34495065a3b309a451e5ae7323b2&selectedTaskRun=Fyl2sKn4T6mfwke2HYgWhQ.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=451275482&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/cabbc2019918c81e8a1e046d9878f5b441a7040d

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c34023ddb0a5
[Linux] Cache gdk_window_get_root_origin() window position at nsWindow::GetScreenBounds() r=emilio

Comment 15

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c34023ddb0a5

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/21247c16b00c
[Linux] Cache gdk_window_get_origin() window position at nsWindow::WidgetToScreenOffset() r=emilio

Comment 17

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/21247c16b00c

Comment 18

[Nicolas Chevobbe [:nchevobbe]]

This has an impact on the console typing test (which display a popup). The first patch triggered alert #41988 (as of Sat, 23 Mar 2024 19:57:26 GMT) ==

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
26%	damp console.typing	linux1804-64-shippable-qr	e10s fission stylo webrender-sw	527.01 -> 666.08
21%	damp console.typing	linux1804-64-shippable-qr	e10s fission stylo webrender	558.17 -> 676.15

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=41988

The second one mitigated this: == Change summary for alert #42022 (as of Wed, 27 Mar 2024 08:57:56 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
14%	damp console.typing	linux1804-64-shippable-qr	e10s fission stylo webrender-sw	662.67 -> 567.51
13%	damp console.typing	linux1804-64-shippable-qr	e10s fission stylo webrender	682.58 -> 592.58

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=42022

---

but overall, this regressed the test a bit

Comment 19

[Acasandrei Beatrice (needinfo me)]

(In reply to Pulsebot from comment #14)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c34023ddb0a5
[Linux] Cache gdk_window_get_root_origin() window position at
nsWindow::GetScreenBounds() r=emilio

== Change summary for alert #42064 (as of Fri, 29 Mar 2024 13:01:51 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
7%	tresize	linux1804-64-shippable-qr	e10s fission stylo webrender-sw	30.01 -> 27.80
7%	tresize	linux1804-64-shippable-qr	e10s fission stylo webrender	30.14 -> 27.96
6%	tresize	linux1804-64-shippable-qr	e10s fission stylo webrender-sw	29.87 -> 27.96

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=42064

Comment 20

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

mirh, can you try latest nightly and check if you see performance improvement?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 21

[mirh]

Yes, absolutely 0 delay now.

Comment 22

[mirh]

Btw do you think this should also be notified to the freedesktop guys?
Or is it not that concerning, and just a specific FF problem?

Comment 23

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

(In reply to mirh from comment #22)

Btw do you think this should also be notified to the freedesktop guys?
Or is it not that concerning, and just a specific FF problem?

It's known issue on X11.