Open Bug 1832876 Opened 1 year ago Updated 2 months ago

[Wayland] zwp_text_input_v3::delete_surrounding_text() does not delete expected text

Categories

(Core :: Widget: Gtk, defect)

Firefox 113
defect

Tracking

()

UNCONFIRMED

People

(Reporter: sebastian-keller, Unassigned)

References

(Blocks 1 open bug)

Details

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

Steps to reproduce:

Use a Wayland compositor that implements the zwp_text_input_v3 protocol and uses delete_surrounding_text() to delete text. For example this could be gnome-shell >= 43 using the OSK backspace key. (On non-touch systems the OSK can be enabled in the accessibility settings under "typing").

Open a website with a text input with the text "test" and make sure it is focused with the text cursor is all the way to the right. Then press the backspace key on the OSK a couple of times.

Actual results:

From running Firefox with WAYLAND_DEBUG=1:

When selecting the input Firefox sends:
set_surrounding_text("test", 4, 4)
This means the current text is "test" and the cursor is placed at the end with no selection. So far this correct.

When pressing backspace on the OSK, gnome-shell sends:
delete_surrounding_text(1, 0)
This means that 1 character before the cursor should be deleted.

After this Firefox sends:
set_surrounding_text("test", 4, 4)
In the browser it leaves the text as "test", but selects the last "t". It did not delete the character and the selection is not reflected in the message either.

Pressing backspace again gnome-shell sends:
delete_surrounding_text(1, 0)

After this Firefox sends:
set_surrounding_text("test", 3, 3)
This means that the text is still "test" with the cursor placed between "s" and "t" and there being no selection, but in the browser the text has been changed to "tet" (with nothing selected).

Expected results:

After the first delete_surrounding_text(1, 0), Firefox should have changed the text to "tes" and responded with a set_surrounding_text("tes", 3, 3) and at no point any text should have been selected.

Additional information:
Something that might be relevant to this is that gtk3 does not support specifying a anchor due to API constraints, so the anchor position will always be set to the the cursor position, meaning selections are not properly reflected in zwp_text_input_v3.

Also currently gnome-shell does not consider the currently selected text and always sends delete_surrounding_text(1, 0) when pressing backspace. This should not be relevant here though, because this should not cause any selections and even the selections visible in the browser due to the bug are not reflected in the protocol, because cursor == anchor. But it might be something you encounter when trying to debug this.

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.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

I think that may come from Gtk3 code. I don't think Firefox uses zwp_text_input_v3 directly.

It works in regular gtk3 programs, at least for deleting single characters. I think it is more related to the way Firefox uses the gtk3 API for selections and deletions in IMContextWrapper.cpp, perhaps in combination with some of the limitations of gtk3 I mentioned.

You need to log in before you can comment on or make changes to this bug.