Closed mfschumann closed 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.
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.
Try flatpak run --log-session-bus eu.betterbird.Betterbird -compose "to=some@mail.com"
and paste the output
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.
I put my money on this: https://searchfox.org/comm-central/search?q=org.mozilla.*APP&path=nsDBusRemote&case=false®exp=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®exp=true
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®exp=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.
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.
I am unable to open a message compose window
flatpak run eu.betterbird.Betterbird -compose "to=some@mail.com"
orwhen another Betterbird flatpak instance is already running. The following error message is shown:![image](https://user-images.githubusercontent.com/9102962/192162226-cafaf90c-eb96-4370-8cc8-57c97cfe49cb.png)
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:
--own-name
argument (because of a comment in the flatpak manifest for Thunderbird). I have triedeu.betterbird.betterbird_default.*
,eu.betterbird.betterbird.*
,eu.betterbird.Betterbird_default.*
,eu.betterbird.Betterbird.*
, and evenorg.mozilla.thunderbird_default.*
(the one used for the Thunderbird flatpak).@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?