tabbing to next field doesn't pre-select text

VERIFIED DUPLICATE of bug 28583

Status

()

Core
Editor
P4
normal
VERIFIED DUPLICATE of bug 28583
17 years ago
17 years ago

People

(Reporter: Judson Valeski, Assigned: Charles Manske)

Tracking

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Add a table to a document using the table icon on the taskbar. The first text
field in the dialog has its text pre-selected. Hit tab, and you'll notice that
the next text field selected does not have its text pre-selected.

Dialog text field values should be pre-selected when tabbed into.

Comment 1

17 years ago
I see this in other dialogs (on Mac); reassign to cmanske for further triage
this bug is really annoying; nominate for mozilla 0.9
Assignee: beppe → cmanske
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 2

17 years ago
This was by design. You actually like this behavior? I sure don't.
If this is to be changed, it would have to be for *all* textfields in all
dialogs in all modules.
(Reporter)

Comment 3

17 years ago
preselection is the default behavior on windows, linux seems to default to the 
current behavior (not preselection), not sure about mac.

Comment 4

17 years ago
Linux does not autoselect contents of text fields when they're focused, by default.

In some dialogs, it might make sense to autoselect the contents of a text field;
but that should be done by the dialog, not automatically by the toolkit.

We already have a pref, "browser.urlbar.clickSelectsAll", to turn this behavior
on in the urlbar for people who want the Windows-type behavior.  If people are
now wanting this behavior in text fields, too, perhaps this pref should be
renamed and generalized.

Comment 5

17 years ago
While Linux (and other Unix vendors?) doesn't pre-select on focus, it does always 
place the caret at the end of the text in the editfield (rather than before the 
first character).

I think this bug should be to have a preference which toggles in two ways:
  * always select all text in the field
  * always put the caret at the end of the text field (unless it's a right-to-
left editfield???)

This bug should also cover making both of these options work.

Mac and Windows should default to the first option
Linux (and presumably other flavors) should default to the 2nd option.

Who wants to do this work? :-)
(Assignee)

Comment 6

17 years ago
I see where to make the fix: in nsTextEditorFocusListener::Focus() handler,
so I'll work on it.
Status: NEW → ASSIGNED
(Assignee)

Comment 7

17 years ago
Created attachment 26102 [details] [diff] [review]
Add select-all logic based on pref.

Comment 8

17 years ago
Note: In 4.x Mac, the text in a textarea is also selected when tabbing into the 
textarea.  Also, this behavior is consistent in that dialog behavior is the same 
as browser form elements.  In input textfields and textareas, "select all" only 
happens on tabbing (not when clicking to focus--with the hacked exception of the 
urlbar).

Comment 9

17 years ago
P4 priority
Priority: -- → P4
(Assignee)

Comment 10

17 years ago
*** Bug 47367 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Summary: tabbing to next field in table creation dialog doesn't pre-select text → tabbing to next field doesn't pre-select text

Comment 11

17 years ago
moving to mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.0

Comment 12

17 years ago


*** This bug has been marked as a duplicate of 28583 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 13

17 years ago
verified in 4/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.