1863611 - Cannot erase properly characters when using OSK with Gnome 45 in Fedora

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Aurel]

Attachment: Capture vidéo du 2023-11-07 21-30-50.webm

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Firefox for Android

Steps to reproduce:

Hello,

I have a Lenovo ThinkPad X12 Detachable Gen 1 under Fedora 39 with Firefox 119 installed by rpm.
When using the touchpad with the keyboard detached, if I want to erase some text through the OSK with the cursor moved at the end of the sentence, instead of erasing the last character, the cursor is first moved to the left selecting the last character. It is only when touching a second time the erase button that the following character is erased.
I joined a video illustrating the issue.

Actual results:

The first character to erase is instead selected and the cursor moved to the left. Only the next character is erased.

Expected results:

The first character should be erased with no character selection.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[luk]

this has already been reported to gnome team
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6340
was determined to be firefox side issue (likely gtk3 related)
also is the case on

arm64 devices
debian both sid firefox and firefox-esr

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Can you test any other gtk3 application like libre office or gimp?
Thanks.

Comment 4

[luk]

i was unable to upload any video here so i uploaded it to youtube
here is try it on libreoffice with libreoffice-gtk3
https://youtu.be/ZCZT7E_I82E
and here is firefox from debian sid repo
https://youtu.be/0JRj73-h3J4

what is interested is the fact that as you can see ^ the issue doesn't affect the url text input

but is the case for any website content, it either doesn't let you to backspace at all or acts in a weird way described above
it is also the case on firefox-esr and also other touch screen devices i have, it can also be reproduced on non touch screen devices too if you use gnome osk with mouse

it might also be worth noting that i use wayland but haven't check the x11 side yet

Comment 5

[Fearless Spiff]

Just a me too: I now did some testing on latest arch here and I have the same problems as @luk is describing.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

It's interesting that if OSK is enabled after Firefox start, erase works fine but typed letter are underlined. But if OSK is enabled before Firefox start, erase is broken but typed letters are without underline.

Comment 7

[luk]

osk is also always enabled on touch screen devices without a keyboard (or detached one)
making browser somewhat unusable

also if you detach keyboard and osk gets enabled automatically (not via accesiblity tab) while firefox is running or not the bug still occures either way

Comment 8

[luk]

can we get this bug as confirmed?

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

This doesn't look related to Wayland at all (although it uses Wayland IM). We correctly select a text for removal but we failed to perform the 'cmd_delete' command as IsCommandEnabled() returns false for it. IsCommandEnabled() returns true/false so only every second selection is removed.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

I'm not sure why IsCommandEnabled() returns false and/or how to debug it? Is that related to actual selection content or so?
https://searchfox.org/mozilla-central/rev/26a98a7ba56f315df146512c43449412f0592942/dom/events/EventStateManager.cpp#6750
I can't step in in gdb. Also if I force it to true the delete works.
Thanks.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Yeah, IsCommandEnabled just tells you whether the selection is editable for Delete here

Masayuki, can you take a look? You're more familiar than me with the relevant code.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

CopyOrDeleteCommand::IsCommandEnabled() doesn't look directly related here - if I put logging it returns true but subsequent call of IsCommandEnabled() is false.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

DeleteCommand::IsCommandEnabled() may be a good candidate here.

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that this is related to bug 1905481. IMContextWrapper::DeleteText extends Selection first, then, send a delete command. If the focused element in a remote process, EventStateManager just send the Selection, then, the delete command comes EventStateManager before the remote process updates command state in the main process. I think that we should send the content command events as same as other composition events including setting selection event. Then, EventStateManager in the remote process can check the latest selection range in the focused editor.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

Okay, Thanks!

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1863611 Make `EventStateManager` send content command events to focused remote process r=smaug!,#dom-core

Currently, EventStateManager handles some content commands only in the parent
process. Therefore, if eSetSelection event or something is being handled in
the focused remote process, the command may be disabled yet.

Avoiding the race conditions, we should handle the content command events in the
focused process.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1590ecab1ea1
Make `EventStateManager` send content command events to focused remote process r=smaug

Comment 20

[Cristian Tuns]

Backed out for causing bc failures in browser_test_contentCommand_immediately_after_setSelection.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | widget/tests/browser/browser_test_contentCommand_immediately_after_setSelection.js | cut immediately after setting selection should affect to the focused <textarea> in the remote process - "abc" == "ac" -

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh? I'll take a look.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, looks like only cut command case is unstable especially in opt builds. I'll reland it without the cut case.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, it may fail at delete too. It seems that the remote process may not be ready at first test when it fails.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't know how to implement SpeicalPowers.spawn, later use of it may be handled before the sent content command event whose priority should be "input".

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e91c8c76fc96
Make `EventStateManager` send content command events to focused remote process r=smaug

Comment 26

[Fearless Spiff]

Maybe FYI: When using https://github.com/Vishram1123/gjs-osk in Gnome 46 then the problem is solved! So might still be a Gnome issue? Unfortunately it is not yet compatible with 47.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yeah, it's a regression of our e10s support from technical point of view (In the wild, a new OSK app hits this bug though). Actually, the adding test case can reproduce this bug in all platforms. Anyway, the change is required for some keyboard layouts/IME on Linux like bug 1905481.

Comment 28

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/e91c8c76fc96