Changeset 21476 in webkit


Ignore:
Timestamp:
May 14, 2007, 11:15:21 PM (18 years ago)
Author:
justing
Message:

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.
Location:
trunk
Files:
5 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r21475 r21476  
     12007-05-14  Justin Garcia  <justin.garcia@apple.com>
     2
     3        Reviewed by ggaren
     4       
     5        Updated these expected results.  We now clear the
     6        selection inside a focused node *after* firing the
     7        mousedown event handler, which matches FF:
     8        * fast/forms/focus-selection-input-expected.txt:
     9        * fast/forms/focus-selection-textarea-expected.txt:
     10
    1112007-05-14  Justin Garcia  <justin.garcia@apple.com>
    212

  • trunk/LayoutTests/fast/forms/focus-selection-input-expected.txt

    r20950 r21476  
    77EDITING DELEGATE: shouldChangeSelectedDOMRange:(null) toDOMRange:range from 0 of #text > DIV to 0 of #text > DIV affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
    88EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
    9 EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
    10 EDITING DELEGATE: shouldChangeSelectedDOMRange:(null) toDOMRange:range from 0 of #text > LABEL > BODY > HTML > #document to 5 of #text > LABEL > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
     9EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of #text > DIV to 0 of #text > DIV toDOMRange:range from 0 of #text > LABEL > BODY > HTML > #document to 5 of #text > LABEL > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
    1110EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
    1211EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification

  • trunk/LayoutTests/fast/forms/focus-selection-textarea-expected.txt

    r20386 r21476  
    77EDITING DELEGATE: shouldChangeSelectedDOMRange:(null) toDOMRange:range from 0 of #text > DIV to 0 of #text > DIV affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
    88EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
    9 EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
    10 EDITING DELEGATE: shouldChangeSelectedDOMRange:(null) toDOMRange:range from 0 of #text > LABEL > BODY > HTML > #document to 5 of #text > LABEL > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
     9EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of #text > DIV to 0 of #text > DIV toDOMRange:range from 0 of #text > LABEL > BODY > HTML > #document to 5 of #text > LABEL > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
    1110EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
    1211EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification

  • trunk/WebCore/ChangeLog

    r21474 r21476  
     12007-05-14  Justin Garcia  <justin.garcia@apple.com>
     2
     3        Reviewed by ggaren
     4       
     5        <http://bugs.webkit.org/show_bug.cgi?id=13716>
     6        REGRESSION: Three new layout test failures
     7       
     8        Two failures are correct.  Updated their expected results.
     9       
     10        In fast/events/frame-tab-focus.html, as we advance
     11        through focusable nodes, we descend into a subframe
     12        to focus a node and then ascend out of it into the
     13        main frame to focus the next.  When we focus the main
     14        frame, the node in that frame that was previously
     15        focused and contains an inactive selection is focused
     16        momentarily because setCaretVisible tries to focus the
     17        node containing the caret.
     18
     19        * page/Frame.cpp:
     20        (WebCore::Frame::setCaretVisible): Don't focus the
     21        node containing the caret. FocusController will focus
     22        the previously focused node (which will contain the
     23        caret) if necessary when the frame gains focus.
     24       
    1252007-05-14  Maciej Stachowiak  <mjs@apple.com>
    226

  • trunk/WebCore/page/Frame.cpp

    r21467 r21476  
    570570        return;
    571571    clearCaretRectIfNeeded();
    572     if (flag)
    573         setFocusedNodeIfNeeded();
    574572    d->m_caretVisible = flag;
    575573    selectionLayoutChanged();
Note: See TracChangeset for help on using the changeset viewer.