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.