Bug 45061 – [chromium] fast/forms/focus2.html fails

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Tools / Tests

[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.

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

[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.

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?

(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.

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.