Fix issue where Chromium thought it had active focus

Previously, when a WebEngineView's RenderWidgetHostViewQtDelegateQuick
had focus, but not activeFocus, Chromium was told that it had keyboard
focus. That is not correct, because having focus inside the FocusScope
(the WebEngineView), does not mean it has keyboard focus, it just
means the RWHVQDQ will receive active focus, when the WebEngineView
does.

The call path for that erronous check was done when a new page was
loaded, specifically going through
NavigatorImpl::DidNavigate() ->
RenderFrameHostManager::CommitPending() ->
render_frame_host_->GetView()->HasFocus() ->
RenderWidgetHostViewQtDelegateQuick::hasKeyboardFocus(),
which resulted in incorrect display of a blinking caret in an
input, when the view actually wasn't focused.

The fix consists in checking for the activeFocus rather than the
focus property.

Change-Id: I97002be3fc8adfec2228a1b5ad62696f8872d3cc
Reviewed-by: Michael Brüning <michael.bruning@qt.io>

1 files changed, 1 insertions, 1 deletions

diff --git a/src/webengine/render_widget_host_view_qt_delegate_quick.cpp b/src/webengine/render_widget_host_view_qt_delegate_quick.cpp
index b10ca8bdb..e198e5e0d 100644
--- a/src/webengine/render_widget_host_view_qt_delegate_quick.cpp
+++ b/src/webengine/render_widget_host_view_qt_delegate_quick.cpp
@@ -128,7 +128,7 @@ void RenderWidgetHostViewQtDelegateQuick::setKeyboardFocus()
 
 bool RenderWidgetHostViewQtDelegateQuick::hasKeyboardFocus()
 {
-    return hasFocus();
+    return hasActiveFocus();
 }
 
 void RenderWidgetHostViewQtDelegateQuick::lockMouse()