Issue metadata
Sign in to add a comment
|
Updating TEXTAREA child nodes without updating textContent should do nothing. |
||||||||||||||||||||||
Issue description
Chrome Version: 59 canary
OS: All but iOS
What steps will reproduce the problem?
(1) Load the following HTML.
<!DOCTYPE html>
<textarea>initial value</textarea>
<script>
var ta = document.querySelector('textarea');
ta.focus();
ta.setSelectionRange(1, 1);
ta.appendChild(document.createTextNode(''));
alert('selection: ' + ta.selectionStart + ',' + ta.selectionEnd);
</script>
What is the expected result?
An alert dialog shows "selection: 1,1".
What happens instead?
An alert dialog shows "selection: 13,13".
Please use labels and text to provide additional information.
Safari and Edge shows 1,1. Firefox shows 13,13.
https://html.spec.whatwg.org/multipage/forms.html#the-textarea-element:textcontent
> When the textarea element's textContent IDL attribute changes value, if the element's dirty value flag is false, then the element's raw value must be set to the value of the element's textContent IDL attribute.
textContent isn't changed in the above HTML code. So we should do nothing.
This is a regression since https://chromium.googlesource.com/chromium/src/+/32b0cf12895a50d1be5962eaa393ec952fea1f4e%5E%21/
,
Mar 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5cd3e773b0851d6e56bc2bcb46802c637c50b837 commit 5cd3e773b0851d6e56bc2bcb46802c637c50b837 Author: tkent <tkent@chromium.org> Date: Mon Mar 06 09:26:33 2017 TEXTAREA element: Updating child nodes without updating textContent should do nothing https://html.spec.whatwg.org/multipage/forms.html#the-textarea-element:textcontent > When the textarea element's textContent IDL attribute changes value, if the > element's dirty value flag is false, then the element's raw value must be set > to the value of the element's textContent IDL attribute. We should do nothing if textContent isn't changed. New behavior matches to Edge, Safari, and the standard, and doesn't match to Firefox. BUG= 698647 Review-Url: https://codereview.chromium.org/2733783003 Cr-Commit-Position: refs/heads/master@{#454840} [modify] https://crrev.com/5cd3e773b0851d6e56bc2bcb46802c637c50b837/third_party/WebKit/LayoutTests/fast/forms/textarea/textarea-selection-preservation-expected.txt [modify] https://crrev.com/5cd3e773b0851d6e56bc2bcb46802c637c50b837/third_party/WebKit/LayoutTests/fast/forms/textarea/textarea-selection-preservation.html [modify] https://crrev.com/5cd3e773b0851d6e56bc2bcb46802c637c50b837/third_party/WebKit/Source/core/html/HTMLTextAreaElement.cpp [modify] https://crrev.com/5cd3e773b0851d6e56bc2bcb46802c637c50b837/third_party/WebKit/Source/core/html/HTMLTextAreaElement.h
,
Mar 6 2017
Please, make sure Firefox knows it is the odd one now by filing an issue...
,
Mar 8 2017
Filed a mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1345293 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Mar 6 2017