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

[Sebastien Bacher]

Steps to reproduce:

 1) on a touch device, browse to http://mikeasoft.com/~mike/oxide-clear.html
 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")

[Olivier Tilloy (osomon)]

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

[Olivier Tilloy (osomon)]

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.

[Olivier Tilloy (osomon)]

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

Tested again google.com, 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

[Sebastien Bacher (seb128)]

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

[Olivier Tilloy (osomon)]

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.

[Sebastien Bacher (seb128)]

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

[Olivier Tilloy (osomon)]

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).

[Bill Filler (bfiller)]

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)]

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.

[Michael Sheldon (michael-sheldon)]

This can be reproduced using the small test page here: http://mikeasoft.com/~mike/oxide-clear.html

[Andrea Bernabei (faenil)]

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 :)
https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1480847

[Olivier Tilloy (osomon)]

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)]

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

[Olivier Tilloy (osomon)]

didUpdateTextOfFocusedElementByNonUserInput was removed from WebViewClient by https://chromium.googlesource.com/chromium/src/+/1c4ff63fc531d7bbb626329b8e7648ecc4b94b22.