Keyboard hides when tapping backspace or auto-punctuation in Twitter tweet box

[UniversalSuperBox]

Typing a tweet in the Twitter tweet box is a slow process if you aren't perfect. Every time you press Backspace or tap Space twice to automatically insert a period, the keyboard disappears. You can reopen the keyboard by tapping in the input field again, but this causes some considerable frustration.

Steps to reproduce

1. Sign in to Twitter
2. Browse to https://mobile.twitter.com/compose/tweet
3. Type some text into the tweet box
4. Press Backspace

Expected behavior

A character is deleted and I can continue typing.

Actual behavior

The keyboard disappears and the text cursor disappears.

Additional information

If anyone can find another site that this occurs on, it would be amazing. Having to sign in to Twitter to test this is annoying at best.

The text cursor does not disappear and it is possible to continue typing if an external keyboard is used. Only the OSK has this problem.

The problem still occurs if all autocorrection and autopunctuation features are disabled.

The only hint that we have is this log which occurs when the keyboard hides: https://paste.ubuntu.com/p/KJwJXbQvyr/
However, this log also occurs when typing forward or backspacing into the QML text box at the top of the page.

I've checked Maliit logs, but they don't report much about text box changes.

[kugiigi]

This may be related to ubports/ubuntu-touch#1244 and ubports/ubuntu-touch#1125 although the former seems to be a separate issue but there are discussions related to this issue (mainly by me 😅 ).

So far, I can replicate this issue on twitter in the tweet text field and in the body field when composing an email in protonmail.
This issue also happens when pressing Enter.

From those two samples, my first guess is that it has something to do with multi-line text fields.

[dobey]

From those two samples, my first guess is that it has something to do with multi-line text fields.

However, it does not happen when typing in https://paste.ubuntu.com for example. So, stil very unclear what might be causing it.

[UniversalSuperBox]

We've found that this issue is also triggered on Etherpad instances when pressing Backspace, Enter, or triggering auto punctuation.

The issue appears to be related to this code block in QtWebEngine's RenderWidgetHostViewQt:

https://github.com/qt/qtwebengine/blob/v5.14.2/src/core/render_widget_host_view_qt.cpp#L764-L769

    const content::TextInputState *state = text_input_manager_->GetTextInputState();
    if (!state) {
        m_delegate->inputMethodStateChanged(false /*editorVisible*/, false /*passwordInput*/);
        m_delegate->setInputMethodHints(Qt::ImhNone);
        return;
    }

The call to content::TextInputManager::GetTextInputState() in text_input_manager_ returns nullptr, which means that Chromium either:

• Thinks that there is no active_view_
• Receives nullptr for the object active_view_ in the text_input_state_map_ map.

The call:

m_delegate->inputMethodStateChanged(false /*editorVisible*/, false /*passwordInput*/);

Immediately hides the keyboard at the end: https://github.com/qt/qtwebengine/blob/v5.14.2/src/webengine/render_widget_host_view_qt_delegate_quick.cpp#L211

Given this is so far inside Chromium and I can't get debug symbols in there, I'm not sure of our next steps.

[UniversalSuperBox]

Edit: The behavioral difference between the two platforms is not due to Maliit/QVK as mentioned in the rest of this comment. Plasma Mobile is using a Maliit-based keyboard now. Instead, the difference is due to Plasma Mobile using the Wayland input protocol instead of the Qt InputMethod plugin that we primarily use.

On Manjaro Plasma Mobile, the keyboard bounces a lot during backspace on the same affected websites. So it's losing keyboard focus but putting it back right away. This seems to be a behavioral difference between Plasma Mobile's QtVirtualKeyboard and our Maliit-based keyboard.

Maliit removes focus from the focused element when the keyboard is dismissed. It's done this for QML apps since it first gained support for Qt5. It appears that Maliit has removed focus from its input on dismissal since before it was open source. QtVirtualKeyboard does not do this, instead opting for leaving the cursor on the input item.

So the story goes:

1. Keyboard sends backspace
2. QtWebEngine reports that it no longer has a focused element
3. Keyboard starts dismissing
4. QtWebEngine probably realizes it has a focused element again
5. Keyboard finishes dismiss animation and forcefully removes focus from the focused element

Step 5 doesn't occur on Plasma Mobile. Instead, the keyboard appears to "bounce back" to resume input.

