ctrl + a is doing what the Home keyboard button does, move the cursor to the beginning of the line. I'm expected this hotkey to select all though.

this is working as-expected. Ctrl/Cmd-E would go to end of line except for bug 609744. You need to select a line or focus the console output area for Cmd/Ctrl-A to work.

(In reply to comment #1) > this is working as-expected. Why is this behavior expected? and how is this behavior useful? since the 'page up' key seems to do exactly the same thing and now I can't find a hotkey to select all.. > Ctrl/Cmd-E would go to end of line except for bug > 609744. ok, idk why you bring that up though.. > You need to select a line or focus the console output area for Cmd/Ctrl-A to > work. I'm referring to the console's input area (which I didn't make clear before sorry), so I don't think the howto's of selecting output are relevant.

(In reply to comment #2) > (In reply to comment #1) > > this is working as-expected. > > Why is this behavior expected? and how is this behavior useful? since the 'page > up' key seems to do exactly the same thing and now I can't find a hotkey to > select all.. All consoles on all platforms map control-a to beginning og line and control-e to end of line. This is actually very helpful to those with this muscle memory.

(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > this is working as-expected. > > > > Why is this behavior expected? and how is this behavior useful? since the 'page > > up' key seems to do exactly the same thing and now I can't find a hotkey to > > select all.. > > All consoles on all platforms map control-a to beginning og line and control-e > to end of line. This is actually very helpful to those with this muscle memory. Hmm I see, so Google Chrome is doing the same, but Firebug does not.. And how is a user supposed to select all?

(In reply to comment #4) > > All consoles on all platforms map control-a to beginning og line and control-e > > to end of line. This is actually very helpful to those with this muscle memory. > > Hmm I see, so Google Chrome is doing the same, but Firebug does not.. > > And how is a user supposed to select all? Sounds like we need to file a bug. Just checked my linux terminal - they make you use a menu item. perhaps we map it to alt - a? alt-a actually does it for me on linux. awesome.

let's reopen this rather than file a new bug but modify the summary. Alt-a is not going to work on all platforms. On OS X, it produces 'å'. Maybe ctrl-shift-a?

Err Rob, the way we normally do it here in Mozilla land is to have platform specific key bindings so that we can be consistent with platform conventions.

(In reply to comment #7) > Err Rob, the way we normally do it here in Mozilla land is to have platform > specific key bindings so that we can be consistent with platform conventions. yes, I know. The input line's a bit special, though I'm inclined to believe that we should probably change ctrl-a/e to do what users expect in Windows.

(In reply to comment #7) > Err Rob, the way we normally do it here in Mozilla land is to have platform > specific key bindings so that we can be consistent with platform conventions. what would be the platform conventions in this case? Apple-a on mac (which should work), alt-a on linux just works, not sure about windows.

cmd-a works on mac (select-all, no change required)., ctrl-a goes to beginning of line (expected, emacs keybindings for text widgets). ctrl-a in linux should go to beginning of line. you say alt-a selects all? That's probably correct there. ctrl-a on Windows (different from what we have now). Only change required.

(In reply to comment #10) > ctrl-a on Windows (different from what we have now). Only change required. On both Windows and Linux: If ctrl+a is mapped to select all, ctrl+e should not be mapped to end of line. (Additional context: On Windows, ctrl+e had been mapped to the search box, since at least before Firefox 2 (we took it from IE). It got removed and wasn't put back for 4.0 due to a string freeze fiasco, but we'll likely put it back for 4.x.) > ctrl-a in linux should go to beginning of line. you say alt-a selects all? > That's probably correct there. In all the input fields I've used in Firefox on Linux, both ctrl+a and alt+a select all. I don't think we should break this, but if we must map ctrl+a to beginning of line, alt+a should still select all. > cmd-a works on mac (select-all, no change required)., ctrl-a goes to beginning > of line (expected, emacs keybindings for text widgets). I agree. If we really want to match the convention of emacs keybindings that Cocoa text widgets use, ctrl+shift+a should select to beginning of line, and ctrl+shift+e should select to end of line.

ddahl just convinced me that the Web Console is actually a command line interface for the browser/web, so I'd like to revise my position. On Windows: Ctrl+A - use default keybinding (Select All) Ctrl+E - unmapped since even Windows's cmd.exe doesn't use emacs-style keybindings. On Mac and Linux: Ctrl+A - beginning of line (no change) Ctrl+E - end of line (no change) Ctrl+Shift+A - select to beginning of line Ctrl+Shift+E - select to end of line On Linux: Alt+A - Select All

triage. Filter on PINKISBEAUTIFUL

still a bug!

Hey I'm new to the group and would like to look at this more to get my feet wet. Have we established a convention for Windows yet or is it still up in the air?

(In reply to Will Carter from comment #19) > Hey I'm new to the group and would like to look at this more to get my feet > wet. Have we established a convention for Windows yet or is it still up in > the air? As I understand it, this just needs a patch. I recommend comment 16's list of mappings, but Ctrl+A -> Select All is the most important one.

(In reply to Will Carter from comment #19) > Hey I'm new to the group and would like to look at this more to get my feet > wet. Have we established a convention for Windows yet or is it still up in > the air? Is this fair game to work on, or are you still working on a patch for this?

(In reply to Cory Gackenheimer from comment #21) > (In reply to Will Carter from comment #19) > > Hey I'm new to the group and would like to look at this more to get my feet > > wet. Have we established a convention for Windows yet or is it still up in > > the air? > > Is this fair game to work on, or are you still working on a patch for this? I'd say, take it! :)

(In reply to Rob Campbell [:rc] (:robcee) from comment #18) > still a bug! Please CC me when I'm added as a mentor to a bug. Thank you!

Comment on attachment 716181 [details] [diff] [review] Control + a on windows will select all in Web Console Review of attachment 716181 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for your patch! Giving r+ with the comments below addressed. ::: browser/devtools/webconsole/test/Makefile.in @@ +125,5 @@ > endif > > +ifeq ($(OS_ARCH),WINNT) > +MOCHITEST_BROWSER_FILES += \ > + browser_webconsole_bug_623749.js \ can you please rename the test to something more self-explanatory? Maybe "browser_webconsole_ctrl_a_select_all_winnt.js". ::: browser/devtools/webconsole/test/browser_webconsole_bug_623749.js @@ +1,4 @@ > +/* Any copyright is dedicated to the Public Domain. > + * http://creativecommons.org/publicdomain/zero/1.0/ */ > + > +// Test for https://bugzilla.mozilla.org/show_bug.cgi?id=623749 Please explain what the test does. Maybe: Test for bug 623749 - Map Ctrl+A to Select All, in the Web Console input, on Windows. @@ +14,5 @@ > + > + > +function runTest(HUD) { > + jsterm = HUD.jsterm; > + jsterm.setInputValue("Ingore These Four Words"); typo: s/ingore/ignore/ @@ +17,5 @@ > + jsterm = HUD.jsterm; > + jsterm.setInputValue("Ingore These Four Words"); > + inputNode = jsterm.inputNode; > + > + //test select all with control + a nit: space after // ::: browser/devtools/webconsole/webconsole.js @@ +3114,5 @@ > let closePopup = false; > switch (aEvent.charCode) { > case 97: > // control-a > + if (Services.appinfo.OS != "WINNT") { nit: instead of nesting everything, you could do an early break for winnt. @@ +3133,5 @@ > closePopup = true; > break; > case 101: > // control-e > + if (Services.appinfo.OS != "WINNT") { Same as above.

Thanks for the review, I have submitted a new patch file to address the items from the previous review.

Comment on attachment 718008 [details] [diff] [review] new patch to reflect requested changes Cory: thanks for the quick update. Next time please fold the two patches. The second patch requires the first one. You should use MQ with HG, see http://mercurial.selenic.com/wiki/MqTutorial MQ helps a lot with managing patches. I'm going to push this patch to the try servers.

Folded the two patches. Pushed to the try servers: https://tbpl.mozilla.org/?tree=Try&rev=55aad1ec327e Once results are green I'm going to land your patch.

Landed the folded patch: https://hg.mozilla.org/integration/fx-team/rev/b1ba5ea6168b

Cory and Mihai, thank you for fixing this! :)

Hi, (I'm new to Bugzilla, excuse my question if I got something wrong) so Ctrl+a has been map to Select All for Windows, but what is the situation on Linux? Neither Ctrl+a or Alt+a seem to be working. If there was no patch for the Linux case, shall I open a new bug or reopen this one with a different title? Thanks in advance :)

(In reply to k from comment #32) > Hi, (I'm new to Bugzilla, excuse my question if I got something wrong) > so Ctrl+a has been map to Select All for Windows, but what is the situation > on Linux? Neither Ctrl+a or Alt+a seem to be working. If there was no patch > for the Linux case, shall I open a new bug or reopen this one with a > different title? > Thanks in advance :) Works for me on Linux.

my mistake, the Alt key was catch by an addon, sorry to have bothered