Closed
Bug 1345293
Opened 8 years ago
Closed 8 years ago
Firefox-only: selection after TEXTAREA child node change
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: tkent, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Steps to reproduce:
Update TEXTAREA child nodes without updating textContent value like:
<!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>
Actual results:
Firefox shows "selection: 13,13"
Expected results:
Edge, Safari, and Chrome 59 shows "selection 1,1"
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.
The specification doesn't mention text selection, however the intention of this paragraph is that we should do nothing if 'textContent' value is not changed.
Ehsan, is it related to bug 1337392 in some way?
Component: Untriaged → DOM: Core & HTML
Flags: needinfo?(ehsan)
|
||
Comment 3•8 years ago
|
||
Boris, how does this test case behave with your recent changes?
Flags: needinfo?(ehsan) → needinfo?(bzbarsky)
|
||
Comment 4•8 years ago
|
||
With my recent changes you get "1,1".
Depends on: 1343037
Flags: needinfo?(bzbarsky)
|
|
||
Comment 5•8 years ago
|
||
Note that per spec behavior here is fairly undefined in general. https://github.com/whatwg/html/issues/2424 tracks that.
|
||
Updated•8 years ago
|
Priority: -- → P3
|
|
||
Comment 6•8 years ago
|
||
Fixed as far as it goes, but note that the spec issue is still open and our new behavior still doesn't match Chrome in various cases. Nor do other browsers match either us or Chrome for various aspects of this behavior.
But for the "no change to the content" case, we should now have interop.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•