[GH-ISSUE #1401] How to use input methods with graphical isolation? #957

Closed
opened 2026-05-05 07:13:09 -06:00 by gitea-mirror · 1 comment
Owner

Originally created by @chiraag-nataraj on GitHub (Jul 25, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1401

So this is kind of an odd problem in that it both makes sense and I cannot figure out a workaround that wouldn't violate the isolation itself.

I started using xpra to isolate my programs graphically. Pretty much everything is working except for my input method (fcitx). Try as I might, I just cannot get fcitx to work with programs that are running under an xpra server (it still works fine in an unjailed terminal emulator, for example). When I try to run fcitx-diagnose to figure out what the problem might be, it seems like I get the same messages. It fails to detect a running instance whether I enable xpra or not (which makes sense due to PID namespaces). It has access to the exact same sockets in both cases (it makes use of /tmp/fcitx-socket-:0). The only thing I'm changing is that I enable xpra.

Of course this makes sense when you consider the point of xpra itself (at least the way it's used here). But obviously it has a mechanism for selectively sharing things such as the clipboard. I already set input-method = keep in ~/.xpra/xpra.conf, so xpra shouldn't be messing with the environment variables in this case.

Does anyone have any ideas for how to selectively share access to fcitx (as with all other resources xpra lets you access)?

Originally created by @chiraag-nataraj on GitHub (Jul 25, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1401 So this is kind of an odd problem in that it both makes sense _and_ I cannot figure out a workaround that wouldn't violate the isolation itself. I started using `xpra` to isolate my programs graphically. Pretty much everything is working except for my input method (`fcitx`). Try as I might, I just cannot get `fcitx` to work with programs that are running under an xpra server (it still works fine in an unjailed terminal emulator, for example). When I try to run `fcitx-diagnose` to figure out what the problem might be, it seems like I get the same messages. It fails to detect a running instance whether I enable xpra or not (which makes sense due to PID namespaces). It has access to the exact same sockets in both cases (it makes use of `/tmp/fcitx-socket-:0`). The only thing I'm changing is that I enable xpra. Of course this makes sense when you consider the point of `xpra` itself (at least the way it's used here). But obviously it has a mechanism for selectively sharing things such as the clipboard. I already set `input-method = keep` in `~/.xpra/xpra.conf`, so `xpra` shouldn't be messing with the environment variables in this case. Does anyone have any ideas for how to selectively share access to fcitx (as with all other resources xpra lets you access)?
Author
Owner

@chiraag-nataraj commented on GitHub (Jul 25, 2017):

So I found that you can partially solve this by launching fcitx -r with the proper display. However, that only worked for my terminal emulator - firefox still refuses to use it. I don't know if that's a firefox problem or an xpra problem or some combination or whatever. Closing this for now.

<!-- gh-comment-id:317774779 --> @chiraag-nataraj commented on GitHub (Jul 25, 2017): So I found that you can _partially_ solve this by launching `fcitx -r` with the proper display. However, that only worked for my terminal emulator - firefox still refuses to use it. I don't know if that's a firefox problem or an xpra problem or some combination or whatever. Closing this for now.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#957
No description provided.