If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Select All via Cmd-A not working in dialogs

VERIFIED WORKSFORME

Status

()

Core
Keyboard: Navigation
P5
normal
VERIFIED WORKSFORME
17 years ago
16 years ago

People

(Reporter: Adam, Assigned: Chris McAfee)

Tracking

({helpwanted})

Trunk
Future
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Oops. Meant keyboard nav.
Assignee: joki → don
Component: Event Handling → Keyboard Navigation
QA Contact: lorca → sairuh
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
(Assignee)

Comment 3

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

Keywords: nsbeta1
OS: Mac System 9.x → All
Hardware: Macintosh → All
(Assignee)

Comment 4

17 years ago
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).
Assignee: vishy → mcafee
OS: All → Windows 2000
Hardware: All → PC

Comment 5

17 years ago
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.
(Reporter)

Comment 6

17 years ago
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

17 years ago
> 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.
OS: Windows 2000 → All
Hardware: PC → All
(Assignee)

Comment 8

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

Comment 9

17 years ago
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

17 years ago
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

17 years ago
nav triage team:

marking nsbeta1+ for now
Whiteboard: nsbeta1+

Comment 12

17 years ago
nav triage team:

Putting on the backburner, removing nsbeta1+, marking p5 and future
Priority: P3 → P5
Whiteboard: nsbeta1+
Target Milestone: --- → Future
should i mark this nsbeta1- since this has been futured? unless The Process has
changed. ;)
Keywords: helpwanted
(Assignee)

Comment 14

17 years ago
I think pchen intended to minus this and not keep on the beta1 radar.
okay...
Keywords: nsbeta1 → nsbeta1-
(Reporter)

Comment 16

17 years ago
I checked this in the 4/20 Mac build and it appears to be working. Fixed?
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
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 :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.