1645038 - [Regression?] Since a few days ago, I sometimes can't open links in thunderbird, discord, and similar to open up in Nightly anymore

Status: RESOLVED DUPLICATE of bug 1724242

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

Description

[Ellie]

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

Steps to reproduce:

Since a few days ago, I sometimes can't open links in thunderbird, discord, and similar to open up in Nightly anymore. Instead of the link opening, I always get this message box:

"Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile."

Interestingly it seems to vary for where it's launched from and just randomly flip on various days, e.g. today links from Thunderbird work fine and open instantly, but all the links opened from Discord don't work and get me this error. Yesterday, none of the Thunderbird links would work either. However, opening the links via "xdg-open https://url" did work fine yesterday.

1. Click a link in any program not firefox

Actual results:

In some programs on some days, the link won't then get opened in firefox but I see this instead: "Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile."

Expected results:

Link always opens, no matter which program I opened it with

Comment 1

[Ellie]

I just updated Nightly, and now links from Discord work but all from Thunderbird give me the error :-D it's pretty wild

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Ellie]

This is possibly a major regression, so if others suffer from this too then it should possibly be fixed. It's still broken for me right now, a couple of nightly updates further in

Comment 4

[Ellie]

This is still broken for me. Any ideas?

Comment 5

[Ellie]

I am also seeing this in xdg-open now sometimes, Thunderbird almost all the time, other programs tend to work now. Just to reiterate, this is a really major problem in practice, so if this was actually fixed that would be extremely helpful.

Comment 6

[Ellie]

Here is some information about what exactly xdg-open appears to be calling:

$ xdg-mime query default x-scheme-handler/https
userapp-Nightly-J5NAC0.desktop
$ locate userapp-Nightly-J5NAC0.desktop
/home/ellie/.local/share/applications/userapp-Nightly-J5NAC0.desktop
$ cat /home/ellie/.local/share/applications/userapp-Nightly-J5NAC0.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/home/ellie/firefox/firefox-bin %u
Name=Nightly
Comment=Custom definition for Nightly
$ ls /home/ellie/firefox --width=0
application.ini  browser  crashreporter  crashreporter.ini  defaults  dependentlibs.list  dmd.py  firefox  firefox-bin  firefox-bin.sig  firefox.sig  fix_stacks.py  fonts  gmp-clearkey  gtk2  icons  libfreeblpriv3.so  libgraphitewasm.so  liblgpllibs.so  libmozavcodec.so  libmozavutil.so  libmozgtk.so  libmozsandbox.so  libmozsqlite3.so  libmozwayland.so  libnspr4.so  libnss3.so  libnssckbi.so  libnssutil3.so  liboggwasm.so  libplc4.so  libplds4.so  libsmime3.so  libsoftokn3.so  libssl3.so  libxul.so  libxul.so.sig  minidump-analyzer  omni.ja  pingsender  platform.ini  plugin-container  plugin-container.sig  precomplete  removed-files  Throbber-small.gif  updater  updater.ini  updates  update-settings.ini  updates.xml

Currently, I'm on 84.0a1 (2020-10-31) (64-bit) with this being a Fedora 32 (likely Fedora 33 soon).

Comment 7

[Ellie]

A very helpful person on Matrix helped me collect a few facts that might be relevant:

