Open Bug 332424 Opened 18 years ago Updated 3 years ago

Setting control's selection before first focus makes it visible

Categories

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

x86
Windows XP
defect

Tracking

()

UNCONFIRMED

People

(Reporter: danswer, Unassigned)

Details

Attachments

(1 file)

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

If I use a button to set the selection of either a textarea or text input element before they have received focus, then those selections will be visible until focus has been set on the control elements.  Subsequently, the button will set the selection, but it will not be visible until focus has returned to the control element (and in the case of the text element it still won't be visible on account of Bug 265159).

Csaba Gabor from Vienna

Reproducible: Always

Steps to Reproduce:
See bug 128953, the problem is that when a textfield blurs, the selection is being made invisible.
So the selection in a textfield is not being made invible when clicking in any other part of the page, but because the textfield loses the focus.

This is indeed not the way this should be done.
Ideally, the selection of text inside a textfield should behave just like any other selection in a page, except it should have it's own independant selection.
Frankly, I'd rather not see what I reported fixed just yet.  There are some good reasons for keeping this behaviour around.

And I agree with you about how it should be, with a slight modification that was alluded to in bug 128953: When the textarea (or any element with a selection) does not have focus, the color of the selection should be faded so that the user doesn't start thinking that the field has focus.  In other words, the "active selection" should have a distinct color.

There does seem to be a more serious aspect to this report, that would bear fixing (don't know if it should get a separate report) as long as it's not fixing the above behaviour:
[I have the setting where I can march the caret around the page (but I've forgetten how I set it up) and make selections via the keyboard]
Bring up the attachment I previously submitted (attachment 216885 [details]) and press alt+s in order to ensure that focus goes to the button.  Now start pressing the left arrow key.  The caret marches right across the textarea and input box, even though you can't actually enter anything.
You have caret browsing enabled, probably (which you can enable/disable with F7).
I see what you mean, you should file a new bug on that (supposed that there hasn't been filed a bug about it already).
Assignee: selection → nobody
QA Contact: selection

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.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: