Current composition is not canceled when a text input field is cleared programmatically

Bug #1384357 reported by Sebastien Bacher on 2014-10-22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
webbrowser-app (Ubuntu)

Bug Description

Steps to reproduce:

 1) on a touch device, browse to
 2) focus the text field and type any word in it (e.g. "Ubuntu")
 3) tap the "X" below the text field, this clears it
 4) press backspace on the OSK

Expected result: nothing happens

Current result: the previous preedit is restored and backspace deletes the last letter (in that example, the text field now contains "Ubunt")

Related branches

Olivier Tilloy (osomon) wrote :

The issue is most likely in the oxide/OSK interaction code.

Changed in webbrowser-app:
status: New → Invalid
Changed in webbrowser-app (Ubuntu):
status: New → Invalid
Olivier Tilloy (osomon) wrote :

Testing on RTM image #150, and the first issue seems to be gone (tapping the "X" symbol clears the field, and the text is not restored).

The second issue (hitting backspace after clearing the field restores the previous uncommitted word) is still present though.

I’ll update the bug title to reflect that.

summary: - Clearing text entry doesn't work (the text is restored directly)
+ [browser] Clearing text entry with backspace restores the previously
+ uncommitted word

Further update: I can’t reproduce the issue with "normal" text fields (tested and, the issue isn’t present).

Tested again, and I can’t reproduce the issue by only clearing the field with backspace. For the bug to be observed, I first have to clear the current uncommitted word with the "X" icon, then type something else, then erase it with backspace, then hit backspace again in the empty field, and the first word (that was cleared by "X") is restored.

It seems there are two issues there, and my guess is that both are in oxide:
 - when the field is cleared with the "X" icon, we don’t cancel the current composition
 - when pressing backspace in an empty text field, the event should be ignored

summary: - [browser] Clearing text entry with backspace restores the previously
- uncommitted word
+ Current composition is not canceled when a text input field is cleared
+ programmatically
Changed in ubuntu-keyboard:
status: New → Invalid
Changed in oxide:
status: New → Confirmed
importance: Undecided → Medium
Sebastien Bacher (seb128) wrote :

the "text is restored after clicking X" is still there on rtm 150/krillin, reopening

Changed in webbrowser-app:
status: Invalid → New
Olivier Tilloy (osomon) wrote :

I can’t observe the bug with the steps described in the original description, however I can see the text being restored when swiping from the right to show the app previews. In any case that’s most likely a bug in oxide, not in webbrowser-app.

Changed in webbrowser-app:
status: New → Invalid
Sebastien Bacher (seb128) wrote :

The bug still happens as described here, not sure what's the difference between our devices, could be an osk configuration...

Olivier Tilloy (osomon) on 2014-11-24
tags: added: osk
Olivier Tilloy (osomon) wrote :

It looks like the blink method we’re interested in listening to is called didUpdateTextOfFocusedElementByNonUserInput().

Apparently this will require patching content::RenderWidget, the current implementation does nothing if !defined(OS_ANDROID).

Olivier Tilloy (osomon) on 2015-03-23
Changed in oxide:
assignee: nobody → Olivier Tilloy (osomon)
Olivier Tilloy (osomon) on 2015-03-30
Changed in oxide:
status: Confirmed → In Progress
Bill Filler (bfiller) wrote :

Is this still an issue? I'm trying the steps in the comments above but cannot reproduce on vivid or rtm.

If still an issue, please list the steps to reproduce.

Olivier Tilloy (osomon) wrote :

Google have recently updated their search page: tapping on the cross to clear the search field used to leave it focused, but it doesn’t any longer, so the OSK is dismissed (which seems like a regression to me, but nothing we can do about I’m afraid).

So the original steps to reproduce the bug don’t apply anymore.

This can be reproduced using the small test page here:

Olivier Tilloy (osomon) on 2015-04-09
description: updated
Olivier Tilloy (osomon) on 2015-07-28
tags: added: keyboard
Andrea Bernabei (faenil) wrote :

Another way to reproduce this is by using Telegram's mobile website (which I currently use for the messages whose type is unsupported by the current Ubuntu Telegram app).

It makes the messaging experience reeeally annoying :)

Olivier Tilloy (osomon) wrote :

The issue still exists in the latest rc-proposed image (#314 on krillin). Word suggestion needs to be enabled in system settings.

Olivier Tilloy (osomon) wrote :

The issue still exists and can also be observed on desktop with ubuntu-keyboard.

Olivier Tilloy (osomon) wrote :

didUpdateTextOfFocusedElementByNonUserInput was removed from WebViewClient by

Olivier Tilloy (osomon) on 2018-11-19
Changed in oxide:
status: In Progress → Confirmed
assignee: Olivier Tilloy (osomon) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers