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.
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
this isn't working in general textfields for me, in html content, on linux. Marking all, nsbeta1.
OS: Mac System 9.x → All
Hardware: Macintosh → All
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
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.
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.
> 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.
this should be a mac bug, can we mark this as such?
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.
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.
nav triage team: marking nsbeta1+ for now
nav triage team: Putting on the backburner, removing nsbeta1+, marking p5 and future
Priority: P3 → P5
Target Milestone: --- → Future
should i mark this nsbeta1- since this has been futured? unless The Process has changed. ;)
I think pchen intended to minus this and not keep on the beta1 radar.
Keywords: nsbeta1 → nsbeta1-
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: 18 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.