fcitx stop working at flatpak 1.0.0

[nakamuray]

Linux distribution and version

ubuntu 18.04

Flatpak version

1.0.0 (from ppa:alexlarsson/flatpak)

Description of the problem

After upgrading flatpak from 0.99.3 to 1.0.0, I can't input japanese characters on slack app.
While fcitx (mozc) is activated (input method indicator is apeard around cursor), typing keyboard has no effect.
Downgrading to 0.99.3 bring back to expected behavior.

Steps to reproduce

1. setup fcitx on host side
2. install slack app from flathub and run it
3. activate fcitx (mozc) and type something

[alexlarsson]

Hmm, this is probably due to a small change in how the dbus proxy works that was made to future proof the portals. In particular, this commit: ef9297a

We used to allow sandboxed apps to receive all broadcasts from portals, but we now limit them to those under the /org/freedesktop/portal object path. I wonder if the fcitx portal was using this? If so, it would need to change the broadcast object paths.

[nakamuray]

I confirmed that at least on flatpak 1.0.0 without ef9297a (rebuild deb package with patch which revert the commit), fcitx works as expected.

[alexlarsson]

I realize this is a breaking change, but its unfortunately required for security reasons. However, it should be fixable, and If you have patches to fcitx I can apply them in the runtimes.

[trulyliu]

I am also affected by this issue.
Should we patch fcitx? How?

[nanonyme]

@alexlarsson if we need changes in freedesktop-sdk, we should probably have a copy of this on that side, right?

[nanonyme]

Opened https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/728 so this gets tracked on runtime-side as well.

[Areiser]

I'm glad this is receiving attention. I still can't use Anki because I can't input vocabulary.

[alexlarsson]

So, I'm not sure exactly what needs to change, because I don't know exactly how fcitx clients talk to the fcitx portal daemon. However, what changed was a detail in which dbus messages was allowed by default.

It used to be the case that all direct messages to any dbus names called org.freedesktop.portal.* were allowed to be sent, and all broadcasts message from the same names are allowed to be received by the sandboxed. However, in later versions of flatpak the later has changed. Any broadcast from org.freedesktop.portal.* must now have an object path starting with /org/freedesktop/portal for it to be received by the sandboxed app.

[alexlarsson]

If you want to see what fcitx does, run dbus-monitor --session while running whatever is not working.
Alternatively you can flatpak run --log-session-bus ..., although the output from that isn't super-easy to understand.

[nanonyme]

Maybe whoever can reproduce this should just collect the output and attach here for further analysis?

[daotrunghieu]

Hello,

I'm using fcitx as my input method and I found an approach helps me type freely in flatpak applications has runtime: org.kde.Platform/x86_64/5.12

$ flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app-id>
or
$ flatpak --user override --socket=session-bus <app-id> (too much?)

In my system (flatpak-1.2.4-1.fc29), three applications were tested: com.slack.Slack; net.ankiweb.Anki; org.telegram.desktop.

[nanonyme]

The latter is definitely too much, it's a blanket permission for granting access to everything in session bus.

[magiruuvelvet]

I just tested flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app-id> on some apps and it works great. Thanks for figuring this out ❤️

I'm on Arch Linux running the latest flatpak.

[nanonyme]

@alexlarsson what's your opinion? Should apps that are most affected by this issue just be changed to request this permission? Do all apps need it?

[daotrunghieu]

I double-check experiments on another apps, I have the outcome that adding
--talk-name=org.freedesktop.portal.Fcitx
is enough to let those apps work with fcitx:

• chat.rocket.RocketChat
• com.visualstudio.code
• com.mattermost.Desktop
• im.gitter.Gitter

and none succeeded:

• com.spotify.Client
• io.ark.Desktop

This is the output when run flatpak run --log-session-bus
logs.tar.gz

[Mikaela]

I confirmed that Riot, Telegram, Discord and Gajim also work when that is added and I sent pull requests as this issue has bothered me a lot with them especially with backticks and code blocks. Thank you everyone involved in finding what was wrong 💜

[alexlarsson]

A --talk-name=org.freedesktop.portal.Fcitx will fix this because that is a wider permission than what the default portal one is.

However, this is a security regression and should not be merged, as it just papers over the real problem which will then not be fixed, and will need every app to be modified with a hack that will be copied around forever.

[alexlarsson]

Basically, the fix is that all the broadcast messages that the fcitx daemon sends have to use a object path that starts with /org/freedesktop/portal.

[nanonyme]

Looks like there actually is a relevant upstream ticket at https://gitlab.com/fcitx/fcitx/issues/429

[teohhanhui]

Looks like kimpanel also has the same problem:

$ dbus-monitor --session

signal time=1592751473.282050 sender=:1.93 -> destination=(null destination) serial=1221311 path=/kimpanel; interface=org.kde.kimpanel.inputmethod; member=ShowAux
   boolean false
signal time=1592751473.282057 sender=:1.93 -> destination=(null destination) serial=1221312 path=/kimpanel; interface=org.kde.kimpanel.inputmethod; member=ShowPreedit
   boolean false
signal time=1592751473.282072 sender=:1.93 -> destination=(null destination) serial=1221313 path=/kimpanel; interface=org.kde.kimpanel.inputmethod; member=ShowLookupTable
   boolean false

This seems to be something that needs to be fixed on Flatpak side, instead of expecting everybody else to change their paths?

Edit: Hmm... Sorry, I actually have no idea if this is the cause.

[ccshao]

