Fix repeated key input issue in Chrome with multiple windows #1642
Conversation
hayandev
force-pushed
the
fix-double-input-chrome
branch
from
19b4506 to
a14b5d7
Compare
hayandev
force-pushed
the
fix-double-input-chrome
branch
from
a14b5d7 to
ef0d0e8
Compare
|
thanks! |
|
After this commit fcitx text_input is straight doesn't work at all, juts gets instantly disabled and that's about it, to repro just run |
| fn set_enabled_resource_id(&self, resource_id: Option<ObjectId>) { | ||
| let mut inner = self.inner.lock().unwrap(); | ||
| if inner.enabled_resource_id.is_some() != resource_id.is_some() { | ||
| inner.enabled_resource_id = resource_id; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
It works the other way around, the IME should state that it's ready meaning that it'll send the Entered to the client and it'll react with enabled and only one of them must be honored IIRC, however with this check it won't ever advertise since it won't be enabled until you actually call enabled, which means with this PR it won't ever happen, thus it will never work at all, thus not sure how it could ever worked, until the client just enables it because it can.
There was a problem hiding this comment.
I'm sorry, you are right. I was focused on the behavior of enable and the input bug related to Chrome. I tested it extensively with Chrome and once with Qt and Gtk apps, and it worked well, so I thought it was working correctly (as shown in the attached image).
I just tested it several times with Gtk apps, and while it works in some cases, it fails more often, and as you mentioned, it's unclear why it works at all.
I would appreciate it if you could revert the commit. I apologize again for not testing more thoroughly.
There was a problem hiding this comment.
I'll fix myself, don't worry.
There was a problem hiding this comment.
Qt doesn't support text-input v3, so it worked just via dbus, I guess, and maybe some gtk apps worked that way as well, on a pure text-input-v3 system it couldn't possible work, just for the reference.
This PR fixes issue #1604
According to the text input v3 specification, the enable request should activate at most one text input on the compositor and ignore any subsequent enable requests until a disable request is received.
However, currently, Smithay does not guarantee this behavior and sends events to all text input objects created by the same client.
We will modify it to send events only to the text input object that has received the enable request and update the management of the enabled text input objects.