Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fcitx stop working at flatpak 1.0.0 #2031

Open
nakamuray opened this issue Aug 28, 2018 · 37 comments
Open

fcitx stop working at flatpak 1.0.0 #2031

nakamuray opened this issue Aug 28, 2018 · 37 comments
Labels
bug

Comments

@nakamuray
Copy link

@nakamuray nakamuray commented Aug 28, 2018

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
Copy link
Member

@alexlarsson alexlarsson commented Aug 28, 2018

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
Copy link
Author

@nakamuray nakamuray commented Aug 29, 2018

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
Copy link
Member

@alexlarsson alexlarsson commented Aug 29, 2018

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
Copy link

@trulyliu trulyliu commented Oct 9, 2018

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

@nanonyme
Copy link

@nanonyme nanonyme commented Apr 6, 2019

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

@nanonyme
Copy link

@nanonyme nanonyme commented Apr 6, 2019

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

@Areiser
Copy link

@Areiser Areiser commented Apr 9, 2019

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

@alexlarsson
Copy link
Member

@alexlarsson alexlarsson commented Apr 12, 2019

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
Copy link
Member

@alexlarsson alexlarsson commented Apr 12, 2019

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
Copy link

@nanonyme nanonyme commented Apr 12, 2019

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

@daotrunghieu
Copy link

@daotrunghieu daotrunghieu commented Apr 15, 2019

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
Copy link

@nanonyme nanonyme commented Apr 16, 2019

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

@magiruuvelvet
Copy link

@magiruuvelvet magiruuvelvet commented Apr 16, 2019

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
Copy link

@nanonyme nanonyme commented Apr 16, 2019

@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
Copy link

@daotrunghieu daotrunghieu commented Apr 17, 2019

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 added a commit to Mikaela/im.riot.Riot that referenced this issue Apr 18, 2019
This is required for Fcitx users for characters such as backtick.

Ref: flatpak/flatpak#2031
Mikaela added a commit to Mikaela/org.gajim.Gajim that referenced this issue Apr 18, 2019
This is required for Fcitx users for characters such as backtick.

Ref: flatpak/flatpak#2031
Mikaela added a commit to Mikaela/com.discordapp.Discord that referenced this issue Apr 18, 2019
This is required for Fcitx users for characters such as backtick.

Ref: flatpak/flatpak#2031
@Mikaela
Copy link

@Mikaela Mikaela commented Apr 18, 2019

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 💜

TingPing added a commit to flathub/com.discordapp.Discord that referenced this issue Apr 18, 2019
This is required for Fcitx users for characters such as backtick.

Ref: flatpak/flatpak#2031
@alexlarsson
Copy link
Member

@alexlarsson alexlarsson commented Apr 23, 2019

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
Copy link
Member

@alexlarsson alexlarsson commented Apr 23, 2019

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
Copy link

@nanonyme nanonyme commented Apr 23, 2019

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

Mikaela added a commit to Mikaela/im.riot.Riot that referenced this issue Apr 29, 2019
This is required for Fcitx users for characters such as backtick.

Ref: flatpak/flatpak#2031
lovetox added a commit to gajim/gajim that referenced this issue Jul 6, 2019
@trulyliu
Copy link

@trulyliu trulyliu commented Oct 21, 2019

flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx com.skype.Client
make skype works.

@BjoernDaase
Copy link

@BjoernDaase BjoernDaase commented Nov 1, 2019

I have the exact same problem in all my Jetbrains IDEs. Unfortunately, flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx com.jetbrains.Webstorm (or any other application of those) does not make the dead keys work again. Any ideas?

OS: Fedora 31

@nanonyme
Copy link

@nanonyme nanonyme commented Nov 2, 2019

This is a bug in fcitx. They seem to have removed means to contribute fixes to the project though so I'm not sure this will ever be fixed. They also removed issue tracker on fcitx. I'm not sure the project is alive anymore.

@wengxt
Copy link

@wengxt wengxt commented Nov 3, 2019

Just pushed relevant fix, need to check if that's the only change need to make fcitx/fcitx@1f4c3a9

@nanonyme
Copy link

@nanonyme nanonyme commented Nov 3, 2019

@wengxt note, regarding compatibility: the server part is shipped by distro while the library is shipped through Flatpak runtime. It's most likely not possible to be compatible but current situation is broken anyway pretty much everywhere.