1. I switch to newly created blank profiles 1-2 times a month to check out whether a bug in nightly is related to my profile settings (since I use nightly in part to give feedback on bugs). However, right now I am on the profile that is also the one that launches by default (when I don't specify -P) and also was when this bug hit me today again, and usually am when it happens. So it doesn't seem to be related to currently running a non-default profile, but I definitely got quite a bunch of other profiles lying around that I occasionally run which may or may not be related.

2. My current default profile is NOT the one nightly originally created, I think. I don't know why, I probably once accidentally stuck with a testing profile for a while and decided to keep using it as my new default profile. Not sure if this is relevant either.

3. This link opening failing with the "Firefox is already running" happens both when there is an update scheduled, and when there isn't. When it happens when there is an update scheduled it will sometimes cause the update to be applied even though firefox is still running, and then opening new tabs gives me an error that it needs to restart because files changed on disk in the middle of things and it can't operate properly anymore. This is also something I would not expect to happen, and maybe might give you an additional clue.

4. Before 2020 this pretty much never happened, now it happens quite often in overall (but not regularly on a SMALL scale, so it's hard to regression test. sometimes it just works fine for a day, or just breaks from some programs while it works opening links from another, or works again after restarting firefox. it's very weird). Other than just the Fedora twice a year upgrades I don't really changed much with this machine, so that is why I'm assuming it might be a regression on the Firefox side.

Comment 8

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi Ellie,

Setting a component for this in order to get the dev team involved. May be fedora specific.
(If the team feels it's an incorrect one please feel free to change it to a more appropriate one.)

Please include your about:support information.
Can you replicate this issue with opening links in safe mode?
Best, Clara

Comment 9

[Ellie]

I could be completely wrong but I think that component might still be incorrect, because the problem is clicking links in OTHER apps than firefox that then are supposed to open in firefox (since it is my default browser). xdg-open from command line is also affected, sometimes. (It is very unreliable to reproduce.) So I think something with the IPC that figures out firefox already is running, and/or the user profile handling is probably involved. I'm not sure DOM Navigation would be relevant.

I can test running the browser in safe mode for a while to see if I ever see it then, but it would possibly take me a few days to give you an answer with any confidence if that helps. The issue is just pretty rare. Additionally, if it works on a blank profile that actually wouldn't surprise me, since it might be related to me using a non-default profile - or not, who knows. In any case, I'm not sure that would necessarily be immediately useful for telling what is going on.

If I had to make a guess myself, I think what might be useful is if anyone can tell me how to collect any logs that happen when firefox launches, and does the IPC with itself/any previous processes running, and/or the discovery of firefox processes already running, that might tell a developer what is going on. But maybe somebody familiar with the whole internals of the launching, IPC, and process discovery has a better idea on what would be useful.

Comment 10

[Ellie]

Attachment: about:support raw data export (JSON)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

https://mastransky.wordpress.com/2020/03/16/wayland-x11-how-to-run-firefox-in-mixed-environment/
might help here

I'm using MOZ_DBUS_REMOTE environment variable and set the right default browser in gnome settings.

Comment 12

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

Can you attach output of terminal command:

env | grep DISPLAY

Thanks.

We may need to enable DBUS remote on XWayland by default.

Comment 13

[Ellie]

$ env | grep DISPL
WAYLAND_DISPLAY=wayland-0
GNOME_SETUP_DISPLAY=:1
DISPLAY=:0

I am indeed running GNOME Wayland, so XWayland could be related to whatever the problem is

Comment 14

[Ellie]

Ok, so I tried MOZ_DBUS_REMOTE=1 and it had these two combined effects:

1. Opening links from thunderbird and everywhere else works now, so that's good

2. Thunderbird (as packaged by Fedora) and Nightly (official mozilla build) now need excruciatingly long for their first start, like a minute or longer. For firefox I also spotted some defunct zombie processes during startup, not sure if related, but it all seems quite fishy. However once they opened they both work fine.

So that's kind of a mixed bag. Seems like enabling dbus doesn't really lead to a satisfactory situation either, summed up

Comment 15

[Ellie]

Just to underline this is a very significant problem, I measured and with MOZ_DBUS_REMOTE=1 thunderbird just took over 1.5 minutes(!) to start for me, and firefox over 6.5(!!) minutes. Previously, it used to be <5 seconds for both. Since links being opened works always now and I don't reboot too often during the day this is still an improvement, but obviously doesn't feel even nearly as proper as a solution as it should.

Comment 16

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

I wonder why DBus causes such delay here.

Comment 17

[Ellie]

So what could I possibly collect to help you debug this? While links do open, they also have one of these super long delays (still better than not opening at all though), both for Firefox and Thunderbird. Something with the DBus handling therefore seems to be wrong in both programs.

Comment 18

[Ellie]

This works for me now (no launch delay anymore), was there any change? I am wondering if I should leave this open though, since I'm not sure whether MOZ_DBUS_REMOTE=1 is now the default when firefox or thunderbird launch on Wayland desktops. Is it? Because it probably really should be.

Comment 19

[Gian-Carlo Pascutto [:gcp]]

I'm not sure whether MOZ_DBUS_REMOTE=1 is now the default when firefox or thunderbird launch on Wayland desktops. Is it? Because it probably really should be.

That was discussed and rejected in bug 1677462 (as far as I understand).

Comment 20

[Darkspirit]

(In reply to Ellie from comment #14)

Ok, so I tried MOZ_DBUS_REMOTE=1 and it had these two combined effects:

1. Opening links from thunderbird and everywhere else works now, so that's good

= Fixed by bug 1724242.

2. Thunderbird (as packaged by Fedora) and Nightly (official mozilla build) now need excruciatingly long for their first start, like a minute or longer. For firefox I also spotted some defunct zombie processes during startup, not sure if related, but it all seems quite fishy. However once they opened they both work fine.

= WFM per comment 18