Bug 45061
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 |
Tony Chang
The test is checking to see what elements get focus when tab is pressed. For some reason, an anchor is skipped over in chromium.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
yosin
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.
yosin
Update test expectation for Chromium:
http://trac.webkit.org/changeset/124731
Tony Chang
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.
yosin
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);
}
Tony Chang
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?
yosin
(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.
Tony Chang
(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.
yosin
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
Stephen Chenney
Marking test failures as WontFix. Bug is still accessible and recording in TestExpectations.