Firefox taking longer to launch
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox97 | --- | unaffected |
firefox98 | --- | fixed |
firefox99 | --- | fixed |
People
(Reporter: souravgoswami24111997s, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
10.00 MB,
application/octet-stream
|
Details | |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta-
|
Details | Review |
2.10 KB,
patch
|
pascalc
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
Updated firefox to 64bit 98.0b2 on Linux (Arch) and firefox taking way longer to launch that it did ever before.
The same problem persists in FF 98.0b4.
Actual results:
I'm using an NVME M.2 storage for root partition and SATA III SSD for /home/. Previously firefox just took < 1 second to launch. But now the launching time is no less than 20 seconds.
The problem only occurs after a boot. Once firefox is loaded, even if I kill the process and relaunch, it launches just fine.
Reporter | ||
Comment 1•3 years ago
|
||
Here's the 10 MiB strace file, if that helps.
Reporter | ||
Updated•3 years ago
|
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•3 years ago
|
||
Please use mozregression to find the broken commit:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.
Assignee | ||
Comment 4•3 years ago
|
||
This smells like broken dbus, probably introduced by bug 1734934 or thereabouts? Can you look on your journal for potential D-BUS errors?
Assignee | ||
Comment 5•3 years ago
|
||
Alternatively, can you paste the output of MOZ_LOG=LookAndFeel:5 /path/to/firefox
?
Assignee | ||
Comment 6•3 years ago
|
||
If comment 4 is right, then the patch above should fix, but we should confirm first.
Assignee | ||
Comment 7•3 years ago
|
||
Reporter | ||
Comment 8•3 years ago
|
||
Hi, sorry for late reply. I've tried mozregression, but it didn't detect anything - maybe because as I said, firefox is slow on the first run, and from the 2nd launch, it's normally fast.
I'll debug with MOZ_LOG=LookAndFeel:5 and try to see if I can get any journal messages from dbus-errors.
Reporter | ||
Comment 9•3 years ago
|
||
Did a journalctl -f
and the output is as the following:
Feb 18 23:16:59 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.33' (uid=1000 pid=1018 comm="/opt/firefox-developer-edition/firefox ")
Feb 18 23:16:59 archlinux systemd[623]: Starting Portal service...
Feb 18 23:16:59 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Activating via systemd: service name='org.freedesktop.portal.Documents' unit='xdg-document-portal.service' requested by ':1.35' (uid=1000 pid=1077 comm="/usr/lib/xdg-desktop-portal ")
Feb 18 23:16:59 archlinux systemd[623]: Starting flatpak document portal service...
Feb 18 23:16:59 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Activating via systemd: service name='org.freedesktop.impl.portal.PermissionStore' unit='xdg-permission-store.service' requested by ':1.36' (uid=1000 pid=1081 comm="/usr/lib/xdg-document-portal ")
Feb 18 23:16:59 archlinux systemd[623]: Starting sandboxed app permission store...
Feb 18 23:16:59 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore'
Feb 18 23:16:59 archlinux systemd[623]: Started sandboxed app permission store.
Feb 18 23:16:59 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Successfully activated service 'org.freedesktop.portal.Documents'
Feb 18 23:16:59 archlinux systemd[623]: Started flatpak document portal service.
Feb 18 23:16:59 archlinux xdg-desktop-por[1077]: No skeleton to export
Feb 18 23:16:59 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.wlr' unit='xdg-desktop-portal-wlr.service' requested by ':1.35' (uid=1000 pid=1077 comm="/usr/lib/xdg-desktop-portal ")
Feb 18 23:16:59 archlinux systemd[623]: Portal service (wlroots implementation) was skipped because of a failed condition check (ConditionEnvironment=WAYLAND_DISPLAY).
Feb 18 23:17:45 archlinux xdg-desktop-por[1077]: Failed to create screenshot proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.wlr: Timeout was reached
Feb 18 23:17:45 archlinux xdg-desktop-por[1077]: No skeleton to export
Feb 18 23:18:10 archlinux xdg-desktop-por[1077]: Failed to create screen cast proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.wlr: Timeout was reached
Feb 18 23:18:10 archlinux xdg-desktop-por[1077]: No skeleton to export
Feb 18 23:18:10 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Successfully activated service 'org.freedesktop.portal.Desktop'
Feb 18 23:18:10 archlinux systemd[623]: Started Portal service.
After some more time, when firefox is already running:
Feb 18 23:19:20 archlinux dbus-daemon[643]: [session uid=1000 pid=643] Failed to activate service 'org.freedesktop.impl.portal.desktop.wlr': timed out (service_start_timeout=120000ms)
Reporter | ||
Comment 10•3 years ago
|
||
After removing xdg-desktop-portal-wlr
package, the problem is fixed.
Actually this problem isn't new. A lot of the apps depending on this package had problem in the past.
https://gitlab.gnome.org/World/gcolor3/-/issues/126
It could be because of the dbus changes?
Reporter | ||
Comment 11•3 years ago
|
||
(In reply to souravgoswami24111997s from comment #10)
After removing
xdg-desktop-portal-wlr
package, the problem is fixed.
Actually this problem isn't new. A lot of the apps depending on this package had problem in the past.https://gitlab.gnome.org/World/gcolor3/-/issues/126
It could be because of the dbus changes?
BTW removing xdg-desktop-portal-wlr
with pacman -Rns
also removes xdg-desktop-portal
.
Here's another one I faced some time ago:
https://github.com/flatpak/xdg-desktop-portal-gtk/issues/332#
Anyway, if I can help by installing the package again. Currently it's an easy fix that doesn't probably provide much insight. But a mere speculation is that it's probably caused by the recent dbus changes as you suspected?
Assignee | ||
Comment 12•3 years ago
|
||
Yeah, so my patch indeed introduced the issue, by introducing the DBUS query that is timing out. There's not all that much we can do on our end tbh, other than something like comment 7 to prevent startup from taking too long, it's really a misconfiguration on your machine.
Jan, fyi since it seems just installing the wlroots desktop portal implementation can cause this. Do you know how common such misconfiguration can be?
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 13•3 years ago
|
||
This seems to be caused by a long-standing DBus issue where there is no feedback about a failed activation from systemd
back to dbus-daemon
, so the latter fruitlessly waits for the name to appear. Maybe dbus-broker
handles this better?
When installing xdg-desktop-portal, the user is asked to install an implementation. For this prompt, xdg-desktop-portal-gnome
is the default choice. I don't think this is a common problem.
Assignee | ||
Comment 14•3 years ago
|
||
(In reply to Jan Alexander Steffens [:heftig] from comment #13)
This seems to be caused by a long-standing DBus issue where there is no feedback about a failed activation from
systemd
back todbus-daemon
, so the latter fruitlessly waits for the name to appear. Maybedbus-broker
handles this better?
Curious, do you have a link for this issue? No big deal if not :)
Comment 15•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)
Curious, do you have a link for this issue? No big deal if not :)
Sorry, I thought I remembered something from long ago on the Freedesktop Bugzilla, but I can no longer find it.
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Set release status flags based on info from the regressing bug 1734934
Comment 17•3 years ago
|
||
Updated•3 years ago
|
Comment 18•3 years ago
|
||
bugherder |
Comment 19•3 years ago
|
||
Emilio, this is a regression introduced in 98, is that a patch we should uplift to 99 or is that uncommon enough that we can let it ride the trains? Thanks
Assignee | ||
Comment 20•3 years ago
|
||
Comment on attachment 9264497 [details]
Bug 1755419 - Don't use default system timeout for settings proxy. r=stransky
Beta/Release Uplift Approval Request
- User impact if declined: Slow startup on misconfigured machines.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- 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): Introduces an smaller timeout for startup-critical code.
- String changes made/needed: none
Comment 21•3 years ago
|
||
Emilio, the patch does not graft cleanly to beta, could you provide a rebased patch? Thanks
Assignee | ||
Comment 22•3 years ago
|
||
Updated•3 years ago
|
Comment 23•3 years ago
|
||
Comment on attachment 9265172 [details] [diff] [review]
Beta patch.
Approved for our last 98 beta, thanks!
Comment 24•3 years ago
|
||
bugherder uplift |
Description
•