I don't know why Maliit's developers chose to remove focus from the focused item, but it was done a long time ago. Maybe it was so that all selection boxes and the drag cursor were dismissed. QtVirtualKeyboard just leaves them all in place, which can cause problems (the copy/paste dialog gets in the way of the text, search boxes don't get dismissed, the like).

[UniversalSuperBox]

This sure sounds like ubports/ubuntu-touch#1125. Which means that it's probably not a regression, though seeing the problem in Twitter is new. You can't trigger this problem in Twitter on OTA-15, but you can on devel. However, you can trigger the problem on Etherpad in OTA-15 and devel. So this issue will not block release...

But it looks like it will take a significant block of my time.

[UniversalSuperBox]

I've reproduced this bug under QtWebEngine 5.15.2 with the QtVirtualKeyboard 5.15.2. I've filed it upstream: https://bugreports.qt.io/browse/QTBUG-91257

[kugiigi]

Great findings!
Just one comment though, as far as I know, Plasma Mobile also uses maliit.

[UniversalSuperBox]

Plasma Mobile also uses maliit.

Thanks, Bhushan notified me of that as well. I've already added a note to that comment.

[UniversalSuperBox]

Fixed by https://gitlab.com/ubports/core/packaging/qtwebengine/-/merge_requests/4; review in progress

[UniversalSuperBox]

https://gitlab.com/ubports/core/packaging/qtwebengine/-/merge_requests/4 has been merged, this issue is resolved in devel.

[Keneda-ut]

Hi, i get an issue with selection field on keyboard in morph, i'll give you a link to where i posted first before @kugiigi pointed me here as some discussions was made there already ubports/keyboard-component#159 (comment)

[Fuseteam]

the tldr; is that when a time field is selected switching between hours and minutes(via selection mode) dismisses the osk. this was not the case on ota 16

[UniversalSuperBox]

Right, so the French government has done something that you should never do, ever. Take note, webdevs. Don't be clever with HTML forms.

Anyway...

It appears that the Ubuntu Touch keyboard does not handle date or time fields. This makes sense considering we haven't programmed anything to do that. Android and iOS each have unique date and time pickers. We don't.

However, date and time fields in QtWebEngine have a default behavior: adding an up and down button to the side. This is not an ideal way to work with them on mobile, but it is a way.

The following image shows my favorite input types test page, https://www.456bereastreet.com/lab/html5-input-types/. I've put my focus on the Time field. Notice the up and down buttons appear, but the keyboard does not. This is the same on qtwebengine 5.14.2-ubports3 (included in OTA-16) and 5.14.2-ubports4 (OTA-17).

You can absolutely operate these fields with the up and down arrows. It's not ideal at all, but it operates. Additionally, by design, the keyboard should not appear in these fields. There is supposedly nothing that you could enter with a keyboard... And indeed, you weren't using the keyboard to enter data but just to press Up and Down.

Now, on -ubports3, it is possible to take advantage of an apparent bug to keep the keyboard visible when moving from another field to the time field. This allows you to use the keyboard's selection mode (which just virtually presses the arrow keys when you swipe your finger) to operate the text field as if you were pressing the visual up and down buttons.

The French government has chosen to do an extremely bad thing: they turned off the up and down buttons. They did this by setting appearance: none in the time input box CSS. If you're in a position to make changes to input boxes, please don't do this. For accessibility's sake, never do this.

In theory, this should have shut off input handling on Android and iOS, too. Maybe those operating systems decided that web developers can't be trusted with appearance: none when it comes to accessibility.

Which comes to "what should we do? Should we stop the OTA-17 release?"

I think the answer is "no." This never actually worked: you were using a small detail of how the Ubuntu Touch keyboard works to carefully get around the website's poor programming. I've filed #487 for the complaint of Morph handling datetime inputs incorrectly.

And to solve the immediate problem, you can still bring up the keyboard inside these fields. It's just more difficult. Place your text cursor in a field which opens the keyboard. Then, tap on the date or time text field. The keyboard will dismiss. After it finishes dismissing and the input field appears unfocused, tap it again. The keyboard reappears.

[Keneda-ut]

"Which comes to "what should we do? Should we stop the OTA-17 release?""

Have i asked for something like that ?

I just pointed a different behavior between ota16 and ota17 with morph/keyboard in a time field that is : before you could swap hours/minutes by swiping, now you can't and it closes keyboard if you don't swipe very linear (< that is "the immediate problem") or try to swap.

Additionally, on Firefox, you can enter directly time with numkeys, that you can't do on morph.
https://forums.ubports.com/topic/6055/ota-17-call-for-testing-companion-post/12?_=1620508443204

Anyway, thanks for filing an issue.

[Fuseteam]

so basically virtually pressing the left and right arrow keys in the time field dismisses the keyboard now, which wasn't the case with ota 16

"Which comes to "what should we do? Should we stop the OTA-17 release?"
i'm guessing dalton said that because we are now currently in a freeze, as in new things won't get merged in unless we stop the release merge a fix and retest if nothing breaks

of course we can also wait for ota 17 to release tommorow and then debug and fix this regression or even fix the core of the issue

[Keneda-ut]

so basically virtually pressing the left and right arrow keys in the time field dismisses the keyboard now, which wasn't the case with ota 16

Yes it's the issue.

"Which comes to "what should we do? Should we stop the OTA-17 release?"
i'm guessing dalton said that because we are now currently in a freeze, as in new things won't get merged in unless we stop the release merge a fix and retest if nothing breaks

I just followed the "Call for testing" thread on forum, and reported an issue i found, i don't want to postpone anything ^^

of course we can also wait for ota 17 to release tommorow and then debug and fix this regression or even fix the core of the issue

If it's the best way, and i believe it is, then let's do that.
I'm a simple user, and can't do anything else than use (daily), report (sometime), and thanks (a lot) ^^