Hello, any updates on this topic? Here in xfce4, opensuse. Fcitx not working in flatpak apps like firefox, Mark Text ...
I have tried the following command suggested by above threads,

 flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx org.mozilla.firefox

However, fcitx still doesn't work in flatpak apps, only work in stock firefox.

[nanonyme]

The talk-name workaround is no longer relevant. Which version of fcitx do you have on host?

[ccshao]

Fcitx 4.2.9.6-lp152.3.12, with flatpak 1.6.3 in opensuse.

…

________________________________ From: Seppo Yli-Olli <notifications@github.com> Sent: Monday, July 6, 2020 12:35 PM To: flatpak/flatpak <flatpak@noreply.github.com> Cc: Chunxuan Shao <chunxuan@outlook.com>; Comment <comment@noreply.github.com> Subject: Re: [flatpak/flatpak] fcitx stop working at flatpak 1.0.0 (#2031) The talk-name workaround is no longer relevant. Which version of fcitx do you have on host? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fflatpak%2Fflatpak%2Fissues%2F2031%23issuecomment-654153957&data=02%7C01%7C%7C60b49b8ff6954fc9d71308d821984d98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637296285299010200&sdata=VfHBphqQDXTEBWPN6rjsP%2B0iSsryhJo96FH2VIzP9%2FI%3D&reserved=0>, or unsubscribe<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABF77F4IEIY7HQNY4VX3I5DR2GSHBANCNFSM4FR4BROA&data=02%7C01%7C%7C60b49b8ff6954fc9d71308d821984d98%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637296285299010200&sdata=23OyJCoEcxgE3NdR%2BMDIQkmLLBRrY3qwAkdJkWvRXf0%3D&reserved=0>.

[Iey4iej3]

For me: flatpak 1.6.2-1 in Debian Buster Backports, fcitx 4.2.9.6-5.

[wengxt]

to put it simple, you'll need 4.2.9.7 to make it work. Because fcitx im module in flatpak is from 4.2.97 and using a different dbus object path. It need to be the same version of fcitx on your host.

[Iey4iej3]

Is that configurable? I mean, a config file in which contains different dbus object paths for different apps needed.

[ntninja]

@ley4iej3: It is not configurable, but you could ask the Debian maintainers to add fcitx/fcitx@1f4c3a9 as a patch in Buster. See the issue tracker at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=fcitx;dist=buster

(You can report Debian bugs using reportbug fcitx on the commandline.)

[Aspire1Inspire2]

to put it simple, you'll need 4.2.9.7 to make it work. Because fcitx im module in flatpak is from 4.2.97 and using a different dbus object path. It need to be the same version of fcitx on your host.

Could you share how to diagnose the supported fcitx module version in my flatpak? Many thanks!

[nanonyme]

@Aspire1Inspire2 it should just work out of the box assuming your host has flatpak 4.2.9.7 or newer.

[wengxt]

shall we just close this?

Originally it was caused by an upstream change in flatpak that requires fcitx to make some necessary changes. Now things are all implemented and released, so I don’t think there’s anything more need to be done in fcitx/flatpak.

If you still have problem:

1. upgrade your system, or ask distro to upgrade or back port relevant code.
2. if the flatpak app you’re using is using an extremely old runtime that doesn’t have the update, then ask the app distributor to make the upgrade.
   (Some other possible workaround may includes using fcitx5 from flatpak because it’s really new.. etc)

There’s nothing else can be done or need to be done in fcitx/flatpak.

[JayXT]

Hello,

I'm using fcitx as my input method and I found an approach helps me type freely in flatpak applications has runtime: org.kde.Platform/x86_64/5.12

$ flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app-id> or $ flatpak --user override --socket=session-bus <app-id> (too much?)

In my system (flatpak-1.2.4-1.fc29), three applications were tested: com.slack.Slack; net.ankiweb.Anki; org.telegram.desktop.

What talk-name would you use for fcitx5?

[nanonyme]

@wengxt yes, this should be closed. The original problem is fixed.

[nanonyme]

@JayXT fcitx uses a portal, you must not use talk name. If it doesn't work, create new bug report after ensuring your host software is up to date.

[JayXT]

@nanonyme, thanks for the response. I'm currently facing an issue with fcitx5 mozc input in Anki flatpak, which seemed somehow related to this thread. The OS (Debian 11) is up-to-date, some recommendations like running the following command haven't resulted in any improvements.
flatpak override --user --env=IBUS_USE_PORTAL=1 net.ankiweb.Anki
I wonder whether there is any special portal that enables interaction with fcitx5.

[nanonyme]

In case it matters, net.ankiweb.Anki is using fcitx4.

[JayXT]

@nanonyme , is it something specific just to Flatpak version of Anki? Because its older version in Debian repos (2.1.15) despite other issues seems to work fine with fcitx5.

[nanonyme]

net.ankiweb.Anki is built against a runtime that provides fcitx4, not fcitx5. It should potentially be runtime bumped.

[JayXT]

Under runtime you mean the version of KDE platform in its build yaml file?

[nanonyme]

Yes, there's a newer runtime 5.15-21.08 which has fcitx5.

[RokeJulianLockhart]

Since this is closed, has it been remediated?

I ask because upstream it remains open, and on flatkill.org, it remains mentioned as open.

[wengxt]

The fcitx upstream is using github again for some time. gitlab is only left for archive purpose.

I problably should disable the issue on gitlab.

[nanonyme]

@RokeJulianLockhart flatkill.org is maintained by people who are against flatpak. I doubt it will ever be fixed to be correct.