Bug 88662 - [Qt][WK2] Only show virtual keyboard as a result of user interaction.
Summary: [Qt][WK2] Only show virtual keyboard as a result of user interaction.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Michael Brüning
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-08 09:05 PDT by Yael
Modified: 2014-02-03 03:21 PST (History)
10 users (show)

See Also:


Attachments
Patch (1.35 KB, patch)
2012-06-08 09:14 PDT, Yael
no flags Details | Formatted Diff | Diff
Patch (3.90 KB, patch)
2012-08-20 05:30 PDT, Michael Brüning
no flags Details | Formatted Diff | Diff
Patch (3.93 KB, patch)
2012-08-20 08:35 PDT, Michael Brüning
no flags Details | Formatted Diff | Diff
Patch (3.94 KB, patch)
2012-08-20 08:45 PDT, Michael Brüning
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yael 2012-06-08 09:05:09 PDT
The ASSERT in QtViewportHandler::focusEditableArea is wrong.
An editable element can be focused when JavaScript focuses it.
I hit this ASSERT when loading e.g. www.google.com in MiniBrowser.

It was added in r118493.
Comment 1 Yael 2012-06-08 09:14:43 PDT
Created attachment 146583 [details]
Patch

Remove the ASSERT.
Input elements can become focused via JavaScript, and not only from user interaction.
Comment 2 Kenneth Rohde Christiansen 2012-06-08 09:25:38 PDT
Comment on attachment 146583 [details]
Patch

Just like on iOS and N9 etc we only want to allow bringing up the vkb and zooming in when the element got focused as a result of user interaction. There is code to make sure of that and that is the reason for this assert. If that doesn't work correctly it should be fixed. Also, it would be good with qml tests for this.
Comment 3 Yael 2012-06-08 09:31:03 PDT
(In reply to comment #2)
> (From update of attachment 146583 [details])
> Just like on iOS and N9 etc we only want to allow bringing up the vkb and zooming in when the element got focused as a result of user interaction. There is code to make sure of that and that is the reason for this assert. If that doesn't work correctly it should be fixed. Also, it would be good with qml tests for this.

Where is the code that prevents bringing VKB?
It seems to me very backwards to add ASSERTS without making sure that the code works.
Comment 4 Chang Shu 2012-06-08 09:43:07 PDT
Would "if (!m_hadUserInteraction) return;" help? :)
Comment 5 Kenneth Rohde Christiansen 2012-06-11 03:37:57 PDT
Zalan can you look into this?
Comment 6 zalan 2012-06-12 09:11:36 PDT
Some code got moved around recently and now JS could bring up vkb indeed. Previously QtWebPageEventHandler::doneWithGestureEvent() triggered setInputPanelVisible(), now it is in this more generic updateTextInputState() method, which gets called by WebCore when EditorStateChange. 
see the change here: https://bugs.webkit.org/attachment.cgi?id=140006&action=diff

The code was probably mistakenly moved. I'll ask Michael tomorrow and make a patch based on that.
Comment 7 Kenneth Rohde Christiansen 2012-06-13 01:04:46 PDT
Would be great with a qml test as well!
Comment 8 Michael Brüning 2012-08-20 05:30:24 PDT
Created attachment 159400 [details]
Patch
Comment 9 Kenneth Rohde Christiansen 2012-08-20 07:28:58 PDT
Comment on attachment 159400 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=159400&action=review

> Source/WebKit2/ChangeLog:10
> +        [Qt][WK2] Remove wrong ASSERT
> +        https://bugs.webkit.org/show_bug.cgi?id=88662
> +
> +        Reviewed by NOBODY (OOPS!).
> +
> +        Rolled back a change to QtWebPageEventHandler::doneGestureEvent and implemented the correct behaviour.
> +        Also added a QML test to test whether the virtual keyboard is visible.
> +

I think that bug needs to be renamed or you need to create another one
Comment 10 Michael Brüning 2012-08-20 08:35:32 PDT
Created attachment 159435 [details]
Patch
Comment 11 Michael Brüning 2012-08-20 08:36:16 PDT
Update ChangeLog to new title.
Comment 12 Kenneth Rohde Christiansen 2012-08-20 08:44:45 PDT
Comment on attachment 159435 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=159435&action=review

