-
-
Notifications
You must be signed in to change notification settings - Fork 399
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
Comments
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. |
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. |
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. |
I am also affected by this issue. |
@alexlarsson if we need changes in freedesktop-sdk, we should probably have a copy of this on that side, right? |
Opened https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/728 so this gets tracked on runtime-side as well. |
I'm glad this is receiving attention. I still can't use Anki because I can't input vocabulary. |
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 |
If you want to see what fcitx does, run |
Maybe whoever can reproduce this should just collect the output and attach here for further analysis? |
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
In my system (flatpak-1.2.4-1.fc29), three applications were tested: com.slack.Slack; net.ankiweb.Anki; org.telegram.desktop. |
The latter is definitely too much, it's a blanket permission for granting access to everything in session bus. |
I just tested I'm on Arch Linux running the latest flatpak. |
@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? |
I double-check experiments on another apps, I have the outcome that adding
and none succeeded:
This is the output when run |
This is required for Fcitx users for characters such as backtick. Ref: flatpak/flatpak#2031
This is required for Fcitx users for characters such as backtick. Ref: flatpak/flatpak#2031
This is required for Fcitx users for characters such as backtick. Ref: flatpak/flatpak#2031
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 |
This is required for Fcitx users for characters such as backtick. Ref: flatpak/flatpak#2031
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. |
Basically, the fix is that all the broadcast messages that the fcitx daemon sends have to use a object path that starts with |
Looks like there actually is a relevant upstream ticket at https://gitlab.com/fcitx/fcitx/issues/429 |
This is required for Fcitx users for characters such as backtick. Ref: flatpak/flatpak#2031
Looks like kimpanel also has the same problem:
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. |
Hello, any updates on this topic? Here in xfce4, opensuse. Fcitx not working in flatpak apps like firefox, Mark Text ...
However, fcitx still doesn't work in flatpak apps, only work in stock firefox. |
The talk-name workaround is no longer relevant. Which version of fcitx do you have on host? |
For me: flatpak 1.6.2-1 in Debian Buster Backports, fcitx 4.2.9.6-5. |
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. |
Is that configurable? I mean, a config file in which contains different dbus object paths for different apps needed. |
@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: (You can report Debian bugs using |
Could you share how to diagnose the supported fcitx module version in my flatpak? Many thanks! |
@Aspire1Inspire2 it should just work out of the box assuming your host has flatpak 4.2.9.7 or newer. |
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:
There’s nothing else can be done or need to be done in fcitx/flatpak. |
What talk-name would you use for fcitx5? |
@wengxt yes, this should be closed. The original problem is fixed. |
@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. |
@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. |
In case it matters, net.ankiweb.Anki is using fcitx4. |
@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. |
net.ankiweb.Anki is built against a runtime that provides fcitx4, not fcitx5. It should potentially be runtime bumped. |
Yes, there's a newer runtime 5.15-21.08 which has fcitx5. |
Since this is closed, has it been remediated? I ask because upstream it remains open, and on flatkill.org, it remains mentioned as open. |
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. |
@RokeJulianLockhart flatkill.org is maintained by people who are against flatpak. I doubt it will ever be fixed to be correct. |
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
The text was updated successfully, but these errors were encountered: