332435 - Can't set reverse selection in textarea with js

Status: UNCONFIRMED

(Core :: DOM: Selection, defect, P5)

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

It seems impossible to set a reverse selection (the kind of selection that you get if you drag your mouse to the left) in a textarea/text input element.  I focus on textarea in this report because of Bug 265159.

Reproducible: Always

Steps to Reproduce:
In the accompanying attachment, enter the arguments for setSelectionRange in the textboxes, then press Set.  This will attempt to set the textarea's selection.  If you have not yet put focus in the textarea, you can see this whether this happens (on account of Bug 332424 - To quickly see whether this method still works or not, you could change the first number to 2 and then press Set.  If it's not working, you'll have to go into the textarea each time to see what happened to the selection).
Actual Results:  
If the first number is greater than the second number, no selection is set in the textarea.

Expected Results:  
1.  If the first number is greater than the second number, I expect to see the same selection as if the numbers were reversed, but diddling with the arrow keys in the textarea should affect the left side of the selection.
2.  TEXTAREA.selectionStart and TEXTAREA.selectionEnd should return the anchor and focus positions, respectively, to reflect this sense of direction in the selection.  Currently, .selectionEnd is guaranteed to be at least .selectionStart, even if a reverse selection has been made by dragging the mouse leftwards.

selections within textareas/text input elements are definitely 2nd class citizens.  It might be worth thinking about whether it makes sense to have something like TEXTAREA.getSelection().  This might, however, be messy since this would then expose methods for extending the range outside the original control.

Csaba Gabor from Vienna

Comment 1

[Csaba Gabor]

Attachment: Reverse selection tester

Comment 2

[Martijn Wargers (dead)]

I've had to alter your testcase to get it working to show the bug.
Could you perhaps post a new testcase that shows the bug?

Note the discussion in bug 88049, comment 138 and further.
It seems that this was implemented this way deliberately.
However, when looking at the discussion in that bug, it seems that it should work for text inputs, but not for textarea's.

Could you perhaps post a testcase that compares this behavior between text inputs and textareas?

If there's a difference in behavior between the two, there is certainly a bug here.

Comment 3

[Csaba Gabor]

> I've had to alter your testcase to get it working to show the bug.
> Could you perhaps post a new testcase that shows the bug?

I now have a new, improved test page which I discuss below, but I don't understand how it was not working for you.  Just to make sure, when you bring up the original test case (and the new one, for that matter), if you press Set right away, you will not see any change because Start/End are showing in reverse  (Start>End) order.  However, if you swap them right at the beginning and then press Set, you'll see that the selections are made.

> Note the discussion in bug 88049, comment 138 and further.
> It seems that this was implemented this way deliberately.

I have read all 152(!) comments in that report.  However, what I picked up from comments 138+ was different.  What I got from it was that they (at least the original implementer) wanted to have the functionality pretty much as I outlined, only it was left out in the rush to get it all into the build.

The one thing that was new to me along these lines was that .selectionStart and .selectionEnd are writable and that .setSelectionRange was just a simpler way of setting first the Start and then the End.  So I tested out my new page with both .setSelectionRange() and setting .selectionStart/End individually, but the results were the same (ie. no reverse ranges).

> However, when looking at the discussion in that bug, it seems that it should
> work for text inputs, but not for textarea's.
 
> Could you perhaps post a testcase that compares this behavior between text
> inputs and textareas?

I have done this, and as near as I can see the behaviors (as far as this report goes) are the same (they do differ in that when you enter a text input element by means of the keyboard, because of extra events firing as discussed in Bug 265159, the selection is collapsed).

> If there's a difference in behavior between the two, there is certainly a bug
> here.

Agreed, and it doesn't seem to be an issue here.

Here's what I did to test: because the selection is collapsed when you enter a text input element, I figured I should set the selection while I was inside the element.  Therefore, if you type an x in either control, after a setTimeout, the selection in Both controls will be set.  No new discoveries, but it is more thorough.

From my read, Start/End (should) determine the direction of the selection, and the values they return should be the same as what they were set with.  It should not be expected that .selectionStart<=.selectionEnd.  Since .setSelectionRange is just syntactic sugar for setting Start/End at the same time, I don't particularly mind if it stays the same (though I think it should be revised, too).

Csaba

PS.  As regards the final comment in my original post, it is covered in Bug 85686

Comment 4

[Csaba Gabor]

Attachment: Revised reverse selection test page

OK, it just dawned on me that I could have made my just prior comment here.  Entering an x in either text control will cause the selection in both to be set.

Comment 5

[Martijn Wargers (dead)]

Hmm, I'm beginning to believe this is more or less invalid, see:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html#Level-2-Range-Changing-h2
"
The start position of a Range is guaranteed to never be after the end position. To enforce this restriction, if the start is set to be at a position after the end, the Range is collapsed to that position. Similarly, if the end is set to be at a position before the start, the Range is collapsed to that position.
"
Also see bug 205635, where this is discussed.

While selectionStart and selectionEnd is Mozilla specific, I don't think it would be wise to deviate from the regular selection specification.

Comment 6

[Csaba Gabor]

(In reply to comment #5)
> Hmm, I'm beginning to believe this is more or less invalid, see:
> http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html#Level-2-Range-Changing-h2
> "
> The start position of a Range is guaranteed to never be after the end position.
...
> Also see bug 205635, where this is discussed.
> 
> While selectionStart and selectionEnd is Mozilla specific, I don't think it
> would be wise to deviate from the regular selection specification.

That Bug 205635 is about ranges and not selections.  This bug is about selections and not ranges (and I did an oops in referring to ranges twice, earlier - I should have written selection).

Pardon for this bugspam, but I'd like to assemble my thoughts on selection vs. range, especially since it took me a while to puzzle out the distinction.  I start with... a selection is what you get when you click with the mouse and then drag, and it could be in either direction.  Hence a selection has a (logical) notion of a start and end position, and these are what the anchor node (the start) and the focus node (the end) of the selection correspond to, giving the selection a sense of direction.  There is no restriction on the end position being at least equal to the start position.  A range, on the other hand, is a contiguous region (irrespective of whether it is visible or not) within the content of the DOM (as opposed to the page - this is significant because the text you see in a textarea/text input element is not part of the DOM content.  Oops).

What's the difference between the two?  A range is like the DOM in that you don't see it - it's an object.  You can see a representation of it, a selection.  That is, a selection is a (typically visually highlighted) collection of (disjoint?) ranges, together with a focusNode.

Although you can select disjoint ranges in Excel via the control key (and notice that there, the focus is distinct from the selection), I didn't get it to work in FF 1.5.0.1.  However, you can experience this (or a simulation thereof), if you do a search on google and you open the cached pages where the search terms will be highlighted in different color.  Or if you search for a word in emacs, each instance of the sought word will be highlighted and one will be specially highlighted.  Or if you highlight multiple files in Windows Explorer.

The reason this is relavant is that it lets us see that in the general case, the notion of anchorNode/Offset is meaningless.  focusNode/Offset is important because that is where the caret is.  anchorNode/Offset in the one range (OK, usual) situation corresponds to the other end of the (sole) range.  When the selection has multiple ranges, this is no longer well defined.  To be specific, in general a selection does not have a notion of start and end position - this is only an artifact in the one range situation (which, of course, is usually what is observed).  Finally, we can appreciate that a range having its start point before its end point is not unreasonable because it specifies a contiguous block.  A range by itself does not have notion of direction.  On the other hand, it is important to know where the caret (focusNode/Offset) is for a selection.

In conclusion, with textareas there is, unfortunately, currently no model for the underlying range, nor a way to specify multiple ranges.  That is to say, the notion of range and selection are synonymous, provided that the caret position (ie. the focus point) is known.  One way to achieve this would be through .selectionStart specifying the focusOffset (and hence .selectionEnd would specify the other endpoint of the selection/underlying range).  That is to say, .selectionStart/End are related to, but need not be identical to, the range start and end.

Comment 7

[Martijn Wargers (dead)]

(In reply to comment #6)
> That Bug 205635 is about ranges and not selections.  This bug is about
> selections and not ranges (and I did an oops in referring to ranges twice,
> earlier - I should have written selection).
You're doing setSelectionRange here. See the 'range' word. You can only progammatically set its selection through ranges.


> What's the difference between the two?  A range is like the DOM in that you
> don't see it - it's an object.  You can see a representation of it, a
> selection.  That is, a selection is a (typically visually highlighted)
> collection of (disjoint?) ranges, together with a focusNode.
Yes, true, and an anchorNode.

> Although you can select disjoint ranges in Excel via the control key (and
> notice that there, the focus is distinct from the selection), I didn't get it
> to work in FF 1.5.0.1.
This is working now in the trunk builds.

> The reason this is relavant is that it lets us see that in the general case,
> the notion of anchorNode/Offset is meaningless.  focusNode/Offset is important
> because that is where the caret is.  anchorNode/Offset in the one range (OK,
> usual) situation corresponds to the other end of the (sole) range.  When the
> selection has multiple ranges, this is no longer well defined.  
anchorNode is important too. In IE6 when you have a selection in a text control
and you press the left/right arrow key, the selection is collapsed to the focusNode or the anchorNode. (not sure how this works with multi-selection in IE, though. And currently, Mozilla is always collapsing at the focusNode)

> In conclusion, with textareas there is, unfortunately, currently no model for
> the underlying range, nor a way to specify multiple ranges. 
Yeah, that's what I really dislike about this model, there's no way to specify multiple ranges of the selection in a text control.

Comment 8

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.