As we can see in http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r69922%20(6689)/results.html all spatial-navigation tests stderr the following message: LayoutTestController::overridePreference tried to override unknown preference 'WebKitTabToLinksPreferenceKey'.
Gtk's LayoutTestController::overridePreference implementation does not support "WebKitTabToLinksPreferenceKey", but in the end it does not affect to spatial-navigation tests because Gtk "tabs to links" unconditionally: 331 bool ChromeClient::tabsToLinks() const 332 { 333 return true; 334 } It is not the case for Mac and Qt for example: both honor this preference.
Martin, Xan: do you guys have interest in supporting DRT's WebKitTabToLinksPreferenceKey preference? Also, is there a way to set WebCore's Settings without having the corresponding webkitwebsettings? In Qt we have for example WebKit/qt/WebCoreSupport/DumpRenderTreeSupportQt.cpp|h can sets WebCore stuff directly from DRT/LayoutTestController.
I have interest in getting tests that use this key working. I've considered adding something like your DumpRenderTreeSupport in the past. Perhaps this is an opportunity to do that.
Good to hear, Martin. We could start simple, like having this setter :). I could get to it. Would you have any special request for its design? In Qt they are mostly a bunch of static methods.
(In reply to comment #4) > Good to hear, Martin. We could start simple, like having this setter :). I could get to it. Would you have any special request for its design? In Qt they are mostly a bunch of static methods. Awesome! That'd be very helpful, as I am swamped right now and it would be maybe end of this week before I could get to it. I think having the same design (could it even share code?) as the Qt version makes a lot of sense (static methods).
Shold be fixed by http://trac.webkit.org/changeset/70609. Waiting for the bots to catch up before closing accordingly.
(In reply to comment #6) > Shold be fixed by http://trac.webkit.org/changeset/70609. > > Waiting for the bots to catch up before closing accordingly. Yes, fixed by r70609.
Thanks again!