selectionDirection should not return "none" on non-Mac |
|||
Issue description
Version: 54
OS: Windows, Linux, and Android
What steps will reproduce the problem?
(1) open the following HTML.
(2) Wait for two seconds.
<!DOCTYPE html>
<input value="abc" onfocus="console.log(this.selectionEnd);">
<script>
setTimeout(function() {
var i = document.querySelector('input');
i.selectionEnd = 0;
i.selectionStart = 0;
i.blur();
i.select();
alert('direction=' + i.selectionDirection);
}, 2000);
</script>
What is the expected output?
A dialog with "direction=forward" is shown.
What do you see instead?
A dialog with "direction=none" is shown.
Non-Mac platforms don't support "none" direction. Edge shows "forward" correctly in this case.
https://html.spec.whatwg.org/multipage/forms.html#set-the-selection-range
> The direction of the selection must be set to
> backward if direction is a case-sensitive match for the string "backward",
> forward if direction is a case-sensitive match for the string "forward" or if the platform does not support selections with the direction none,
> and none otherwise (including if the argument is omitted).
Please use labels and text to provide additional information.
,
Aug 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9cde715f00643052484f4cb60ed0d9593b5661ca commit 9cde715f00643052484f4cb60ed0d9593b5661ca Author: tkent <tkent@chromium.org> Date: Thu Aug 25 04:15:52 2016 setSelectionRange() for INPUT and TEXTAREA should not set "none" direction on non-macOS platforms. setSelectionRange(s, e) unexpectedly called the four-argument version of HTMLTextFormControlElement::setSelectionRange() with SelectionHasNoDirection. So it set "none" direction without EditingBehavior check. This CL renames the implementation function of web-exposed setSelectionRange() to setSelectionRangeForBinding(), and makes its third argument optional so that seSelectionRange(s, e) calls it. On non-macOS platforms, two tests in textfieldselection-setSelectionRange.html correctly fail. BUG= 640861 Review-Url: https://codereview.chromium.org/2274103002 Cr-Commit-Position: refs/heads/master@{#414306} [modify] https://crrev.com/9cde715f00643052484f4cb60ed0d9593b5661ca/third_party/WebKit/LayoutTests/platform/win/imported/wpt/html/semantics/forms/textfieldselection/textfieldselection-setSelectionRange-expected.txt [modify] https://crrev.com/9cde715f00643052484f4cb60ed0d9593b5661ca/third_party/WebKit/Source/core/html/HTMLInputElement.cpp [modify] https://crrev.com/9cde715f00643052484f4cb60ed0d9593b5661ca/third_party/WebKit/Source/core/html/HTMLTextAreaElement.idl [modify] https://crrev.com/9cde715f00643052484f4cb60ed0d9593b5661ca/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.cpp [modify] https://crrev.com/9cde715f00643052484f4cb60ed0d9593b5661ca/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.h
,
Aug 25 2016
Oops, the report was partially wrong. > i.select(); > A dialog with "direction=none" is shown. In this case, Chrome correctly shows direction=forward because select() does focus() internally, and selectionDirection is computed from FrameSelection. I think this was problematic only if setSelectionRange(start, end) was used, and #2 fixed it.
,
Aug 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f04e619a56c036526512eec982029e8e0cf095e1 commit f04e619a56c036526512eec982029e8e0cf095e1 Author: tkent <tkent@chromium.org> Date: Thu Aug 25 07:29:37 2016 Remove NeedToDispatchSelectEvent argument of HTMLTextFormControlElement::select(). A callsite with NotDispatchSelectEvent is updated so that it calls the four-argument version of setSelectedRange(). This CL has no behavior changes. BUG= 640861 Review-Url: https://codereview.chromium.org/2274413003 Cr-Commit-Position: refs/heads/master@{#414349} [modify] https://crrev.com/f04e619a56c036526512eec982029e8e0cf095e1/third_party/WebKit/Source/core/html/HTMLInputElement.cpp [modify] https://crrev.com/f04e619a56c036526512eec982029e8e0cf095e1/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.cpp [modify] https://crrev.com/f04e619a56c036526512eec982029e8e0cf095e1/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.h [modify] https://crrev.com/f04e619a56c036526512eec982029e8e0cf095e1/third_party/WebKit/Source/core/html/forms/TextFieldInputType.cpp
,
Aug 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e31411764112e03a39ff3683a4aa8367e950e8d9 commit e31411764112e03a39ff3683a4aa8367e950e8d9 Author: tkent <tkent@chromium.org> Date: Thu Aug 25 16:22:12 2016 Fix selectionDirection after setting value of TEXTAREA/INPUT. slectionDirection wrongly returned "none" on non-Mac platforms in such case. This CL - makes sure that selection operations are done by setSelectionRange(). - moves direction normalization code from setSelectionRangeForBinding() to setSelectionRange(). Also, this makes cacheSelection() private. Only HTMLTextFormControlElement calls it. BUG= 640861 Review-Url: https://codereview.chromium.org/2277903003 Cr-Commit-Position: refs/heads/master@{#414451} [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/LayoutTests/fast/forms/selection-direction-expected.txt [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/LayoutTests/fast/forms/selection-direction.html [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/Source/core/html/HTMLInputElement.cpp [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/Source/core/html/HTMLInputElement.h [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.cpp [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.h [modify] https://crrev.com/e31411764112e03a39ff3683a4aa8367e950e8d9/third_party/WebKit/Source/core/html/forms/TextFieldInputType.cpp
,
Aug 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b3aa5da1f6257e84087e7fb7a1b7ed546177cae commit 1b3aa5da1f6257e84087e7fb7a1b7ed546177cae Author: tkent <tkent@chromium.org> Date: Fri Aug 26 09:33:31 2016 Fix selectionDirection attribute value of INPUT/TEXTAREA just after creation. selectionDirection incorrectly returned "none" in such case even on non-Mac platforms. BUG= 640861 Review-Url: https://codereview.chromium.org/2285613002 Cr-Commit-Position: refs/heads/master@{#414678} [modify] https://crrev.com/1b3aa5da1f6257e84087e7fb7a1b7ed546177cae/third_party/WebKit/LayoutTests/fast/forms/selection-direction-expected.txt [modify] https://crrev.com/1b3aa5da1f6257e84087e7fb7a1b7ed546177cae/third_party/WebKit/LayoutTests/fast/forms/selection-direction.html [modify] https://crrev.com/1b3aa5da1f6257e84087e7fb7a1b7ed546177cae/third_party/WebKit/Source/core/html/HTMLTextFormControlElement.cpp
,
Aug 26 2016
,
Oct 12 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by tkent@chromium.org
, Aug 25 2016