@nanonyme
Copy link

@nanonyme nanonyme commented Nov 3, 2019

Thank you and sorry for above. I jumped to conclusions from repo configuration

@nanonyme
Copy link

@nanonyme nanonyme commented Nov 10, 2019

The fix by @wengxt is now integrated into all active freedesktop-sdk branches. It will be released Soon (tm) for 18.08 and 19.08.

@nanonyme
Copy link

@nanonyme nanonyme commented Nov 10, 2019

Note we realized that Gnome runtime is shipping a separate fcitx version so assuming all goes well with the freedesktop-sdk release, attention needs to next be focused into https://gitlab.gnome.org/GNOME/gnome-build-meta/issues. KDE should end up getting fixed by itself after a rebuild.

@refi64
Copy link
Contributor

@refi64 refi64 commented Jan 30, 2020

To be clear, what else here needs to be done? Is it just pending a new fcitx server release with the linked commit?

@Quintasan
Copy link

@Quintasan Quintasan commented Feb 6, 2020

I am not sure if this is related but I can't even activate fcitx in Slack using the default Ctrl+Space combo.

I have run flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx com.slack.Slack

which then I verified by running

~ ➜ flatpak --user override --show com.slack.Slack
[Session Bus Policy]
org.freedesktop.portal.Fcitx=talk
org.fcitx.Fcitx=talk

so my flatpak should have the appropriate permissions to talk to Fcitx. Fcitx itself works just fine on the host itself. Is there anything I missed?

@Mikaela
Copy link

@Mikaela Mikaela commented Feb 7, 2020

Have you restarted Slack after adding the override? That is the only step you don't mention that I can see you as missing.

@Quintasan
Copy link

@Quintasan Quintasan commented Feb 8, 2020

@yutouyes
Copy link

@yutouyes yutouyes commented Apr 15, 2020

The trick flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app id> doesn't work in Crostini(Chrome OS). Tested in Firefox and vscode.

@luni3359
Copy link

@luni3359 luni3359 commented Apr 15, 2020

The trick flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app id> doesn't work in Crostini(Chrome OS). Tested in Firefox and vscode.

Your fcitx needs to be on version 4.2.9.7 to work with flatpak.

@yutouyes
Copy link

@yutouyes yutouyes commented Apr 16, 2020

The trick flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app id> doesn't work in Crostini(Chrome OS). Tested in Firefox and vscode.

Your fcitx needs to be on version 4.2.9.7 to work with flatpak.

I've upgraded fcitx to 4.2.9.7-3 but still broke. Is everything ok in your crostini?

@wengxt
Copy link

@wengxt wengxt commented Apr 16, 2020

The trick flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app id> doesn't work in Crostini(Chrome OS). Tested in Firefox and vscode.

Your fcitx needs to be on version 4.2.9.7 to work with flatpak.

I've upgraded fcitx to 4.2.9.7-3 but still broke. Is everything ok in your crostini?

I just tried firefox from flathub on archlinux and everything works fine. So probably you just had a regular fcitx configuration problem? BTW, no "talk-name" argument is required anymore.

Try set GTK_IM_MODULE before run flatpak, also see https://fcitx-im.org/wiki/Configure_(Other)

@yutouyes
Copy link

@yutouyes yutouyes commented Apr 17, 2020

The trick flatpak --user override --talk-name=org.fcitx.Fcitx --talk-name=org.freedesktop.portal.Fcitx <app id> doesn't work in Crostini(Chrome OS). Tested in Firefox and vscode.

Your fcitx needs to be on version 4.2.9.7 to work with flatpak.

I've upgraded fcitx to 4.2.9.7-3 but still broke. Is everything ok in your crostini?

I just tried firefox from flathub on archlinux and everything works fine. So probably you just had a regular fcitx configuration problem? BTW, no "talk-name" argument is required anymore.

Try set GTK_IM_MODULE before run flatpak, also see https://fcitx-im.org/wiki/Configure_(Other)

I've set that and fIrefox from apt-get can catch fcitx correctly. I'm not sure if it's the problem of crostini or just my mistake because before flatpak, snap also came to an error cannot update snap namespace: cannot create writable mimic over "/usr/share/" which is not reported in the community. Your archlinux is running in crostini right?

@teohhanhui
Copy link

@teohhanhui teohhanhui commented Jun 21, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.