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
+2007-05-14 Justin Garcia <justin.garcia@apple.com>
+
+ 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:
+
2007-05-14 Justin Garcia <justin.garcia@apple.com>
Reviewed by ggaren
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: shouldChangeSelectedDOMRange:(null) toDOMRange:range from 0 of #text > DIV to 0 of #text > DIV affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
-EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
-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
+EDITING 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
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: shouldChangeSelectedDOMRange:(null) toDOMRange:range from 0 of #text > DIV to 0 of #text > DIV affinity:NSSelectionAffinityDownstream stillSelecting:FALSE
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
-EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
-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
+EDITING 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
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification
+2007-05-14 Justin Garcia <justin.garcia@apple.com>
+
+ 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.
+
2007-05-14 Maciej Stachowiak <mjs@apple.com>
Reviewed by Brady.
if (d->m_caretVisible == flag)
return;
clearCaretRectIfNeeded();
- if (flag)
- setFocusedNodeIfNeeded();
d->m_caretVisible = flag;
selectionLayoutChanged();
}