Summary: | [chromium] fast/forms/focus2.html fails | ||
---|---|---|---|
Product: | WebKit | Reporter: | Tony Chang <tony> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | shinyak, yosin |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | OS X 10.5 |
Description
Tony Chang
2010-09-01 14:00:42 PDT
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. |