Bug 77884

Created attachment 125670 [details] Patch

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.

Good to know, I'll take a look.

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

Created attachment 126128 [details] Patch

Created attachment 126141 [details] Patch

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.

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

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.

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