Bug 84875 - [Qt][WK2] Virtual keyboard is not showing when user clicks inside of <input> tag
Summary: [Qt][WK2] Virtual keyboard is not showing when user clicks inside of <input> tag
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-25 10:59 PDT by Alex Bravo
Modified: 2012-11-02 09:46 PDT (History)
12 users (show)

See Also:


Attachments
Patch (2.01 KB, patch)
2012-04-25 17:21 PDT, Alex Bravo
no flags Details | Formatted Diff | Diff
Test case for type="text" and type="password" <input> tags (902 bytes, text/x-python)
2012-11-02 09:07 PDT, Manuel Kaufmann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Bravo 2012-04-25 10:59:44 PDT
This problem happens on both Linux (11.10 x64) and Harmattan/N9.

One simple solution is to either add ItemAcceptsInputMethod permanently in here (new line is marked with //AB).

From Source/WebKit2/UIProcess/qt/QtWebPageEventHandler.cpp:

QtWebPageEventHandler::QtWebPageEventHandler(WKPageRef pageRef, QQuickWebPage* qmlWebPage, QQuickWebView* qmlWebView)
    : m_webPageProxy(toImpl(pageRef))
    , m_interactionEngine(0)
    , m_panGestureRecognizer(this)
    , m_pinchGestureRecognizer(this)
    , m_tapGestureRecognizer(this)
    , m_webPage(qmlWebPage)
    , m_webView(qmlWebView)
    , m_previousClickButton(Qt::NoButton)
    , m_clickCount(0)
    , m_postponeTextInputStateChanged(false)
{
    connect(qApp->inputPanel(), SIGNAL(visibleChanged()), this, SLOT(inputPanelVisibleChanged()));
    m_webView->setFlag(QQuickItem::ItemAcceptsInputMethod, true);  //AB
}

Or alternatively add this flag only if editor content is editable:

void QtWebPageEventHandler::updateTextInputState()
{
    if (m_postponeTextInputStateChanged)
        return;

    const EditorState& editor = m_webPageProxy->editorState();

    if (!m_webView->hasFocus())
        return;

    // Ignore input method requests not due to a tap gesture.
    if (!editor.isContentEditable) {
        m_webView->setFlag(QQuickItem::ItemAcceptsInputMethod, false);  //AB
        setInputPanelVisible(false);
    }
}

void QtWebPageEventHandler::doneWithGestureEvent(const WebGestureEvent& event, bool wasEventHandled)
{
    if (event.type() != WebEvent::GestureSingleTap)
        return;

    m_postponeTextInputStateChanged = false;

    if (!wasEventHandled || !m_webView->hasFocus())
        return;

    const EditorState& editor = m_webPageProxy->editorState();
    bool newVisible = editor.isContentEditable;

    m_webView->setFlag(QQuickItem::ItemAcceptsInputMethod, newVisible);  //AB
}

Note: Once this issue with ItemAcceptsInputMethod is solved, another bug in focusEditableArea() (called from QtWebPageEventHandler::inputPanelVisibleChanged())
shows up. This bug prevents Virtual keyboard from showing when user clicks inside of <input> tag second time (after Edit area is zoomed in once.)
To temporary fix this problem and be able to use ZVirtual keyborad repeatedly, either zoom page manually or comment out two lines marked with //AB as shown below:

void QtWebPageEventHandler::inputPanelVisibleChanged()
{
    if (!m_interactionEngine)
        return;

    // We only respond to the input panel becoming visible.
    if (!m_webView->hasFocus() || !qApp->inputPanel()->visible())
        return;

    const EditorState& editor = m_webPageProxy->editorState();

//AB    if (editor.isContentEditable)
//AB        m_interactionEngine->focusEditableArea(QRectF(editor.cursorRect), QRectF(editor.editorRect));
}
Comment 1 Jesus Sanchez-Palencia 2012-04-25 11:14:19 PDT
Alex, thanks for looking into this!

Do you plan to submit a patch for review following webkit guidelines?
Comment 2 Alex Bravo 2012-04-25 11:24:29 PDT
(In reply to comment #1)
> Alex, thanks for looking into this!
> 
> Do you plan to submit a patch for review following webkit guidelines?

I wanted to get first the feedback on wheach of mentioned two ways of adding ItemAcceptsInputMethod is better before I do a patch.
Comment 3 Kenneth Rohde Christiansen 2012-04-25 12:19:36 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > Alex, thanks for looking into this!
> > 
> > Do you plan to submit a patch for review following webkit guidelines?
> 
> I wanted to get first the feedback on wheach of mentioned two ways of adding ItemAcceptsInputMethod is better before I do a patch.

Even if it is not for review, it would be so much easier to give comments if it was uploaded as a patch
Comment 4 Alex Bravo 2012-04-25 17:21:19 PDT
Created attachment 138906 [details]
Patch
Comment 5 Alex Bravo 2012-04-25 17:26:23 PDT
In the proccess of testing this patch I found out that the trunk works without this patch just fine - vkb is show and hidden.
Which means that more investigation is needed on my part to find out which of the other of my changes are needed for this patch.
Comment 6 Lauro Moura Maranhao Neto 2012-04-26 11:13:56 PDT
How did you test it? I've just tested revision 115325 against the latest pinned Qt5 hash (From early April) and VKB is not shown. I tested using a release build with both Snowshoe[1] and Femto[2] on a PR1.2 N9.

[1] http://github.com/snowshoe/snowshoe/
[2] https://gitorious.org/femto/femto
Comment 7 Alex Bravo 2012-04-26 11:38:25 PDT
(In reply to comment #6)
> How did you test it? 

I'm using MiniBrowser. I tested yesterday with trunk at  ebfce6a90080fe64aa07d009354ff4a975267782 on desktop.
Comment 8 Noam Rosenthal 2012-04-26 11:40:47 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > How did you test it? 
> 
> I'm using MiniBrowser. I tested yesterday with trunk at  ebfce6a90080fe64aa07d009354ff4a975267782 on desktop.

You mean, on desktop with maliit enabled :)
Comment 9 Rafael Brandao 2012-04-26 11:44:00 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > How did you test it? 
> > 
> > I'm using MiniBrowser. I tested yesterday with trunk at  ebfce6a90080fe64aa07d009354ff4a975267782 on desktop.
> 
> You mean, on desktop with maliit enabled :)

Did you run MiniBrowser in desktop mode or mobile?
Comment 10 Alex Bravo 2012-04-26 11:52:30 PDT
> Did you run MiniBrowser in desktop mode or mobile?

I'm not using --desktop switch, which I guess makes it run in mobile mode?
What's the difference?

@No'am Yes, I malliit was installed. Abd Qt compiled with dbus.
Comment 11 Alex Bravo 2012-04-27 17:12:22 PDT
I verified that vkb is shown and hidden in MiniBrowser using revision 115493.
There's still an issue with zooming in when the WebView is not the same size as the whole window, but that's a separate bug.

So I'm marking this bug as resolved.
Comment 12 Noam Rosenthal 2012-04-30 16:50:09 PDT
Comment on attachment 138906 [details]
Patch

Clearing review flag.
Comment 13 Manuel Kaufmann 2012-11-02 09:07:27 PDT
Created attachment 172077 [details]
Test case for type="text" and type="password" <input> tags

Test case
Comment 14 Manuel Kaufmann 2012-11-02 09:08:13 PDT
Comment on attachment 172077 [details]
Test case for type="text" and type="password" <input> tags

I'm having a similar issue in Browse[1] (from the OLPC / Sugar Platform). It shows the Maliit virtual keyboard on <input type="text"> tags but it doesn't for <input type="password">.

I create a simple script as test case. It shows a webpage that has two <input> tags, one is type="text" which reveals the virtual keyboard and the other one is type="password" that doesn't reveal the VK. It's attached.

Any clue where I can take a look?

[1] http://git.sugarlabs.org/browse
Comment 15 Manuel Kaufmann 2012-11-02 09:46:08 PDT
(In reply to comment #14)
> Any clue where I can take a look?

I found this bug that deals with this specific issue:

 * https://bugs.webkit.org/show_bug.cgi?id=34285