45061 2010-09-01 14:00:42 -0700 [chromium] fast/forms/focus2.html fails 2013-04-09 16:27:56 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX P2 Normal --- 1 tony webkit-unassigned shinyak yosin oldest_to_newest 272996 0 tony 2010-09-01 14:00:42 -0700 The test is checking to see what elements get focus when tab is pressed. For some reason, an anchor is skipped over in chromium. 687754 1 yosin 2012-08-05 22:04:49 -0700 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. 687757 2 yosin 2012-08-05 22:12:14 -0700 Update test expectation for Chromium: http://trac.webkit.org/changeset/124731 687791 3 tony 2012-08-05 23:28:32 -0700 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. 687830 4 yosin 2012-08-06 00:52:38 -0700 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); } 687880 5 tony 2012-08-06 02:11:09 -0700 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? 687884 6 yosin 2012-08-06 02:14:11 -0700 (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. 687896 7 tony 2012-08-06 02:26:13 -0700 (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. 688643 8 yosin 2012-08-06 18:19:49 -0700 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 872280 9 schenney 2013-04-09 16:27:56 -0700 Marking test failures as WontFix. Bug is still accessible and recording in TestExpectations.