LayoutTests:
authorjusting <justing@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 15 May 2007 06:15:21 +0000 (06:15 +0000)
committerjusting <justing@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 15 May 2007 06:15:21 +0000 (06:15 +0000)
commite1af1335c731fd727a9ce3a95c31df13637ddbfd
tree507db9cf2a2ff201304f6b422c2779b5e47424e2
parenta345310c26422ee6301f839bcae6fbd3a725728d
LayoutTests:

        Reviewed by ggaren

        Updated these expected results.  We now clear the
        selection inside a focused node *after* firing the
        mousedown event handler, which matches FF:
        * fast/forms/focus-selection-input-expected.txt:
        * fast/forms/focus-selection-textarea-expected.txt:

WebCore:

        Reviewed by ggaren

        <http://bugs.webkit.org/show_bug.cgi?id=13716>
        REGRESSION: Three new layout test failures

        Two failures are correct.  Updated their expected results.

        In fast/events/frame-tab-focus.html, as we advance
        through focusable nodes, we descend into a subframe
        to focus a node and then ascend out of it into the
        main frame to focus the next.  When we focus the main
        frame, the node in that frame that was previously
        focused and contains an inactive selection is focused
        momentarily because setCaretVisible tries to focus the
        node containing the caret.

        * page/Frame.cpp:
        (WebCore::Frame::setCaretVisible): Don't focus the
        node containing the caret. FocusController will focus
        the previously focused node (which will contain the
        caret) if necessary when the frame gains focus.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@21476 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/fast/forms/focus-selection-input-expected.txt
LayoutTests/fast/forms/focus-selection-textarea-expected.txt
WebCore/ChangeLog
WebCore/page/Frame.cpp