60614 - Select All via Cmd-A not working in dialogs

Status: VERIFIED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Description

[Adam]

11/17 trunk, NS6 -

1) open the preferences dialog
2) click in the location field in the homepage section
3) press Command+A

Nothing happens. All of the text should be selected. This occurs in the find
pseudo-dialog, the open web location dialog, and I'm sure any other dialog that
pops up in Moz. Very annoying, especially since tabbing to a field doesn't
automatically select text. Command+A works fine in every other part of the
browser, so this might be a xpapps/toolkit or selection problem.

Comment 1

[Adam]

Oops. Meant keyboard nav.

Comment 2

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 3

[Chris McAfee]

this isn't working in general textfields for me, in html content, on linux.
Marking all, nsbeta1.

Comment 4

[Chris McAfee]

this is broken for the find dialog on windows, works on linux (emacs bindings)
bindings need to show up in the platform bindings files (textfield & textarea).

Comment 5

[Blake Ross]

This is really a question of whether or not we want the contents of textfields 
to inherently get selected via ctrl+A, which would rule out using that shortcut 
for anything else in most cases.  Unlike ctrl+c/v/z, ctrl+a is not a basic 
Windows shortcut for standard textboxes.

Comment 6

[Adam]

This was originally a Mac bug (where Command+A is the standard for selecting all 

text). Unless it's been fixed, this bug should still be All/All.

Comment 7

[Matthew T (active 1999-2002)]

> This is really a question of whether or not we want the contents of textfields 
> to inherently get selected via ctrl+A, which would rule out using that shortcut
> for anything else in most cases.

The only platform where this will be a problem is Mac OS (where keyboard 
shortcuts and accesskeys both use the Command key, see bug 959). On other 
platforms, there won't be any clash.

Comment 8

[Chris McAfee]

this should be a mac bug, can we mark this as such?

Comment 9

[Matthew T (active 1999-2002)]

mcafee, you said it wasn't working in the find dialog on Windows. If that's still 
the case, this isn't just a Mac bug.

Comment 10

[Akkana Peck]

It's a problem on linux, too (since there's a binding conflict between
select-all and beginning-of-line) but there's already a bug on the linux issue.
 If Windows people are happy with the current behavior, then this one should
probably be mac only.

Comment 11

[Paul Chen]

nav triage team:

marking nsbeta1+ for now

Comment 12

[Paul Chen]

nav triage team:

Putting on the backburner, removing nsbeta1+, marking p5 and future

Comment 13

[sairuh (rarely reading bugmail)]

should i mark this nsbeta1- since this has been futured? unless The Process has
changed. ;)

Comment 14

[Chris McAfee]

I think pchen intended to minus this and not keep on the beta1 radar.

Comment 15

[sairuh (rarely reading bugmail)]

okay...

Comment 16

[Adam]

I checked this in the 4/20 Mac build and it appears to be working. Fixed?

Comment 17

[sairuh (rarely reading bugmail)]

yeah, this is working for me on mac and winNT [2001.04.25.09]. not sure if there
was a specific fixed checked in, though there have been other fixes for
keybinding issues. so, gonna mark as wfm.

Comment 18

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)