> Source/WebKit2/UIProcess/API/qt/tests/qmltests/WebView/tst_noVirtualKeyboardFromJS.qml:18
> +        function test_virtualKeyboardNotVisible() {
> +            var url = Qt.resolvedUrl("../common/focusInputElementFromJS.html")
> +
> +            webView.url = url

I want another test, like one click on a button and it calls js to focus something else which is editable... that should work

> Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:437
> +    // Ignore input method requests not due to a tap gesture.
> +    if (!editor.isContentEditable)
> +        setInputPanelVisible(false);

How is it doing that?
Comment 13 Michael Brüning 2012-08-20 08:45:41 PDT
Created attachment 159439 [details]
Patch
Comment 14 Caio Marcelo de Oliveira Filho 2012-08-20 09:41:20 PDT
Comment on attachment 159439 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=159439&action=review

> Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:437
>      qApp->inputMethod()->update(Qt::ImQueryInput | Qt::ImEnabled | Qt::ImHints);
>  
> -    setInputPanelVisible(editor.isContentEditable);
> +    // Ignore input method requests not due to a tap gesture.
> +    if (!editor.isContentEditable)
> +        setInputPanelVisible(false);

Do we need to update() the input method when we are setting the input panel to invisible?

> Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:454
> -    updateTextInputState();
> +    qApp->inputMethod()->update(Qt::ImQueryInput | Qt::ImEnabled | Qt::ImHints);
> +
> +    const EditorState& editor = m_webPageProxy->editorState();
> +    bool newVisible = editor.isContentEditable;
> +    setInputPanelVisible(newVisible);

Don't we need to update WebView's flag ItemAcceptsInputMethod?

Could the common code of updateTextInputState() and doneWithGestureEvent() be moved to a function that both call?
Comment 15 Kenneth Rohde Christiansen 2012-08-20 13:02:58 PDT
Comment on attachment 159439 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=159439&action=review

> Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:435
> +    // Ignore input method requests not due to a tap gesture.

The comment is not so good because we do hide it.

> Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:453
> +    qApp->inputMethod()->update(Qt::ImQueryInput | Qt::ImEnabled | Qt::ImHints);
> +
> +    const EditorState& editor = m_webPageProxy->editorState();
> +    bool newVisible = editor.isContentEditable;

The difference here from updateTextInputState is minimal, so either it needs a comment or you could give updateTextInputState an argument. Like why is it ok to ignore the postpone? or the hasActiveFocus?
Comment 16 Michael Brüning 2012-08-21 07:21:02 PDT
(In reply to comment #15)
> (From update of attachment 159439 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=159439&action=review
> 
> > Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:435
> > +    // Ignore input method requests not due to a tap gesture.
> 
> The comment is not so good because we do hide it.

Actually, this comment was at that line in exactly the same wording for quite a while until my previous change (the one which caused the trouble with the assert) removed it. But I do agree that it does not really explain why we're hiding the thing, so I'll reword it when I post the refactoring...

> 
> > Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:453
> > +    qApp->inputMethod()->update(Qt::ImQueryInput | Qt::ImEnabled | Qt::ImHints);
> > +
> > +    const EditorState& editor = m_webPageProxy->editorState();
> > +    bool newVisible = editor.isContentEditable;
> 
> The difference here from updateTextInputState is minimal, so either it needs a comment or you could give updateTextInputState an argument. Like why is it ok to ignore the postpone? or the hasActiveFocus?

Hm, afaics, it's not ignoring any of those :). The postpone gets reset to false here because it is set by the single tap gesture and this is the callback / handler that gets called when this single tap gesture is done.
Comment 17 Michael Brüning 2012-08-21 08:02:21 PDT
Comment on attachment 159439 [details]
Patch

Clearing flags, will post updated patch later.
Comment 18 Jocelyn Turcotte 2014-02-03 03:21:10 PST
=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.