search

flathub / eu.betterbird.Betterbird

https://flathub.org/apps/details/eu.betterbird.Betterbird
9 stars 1 forks source link

Cannot start message composer when another instance is running #33

Closed mfschumann closed 1 year ago

mfschumann commented 1 year ago

I am unable to open a message compose window

when another Betterbird flatpak instance is already running. The following error message is shown: image

Both the binary distributed via betterbird.eu and the Thunderbird flatpak do not show this behavior, but instead a compose window is opened in the running instance as expected. So the issue seems to be caused by some error in the building or packaging that is specific to the flatpak version of Betterbird.

I have tried the following without any effect:

@Erick555, @Betterbird: Do you have an idea how detection of the running instance works and what could go wrong in this case? Can you give me any hints on how to debug this issue?

Betterbird commented 1 year ago

I'm confused. The comment said that you (unsuccessfully?) tried eu.betterbird.betterbird_default.*, yet that is what the pull request "add own-name to make running instance detection work under wayland" adds. Anyway, I won't be of help here, especially given that our binary works.

mfschumann commented 1 year ago

The PR #32 was an unsuccessful attempt to fix the issue by adding the own-name argument, since this was the only difference I found relevant when comparing the flatpak manifests for Betterbird and Thunderbird. I kept the PR open because like that I can easily get test builds while trying to fix the issue.

Erick555 commented 1 year ago

Try flatpak run --log-session-bus eu.betterbird.Betterbird -compose "to=some@mail.com" and paste the output

mfschumann commented 1 year ago

Thanks, that helped. It seems the dbus call does not match because it uses the id org.mozilla.betterbird (full log: flatpak-run-session-bus.log):

C20: -> org.mozilla.betterbird.ZGVmYXVsdA__ call org.mozilla.betterbird.OpenURL at /org/mozilla/betterbird/Remote

When adding --own-name='org.mozilla.betterbird.*' to flatpak run the issue is gone. Do you know how the id org.mozilla.betterbird is generated? I think it would make sense for betterbird to add a patch that changes the id to eu.betterbird.betterbird or so.

Betterbird commented 1 year ago

I put my money on this: https://searchfox.org/comm-central/search?q=org.mozilla.*APP&path=nsDBusRemote&case=false&regexp=true

    mozilla/toolkit/components/remote/nsDBusRemoteClient.cpp
142 pathName = nsPrintfCString("/org/mozilla/%s/Remote", appName.get());
153 remoteInterfaceName = nsPrintfCString("org.mozilla.%s", appName.get());
    mozilla/toolkit/components/remote/nsDBusRemoteServer.cpp
66  errorMsg = nsPrintfCString("org.mozilla.%s.Error", mAppName.get());
96  ourInterfaceName = nsPrintfCString("org.mozilla.%s", mAppName.get());
157 nsPrintfCString busName("org.mozilla.%s.%s", mAppName.get(),
170 busName = nsPrintfCString("org.mozilla.%s.%s", mAppName.get(), "default");
189 mPathName = nsPrintfCString("/org/mozilla/%s/Remote", mAppName.get());

Maybe not a good idea to patch that since we don't know what else will break if we change it. There are heaps of constructs of this kind: https://searchfox.org/comm-central/search?q=org.mozilla.*APP&path=&case=false&regexp=true

mfschumann commented 1 year ago

Maybe not a good idea to patch that since we don't know what else will break if we change it. There are heaps of constructs of this kind: https://searchfox.org/comm-central/search?q=org.mozilla.*APP&path=&case=false&regexp=true

Hm, to me these occurrences seem pretty unrelated, but I'm really not an expert on TB/mozilla source code. If you decide against patching I will add the --own-name='org.mozilla.betterbird.*' workaround for flatpak packaging, so the issue will be resolved either way. Just let me know your decision and I will either wait for your patch or add the workaround.

Betterbird commented 1 year ago

Let's go with org.mozilla.betterbird.*. This string is not visible to the user. It was a bit different for the WM_CLASS which used to be thunderbird (https://github.com/Betterbird/thunderbird-patches/issues/75). Undeniably Betterbird is based on Mozilla software and we don't want to weed out every little bit of it. Have you noticed that the user agent string is still Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0? It's different in the mail header. This is done for a reason: If you browse a feed URL with BB, the client should be treated like TB. We've seen cases where websites react differently based on the UA string and it's possible that Betterbird wouldn't be a recognised browser.