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

Closed
nakamuray opened this issue Aug 28, 2018 · 56 comments
Closed

fcitx stop working at flatpak 1.0.0 #2031

nakamuray opened this issue Aug 28, 2018 · 56 comments
Labels

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
Contributor

@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
Contributor

@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
Contributor

@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
Contributor

@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
Contributor

@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 pushed 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
Contributor

@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
@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.

@ccshao
Copy link

@ccshao ccshao commented Jul 6, 2020

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

@nanonyme nanonyme commented Jul 6, 2020

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

@ccshao
Copy link

@ccshao ccshao commented Jul 7, 2020

@Iey4iej3
Copy link

@Iey4iej3 Iey4iej3 commented Jul 7, 2020

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

@wengxt
Copy link

@wengxt wengxt commented Jul 7, 2020

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

@Iey4iej3 Iey4iej3 commented Jul 8, 2020

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

@ntninja
Copy link

@ntninja ntninja commented Aug 31, 2020

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

@Aspire1Inspire2 Aspire1Inspire2 commented Mar 16, 2021

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

@nanonyme nanonyme commented Mar 16, 2021

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

@wengxt
Copy link

@wengxt wengxt commented Mar 21, 2021

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

@JayXT JayXT commented Jan 7, 2022

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

@nanonyme nanonyme commented Jan 7, 2022

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

@nanonyme
Copy link
Contributor

@nanonyme nanonyme commented Jan 7, 2022

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

@JayXT JayXT commented Jan 7, 2022

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

@nanonyme nanonyme commented Jan 7, 2022

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

@JayXT
Copy link

@JayXT JayXT commented Jan 7, 2022

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

@nanonyme nanonyme commented Jan 7, 2022

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

@JayXT
Copy link

@JayXT JayXT commented Jan 7, 2022

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

@nanonyme
Copy link
Contributor

@nanonyme nanonyme commented Jan 7, 2022

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

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

No branches or pull requests