When (qml) WebView looses focus the focus status is not updated correctly to WebProcess.
QtWebPageEventHandler::handleFocusOutEvent calls WebPageProxy::viewStateDidChange which then
checks the focus from QtPageClient::isViewFocused. QtPageClient::isViewFocused returns QQuickWebView::hasFocus
but the actual "focus" property value has not changed yet and thus it returns true.
This can be seen e.g. in MiniBrowser by clicking address bar after launching as the caret
is left blinking on google search front page text input.
I'll check this.
Created attachment 165137 [details]
The solution here might be a bit "hacky", but it seems to be the least complicated way. Better suggestions are welcome as always :)
Would it possible to set the focus value on the UIProcess side as soon as the event is send to the WebProcess? Focus out shouldn't be an event the WebProcess can block anyway.
(In reply to comment #4)
> Would it possible to set the focus value on the UIProcess side as soon as the event is send to the WebProcess? Focus out shouldn't be an event the WebProcess can block anyway.
It's not really the WebProcess "blocking" the focus, it's the UI process feeding it with the wrong value and hence the FocusController doesn't set the focus on the text element correctly.
Anyway, after digging through the focus event handling etc, I have found that
virtual void QQuickItem::itemChange(ItemChange change, const ItemChangeData &value);
is the right method to override here as also e.g. the QQuickTextInput uses that for deciding about lost focus (gaining focus seems to work...). Updated patch coming soon...
Created attachment 165379 [details]
As already correctly noted by Simon on irc, the call to QQuickItem::itemChange() will be changed to QQuickFlickable::itemChange().
Created attachment 165559 [details]
Created attachment 165592 [details]
Comment on attachment 165592 [details]
Clearing flags on attachment: 165592
Committed r129496: <http://trac.webkit.org/changeset/129496>
All reviewed patches have been landed. Closing bug.