Bug 157793 - [GTK] Cannot focus out of the WebKitWebView using Tab/Shift+Tab
Summary: [GTK] Cannot focus out of the WebKitWebView using Tab/Shift+Tab
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-17 07:32 PDT by Milan Crha
Modified: 2018-09-06 02:32 PDT (History)
3 users (show)

See Also:


Attachments
test-wk2.c (3.08 KB, text/plain)
2016-05-17 07:32 PDT, Milan Crha
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Crha 2016-05-17 07:32:35 PDT
Created attachment 279120 [details]
test-wk2.c

The attached is a test example (the first line contains a command line to compile and run it), which packs a GtkEntry on the left and two WebKitWebView-s split by a GtkLabel on the right of the window. The idea is that the Tab key should circle between: GtkEntry, 1st WebView, 2nd WebView, Cancel button. The Shift+Tab should do the same, only in the opposite order. Once the WebView is focused, the next press can eventually focus the next focusable element, being it an anchor, an input or any similar, but it should also focus out, when there is nothing more to be focused in the WebView. The example has the anchor in each WebView, but those are only for testing, that the Tab/Shift+Tab does something with the WebView (there is no visual indication that the WebView is focused).

The current output (I'm at git commit 6f2ad6890b143) of the test example is:
a) using Tab, it circles between GtkEntry, 1st WebView, the internal anchor, 1st WebView, the internal anchor, ...
b) using Shift+Tab, it circles between GtkEntry, Cancel button, 2nd WebView, the internal anchor, 2nd WebView, the internal anchor, ...

That is, it never leaves the WebView once it is entered.

There is no difference with or without the anchors, except it seems nothing is focused when pressing the key, because it's the WebView focused (and it has no visual indication that it has focus). Except of this, there are special cases, like:
1) the WebView being in a read-only mode (like in this example),
2) the WebView has turned on caret mode,
3) the WebView is an editor (contenteditable; which can eat the Tab for itself, but should react on Ctrl+Tab/Ctrl+Shift+Tab)