The test is checking to see what elements get focus when tab is pressed. For some reason, an anchor is skipped over in chromium.
Chromium DumpRenderTree sets tabsToLinks to false[1]. http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/chromium/WebPreferences.cpp#L111 So, links aren't be tab stop.
Update test expectation for Chromium: http://trac.webkit.org/changeset/124731
How does this test pass on Apple Mac's port? They also set tabsToLinks to NO: http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/mac/DumpRenderTree.mm#L629 If chromium DRT gets a different result from Apple Mac DRT, we need to understand why we're getting a different result, not just check in a new baseline.
fast/forms/focus2.html sends Option+Tab key events[1]. As of Safari, Option+Tab set focus to anchor. This is a reason why behavior of Chromium DRT and Mac DRT is different. Note: Win port skipped this test, because Alt+Tab in Windows is handled by system, switching foreground process. [1] http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/focus2.html?rev=121008#L112 function dispatchOptionTab(element, shiftKey) { var event = document.createEvent("KeyboardEvents"); var tabKeyIdentifier = "U+0009"; event.initKeyboardEvent( "keydown", // type true, // canBubble true, // cancelable document.defaultView, // view tabKeyIdentifier, // keyIdentifier 0, // KeyLocation false, // ctrlKey true, // altKey ***** shiftKey, false, // metaKey false); // altGraphKey element.dispatchEvent(event); }
Do we pass the test on Chromium Mac? We should fix the test so it is not OS specific. What does options+tab do on OSX? What would be the equivalent key combination on Win/Linux to Options+Tab on OSX?
(In reply to comment #5) > Do we pass the test on Chromium Mac? Yes. Chromium Mac doesn't handle Option+Tab as Safari/Mac. There is a flag in chrome://setteings page whether Tab key sets focus on anchor or not. Chrome Linux/Mac/Win checks this settings rather than special key combination.
(In reply to comment #6) > (In reply to comment #5) > > Do we pass the test on Chromium Mac? > > Yes. Chromium Mac doesn't handle Option+Tab as Safari/Mac. There is a flag in > chrome://setteings page whether Tab key sets focus on anchor or not. Chrome Linux/Mac/Win checks this settings rather than special key combination. I see, so on Safari Mac, Option+Tab always sets focus on anchor. It seems like a bug that Chromium Mac doesn't obey this key combination. We normally try to match platform convention for keyboard shortcuts. It sounds like the different behavior is expected on Win/Linux, but perhaps we should move this test into the platform/mac directory. We could also split this into two tests: 1 test for the cross platform behavior and 1 test for the mac specific behavior.
To make Option+Tab (Alt+Tab) to set focus on anchor if preferences sets tabs-to-link as false, it seems we can add PLATFORM(CHROMIUM) && OS(MAC) to EventHandler::eventInvertsTabsToLinksClientCallResult[1]. bool EventHandler::eventInvertsTabsToLinksClientCallResult(KeyboardEvent* event) { #if PLATFORM(MAC) || PLATFORM(QT) || PLATFORM(EFL) return EventHandler::isKeyboardOptionTab(event); #else return false; #endif } This function is called by EventHandler::tabsToLinks. [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/EventHandler.cpp#L3308
Marking test failures as WontFix. Bug is still accessible and recording in TestExpectations.