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.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
this isn't working in general textfields for me, in html content, on linux. Marking all, nsbeta1.
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).
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
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.
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.
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 :)