Bug 77884 – [Qt][WK2] Can't use TAB key to navigate on webpage links

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Hugo Parente Lima]

How to reproduce:

Open MiniBrowser on desktop mode and try to change the focus pressing the Tab key, it must behave like QtTestBrowser.

[Hugo Parente Lima]

Created attachment 125670 [details]
Patch

[Caio Marcelo de Oliveira Filho]

Hugo, did you checked the LayoutTests after this?

I think this might cause some LayoutTests to fail. The support for override preference that enabled/disable this is not done yet for WK2. So if the test use layoutTestController to change this preference, it won't work. Could you check that. Grepping for "WebKitTabToLinksPreferenceKey" might give you a hint.

[Hugo Parente Lima]

Good to know, I'll take a look.

[Hugo Parente Lima]

I just removed the "review?" flag until I check the issue with the layout tests.

[Hugo Parente Lima]

Created attachment 126128 [details]
Patch

[Hugo Parente Lima]

Created attachment 126141 [details]
Patch

[Simon Hausmann]

Comment on attachment 126141 [details]
Patch

Making the tab preference available to us in WK2 makes sense to me, but turning this into a WebCore::Setting sounds like something that should be dealt with in a separate change.

I'm not sure the move to WC::Settings is actually worth it, but if it's done then I suppose it should replace the existing ChromeClient's keyboardUIMode(). Having both, a WC::Setting _and_ the virtual keyboardUIMode() would be wrong IMHO.

[Hugo Parente Lima]

(In reply to comment #7)
> (From update of attachment 126141 [details])
> Making the tab preference available to us in WK2 makes sense to me, but turning this into a WebCore::Setting sounds like something that should be dealt with in a separate change.
> 
> I'm not sure the move to WC::Settings is actually worth it, but if it's done then I suppose it should replace the existing ChromeClient's keyboardUIMode(). Having both, a WC::Setting _and_ the virtual keyboardUIMode() would be wrong IMHO.

I don't know if it can fully replace the virtual keyboardUIMode() because this virtual returns a enum with 3 possible values, replacing it by the value stored on WC::Settings would mean remove the KeyboardAccessFull option from keyboardUIMode().

The tab preference is stored per webkit port on ChromeClient implementations, as WK2 have their own and unique ChromeClient implementation, ugly hacks like the ones used on other ports to check if the tab preference is on or off isn't possible, e.g. some ports just put a #ifdef and get the tab preference value directly from a DRT support class.

KeyboardAccessFull seems to be used only on Mac ports, unfortunately my Objective-C skill didn't help me too much to understand why it exists.

[Hugo Parente Lima]

What do you think about WC::Settings storing the int value with the mask used by  keyboard UI mode? This for sure should exclude the need of keyboardUIMode() virtual.

[Jocelyn Turcotte]

=== 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.