1569625 - [Snap] Firefox is slow to open, close and switch tabs in Xwayland

Status: RESOLVED WORKSFORME

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

Description

[aceler]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Firefox is launched as a XWayland app, i.e. just launched under wayland session.

When Firefox is launched as an X11 app in an X11 session, or it is launched as a native wayland app in a wayland session using GDK_BACKEND=wayland env, all is fine.

Actual results:

Firefox opens, closes and switch tabs with a very big latency. This happens only if the window is in a maximized state. If the window is in non-maximized state, or if the window in in a full-screen mode (F11), Firefox works as expected.

Tried with a new profile and safe-mode. I have AMD RX560 with open-source videodriver under Ubuntu 19.04.

Comment 1

[Liviu Seplecan]

Hi @aceler, I don't have the proper environment to test it. What I can do for now is to set a component and maybe someone from dev's team could give us a hand.
Thanks.

Comment 2

[abougouffa]

Hi,

I confirm the issues reported by @aceler, I have exactly the same behavior.
I'm using Firefox version 70.0 on Arch Linux

Comment 3

[vita.amaro]

Confirm. Firefox 71 beta affected aswell...

Comment 4

[vita.amaro]

(In reply to vita.amaro from comment #3)

Confirm. Firefox 71 beta affected aswell...

By the way it lag only if i use some extension hiding top gnome panel. And only on wayland. If i use x or turn off extension everything okey.

Comment 5

[Woyece]

I've the same annoying problem on wayland (FF nightly 78.0a1 - FF 76.0.1).

Comment 6

[mathieu.bousquet2]

Same here (FF78), I can confirm that this bug is present when using the "hide top bar" gnome-shell extension

Comment 7

[henry78]

This also happens on Wayland also without an extension hiding the top-bar. (FF78). Here I noticed the issue for the first time, after setting the panel ("Dash to Panel") to autohide and FF used the whole screen. But this might be similar to top-bar-hiding(?).

Comment 8

[sgraf1337]

https://github.com/mozilla/nixpkgs-mozilla/issues/163#issuecomment-822058334 might be related: Note that FF 67 introduced one-profile-per-install which was worked around (in nixpkgs) by passing SNAP_HOME=firefox in a wrapper script. That's no longer necessary since FF 69, which has MOZ_LEGACY_PROFILES='1' for that and it caused real harm for me in that I experienced quite similar symptoms as the OP since FF 85. Getting rid of the SNAP_HOME setting fixed it for me. Not sure if this generalises much to other users, but it might help devs to bin down what's going on.

Comment 9

[sgraf1337]

It appears that (the length of?) XDG_DATA_DIRS also plays a role: There are 52 entries for me (most of which are GNOME-specific paths into the Nix store) and if I unset them, firefox is no longer slow.

Comment 10

[sgraf1337]

I bisected the entries in XDG_DATA_DIRS and found out that it's not the length, but the size of one the directories: ~/.nix-profile/share is generated by home-manager and is huge. Apparently, Firefox with SNAP_NAME=firefox will repeatedly parse those directories and I've no idea why that's necessary. Something similar might apply to huge ~/.local/share folders.

Comment 11

[:gerard-majax]

Can you update whether you still have the issue ?

Comment 12

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.