879799 - Browser console lacks keyboard access

Status: VERIFIED FIXED

(DevTools :: Console, defect)

Description

[Dão Gottwald [:dao]]

I couldn't find a way to clear the output with the keyboard. The old console had an access key for that.

In fact it looks like none of the buttons at the top of the browser console window are keyboard accessible.

Comment 1

[Mihai Sucan [:msucan]]

Thanks for the bug report.

Is this a blocker for the browser console feature?

We have Bug 612252 for the clear output keyboard shortcut. I can make a patch for that.

For the filter buttons I assume making them accessible by tab should be sufficient. Is that correct?

Is there anything else needed beyond the above?

Comment 2

[Dão Gottwald [:dao]]

(In reply to Mihai Sucan [:msucan] from comment #1)
> Thanks for the bug report.
> 
> Is this a blocker for the browser console feature?

General accessibility requirements put aside, the console is a particularly keyboard-centric UI, so making sure we don't ship this regression probably makes sense.

> For the filter buttons I assume making them accessible by tab should be
> sufficient. Is that correct?

There are two problems with that: 1. The help links in the output area are in the tab order, which would make using the tab key to switch focus between the buttons and the input field a bit painful, unless you're mindful of using tab to go in one direction and shift+tab to go in the other direction. 2. If the input field is focused, the tab key currently can't move focus outside of it.

Comment 3

[Mihai Sucan [:msucan]]

Attachment: proposed patch

This patch does the following:

- adds Ctrl/Cmd-F: focus filter field. (matches chrome)

- adds Ctrl/Cmd-K: clear output. (matches chrome)

- adds accesskeys for the filter categories. (similar to the error console)

- changes the Right arrow to accept completion suggestion if the cursor is at the end of the input or if the user navigated through the list of suggestions with Up/Down. (matches chrome)

- changes Enter to accept completion suggestion if the user navigated through the list of suggestions with Up/Down. (matches chrome)

Since bug 873250 landed Enter does not accept suggestions even if you go Up/Down through suggestions, which is really unexpected/confusing. We changed one problem with another one, unfortunately.

- fixed tabbing order as much as possible. Output needs a rewrite for better tabbing, but even as it is now it's better. You can tab through output links, through filter categories, Clear button, filter input and the jsterm input.

Please let me know if further changes are needed. Thank you!

Try push: https://tbpl.mozilla.org/?tree=Try&rev=f6c4dab63782

Comment 4

[Dão Gottwald [:dao]]

(In reply to Mihai Sucan [:msucan] from comment #3)
> Created attachment 763786 [details] [diff] [review]
> proposed patch
> 
> This patch does the following:
> 
> - adds Ctrl/Cmd-F: focus filter field. (matches chrome)
> 
> - adds Ctrl/Cmd-K: clear output. (matches chrome)

Are these exposed anywhere? How are users supposed to know about them?

By the way, I don't see Ctrl+K clear the console in Chrome 27.

> - adds accesskeys for the filter categories. (similar to the error console)

Why should the clear button not get an access key?

Comment 5

[Mihai Sucan [:msucan]]

(In reply to Dão Gottwald [:dao] from comment #4)
> (In reply to Mihai Sucan [:msucan] from comment #3)
> > Created attachment 763786 [details] [diff] [review]
> > proposed patch
> > 
> > This patch does the following:
> > 
> > - adds Ctrl/Cmd-F: focus filter field. (matches chrome)
> > 
> > - adds Ctrl/Cmd-K: clear output. (matches chrome)
> 
> Are these exposed anywhere? How are users supposed to know about them?

Where can they be exposed? We need user docs. Chrome has a help, we don't have one yet.

> By the way, I don't see Ctrl+K clear the console in Chrome 27.

Yes, I can confirm that Ctrl-K doesn't clear output on Linux - Ctrl-L does it. However, according to research Nick did, it does work. [1] Chrome does this differently from system to system, IIANM. Nick uses Mac, I use Linux. 

Do we want such system-to-system differences in shortcuts? Cmd-L focuses the address bar, while Cmd-K focuses the web search. I prefer to steal the search field shortcut, not the address bar shortcut. Plus, Ctrl-K is not an uncommon choice for clear output - should be easy enough to discover.


[1] https://etherpad.mozilla.org/hot-hot-hotkeys


> > - adds accesskeys for the filter categories. (similar to the error console)
> 
> Why should the clear button not get an access key?

It has a shortcut, Ctrl-K. Should it also get an accesskey?

Do note that we now have a problem with access keys and Mac OS. Accesskeys are triggered with Ctrl-foo which means that Network button can be focused with Ctrl-N. That shortcut is also used for line navigation in the jsterm input, however the accesskey now takes precedence, meaning that Ctrl-N no longer works as desired in the jsterm input. Should I just leave it as it is? Depending on each localization different Ctrl-foo keys will be stolen by these new access keys.

Also, you can't tab to buttons by defaults on Macs. You need to go to the keyboard prefs and enable an option that allows this behavior.

I don't see how we can solve the Ctrl-N conflict other than to ifdef-out the accesskeys on Macs, or to just let the inconsistent behavior. Thoughts?

Thanks for looking into the patch!

Comment 6

[Victor Porof [:vporof][:vp]]

My 2¢: iTerm uses Cmd+K. Same goes for Chrome on OS X. I think it's a very common and discoverable shortcut, and I would expect many devs have this engrained into their muscle memory.

Comment 7

[Dão Gottwald [:dao]]

(In reply to Mihai Sucan [:msucan] from comment #5)
> > > This patch does the following:
> > > 
> > > - adds Ctrl/Cmd-F: focus filter field. (matches chrome)
> > > 
> > > - adds Ctrl/Cmd-K: clear output. (matches chrome)
> > 
> > Are these exposed anywhere? How are users supposed to know about them?
> 
> Where can they be exposed? We need user docs. Chrome has a help, we don't
> have one yet.

We usually expose command keys in menus.

> > By the way, I don't see Ctrl+K clear the console in Chrome 27.
> 
> Yes, I can confirm that Ctrl-K doesn't clear output on Linux - Ctrl-L does
> it. However, according to research Nick did, it does work. [1] Chrome does
> this differently from system to system, IIANM. Nick uses Mac, I use Linux. 
> 
> Do we want such system-to-system differences in shortcuts? Cmd-L focuses the
> address bar, while Cmd-K focuses the web search. I prefer to steal the
> search field shortcut, not the address bar shortcut. Plus, Ctrl-K is not an
> uncommon choice for clear output - should be easy enough to discover.

Ideally we would steal neither shortcut. Also note that I certainly wouldn't have tried to clear the console with Ctrl-K. If there's such a convention, it was entirely unknown to me. I don't think we can expect people to just know about it.

> > > - adds accesskeys for the filter categories. (similar to the error console)
> > 
> > Why should the clear button not get an access key?
> 
> It has a shortcut, Ctrl-K. Should it also get an accesskey?

There's the discoverability problem (see above). An access key wouldn't have that problem.

> Do note that we now have a problem with access keys and Mac OS. Accesskeys
> are triggered with Ctrl-foo which means that Network button can be focused
> with Ctrl-N. That shortcut is also used for line navigation in the jsterm
> input, however the accesskey now takes precedence, meaning that Ctrl-N no
> longer works as desired in the jsterm input. Should I just leave it as it
> is? Depending on each localization different Ctrl-foo keys will be stolen by
> these new access keys.

Sounds like the underlying problem here is that jsterm shouldn't use the Ctrl-* pattern on OS X if that's reserved for access keys there?

Comment 8

[Mihai Sucan [:msucan]]

(In reply to Dão Gottwald [:dao] from comment #7)
> > Where can they be exposed? We need user docs. Chrome has a help, we don't
> > have one yet.
> 
> We usually expose command keys in menus.

We do not have menus here.

> > Do we want such system-to-system differences in shortcuts? Cmd-L focuses the
> > address bar, while Cmd-K focuses the web search. I prefer to steal the
> > search field shortcut, not the address bar shortcut. Plus, Ctrl-K is not an
> > uncommon choice for clear output - should be easy enough to discover.
> 
> Ideally we would steal neither shortcut. Also note that I certainly wouldn't
> have tried to clear the console with Ctrl-K. If there's such a convention,
> it was entirely unknown to me. I don't think we can expect people to just
> know about it.

Agreed, yet Ctrl-L and Ctrl-K both steal existing shortcuts, and we have to make a concession here if we want to pick one of the common shortcuts for clearing output in terminals/consoles.


> > > > - adds accesskeys for the filter categories. (similar to the error console)
> > > 
> > > Why should the clear button not get an access key?
> > 
> > It has a shortcut, Ctrl-K. Should it also get an accesskey?
> 
> There's the discoverability problem (see above). An access key wouldn't have
> that problem.

Yes, but take into account that adding an accesskey to the clear button would steal two shortcuts, not one. One needs to be Ctrl-K or Ctrl-L - since one of these is what is used for the majority of terminals/consoles out there. The second shortcut would be the one assigned through the label and its access key. Given that "C" is taken for "CSS", "L" is taken for "Logging", we would end up with "e". Alt+E shows the Edit menu. We would end up with Ctrl+K/Ctrl+L and Alt+E to clear the output. This also depends on the language.

Access keys have the disadvantage of being different for every language. Also, they are not discoverable on Macs - no underline.


> > Do note that we now have a problem with access keys and Mac OS. Accesskeys
> > are triggered with Ctrl-foo which means that Network button can be focused
> > with Ctrl-N. That shortcut is also used for line navigation in the jsterm
> > input, however the accesskey now takes precedence, meaning that Ctrl-N no
> > longer works as desired in the jsterm input. Should I just leave it as it
> > is? Depending on each localization different Ctrl-foo keys will be stolen by
> > these new access keys.
> 
> Sounds like the underlying problem here is that jsterm shouldn't use the
> Ctrl-* pattern on OS X if that's reserved for access keys there?

Ctrl-N and Ctrl-P is native on Macs for inputs to move the cursor up and down. The problem is really with MacOSX which chooses to use Ctrl-* for accesskeys and for editing commands in inputs. This is not a jsterm thing.

Comment 9

[Rob Campbell [:rc] (:robcee)]

as for needing "help", the "help" command in the jsterm input line will take you to the MDN page. We can add information there specific to the Browser Console.

Comment 10

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 763786 [details] [diff] [review]
proposed patch

Review of attachment 763786 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/webconsole/webconsole.js
@@ +3809,5 @@
> +        if (this._autocompletePopupNavigated &&
> +            this.autocompletePopup.isOpen &&
> +            this.autocompletePopup.selectedIndex > -1) {
> +          this.acceptProposedCompletion();
> +        }

why is this here?

@@ +3872,5 @@
> +        if (this.autocompletePopup.isOpen) {
> +          this.clearCompletion();
> +        }
> +        break;
> +      }

not strictly necessary for this bug. I'd almost prefer not riffing on autocompletion in this bug. It's separate. Not saying it wouldn't improve this, I just don't want to think about it in this review.

@@ +4199,5 @@
>      this.lastCompletion = { value: null };
>      this.updateCompleteNode("");
>      if (this.autocompletePopup.isOpen) {
>        this.autocompletePopup.hidePopup();
> +      this._autocompletePopupNavigated = false;

all of these would go away.

::: browser/devtools/webconsole/webconsole.xul
@@ +144,5 @@
>          </toolbarbutton>
>  
>          <toolbarbutton class="webconsole-clear-console-button devtools-toolbarbutton"
> +                       label="&btnClear.label;" tooltiptext="&btnClear.tooltip;"
> +                       tabindex="8"/>

good. Nice to see these getting some tab controls.

Comment 11

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 763786 [details] [diff] [review]
proposed patch

yeah, thinking about the completion suggestion and up/down it makes sense. I think we should keep it.

testing locally but r+.

Comment 12

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 763786 [details] [diff] [review]
proposed patch

canceling r+ until we can figure out what to do about the keyboard conflicts with toolbar button accesskeys and cmd/ctrl-K stealing access from the searchbox on all platforms.

Comment 13

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 763786 [details] [diff] [review]
proposed patch

regarding. cmd/ctrl-k, go ahead: steal it.

as for ctrl-p/n on mac, I don't care either way. I'm not sure many people use ctrl-p/n for history navigation or not. Would need more data.

Comment 14

[Dão Gottwald [:dao]]

(In reply to Mihai Sucan [:msucan] from comment #8)
> > There's the discoverability problem (see above). An access key wouldn't have
> > that problem.
> 
> Yes, but take into account that adding an accesskey to the clear button
> would steal two shortcuts, not one. One needs to be Ctrl-K or Ctrl-L - since
> one of these is what is used for the majority of terminals/consoles out
> there.

Have there been requests that we should support Ctrl-K/L either for the error console or the web console? Can this be handled in a new bug? This one was really supposed to be about standard, discoverable keyboard accessibility rather than special keys developers may or may not expect to work.

> The second shortcut would be the one assigned through the label and
> its access key. Given that "C" is taken for "CSS", "L" is taken for
> "Logging", we would end up with "e". Alt+E shows the Edit menu.

Alt+A is still available.

> This also depends on the language.

Right, access keys always need to be picked with special care. This isn't a new problem.

> Access keys have the disadvantage of being different for every language.
> Also, they are not discoverable on Macs - no underline.

Is this true? There's no way to expose access keys on Mac? In that case I'd say: just ignore Mac and make the access keys work for other platforms.

> Ctrl-N and Ctrl-P is native on Macs for inputs to move the cursor up and
> down. The problem is really with MacOSX which chooses to use Ctrl-* for
> accesskeys and for editing commands in inputs. This is not a jsterm thing.

Then you should probably use some other access key and document that other locales should't pick N or P either?

(In reply to Rob Campbell [:rc] (:robcee) from comment #13)
> Comment on attachment 763786 [details] [diff] [review]
> proposed patch
> 
> regarding. cmd/ctrl-k, go ahead: steal it.

I don't think that's sound. You'd also need to prevent accel+k from being advertised as the search command key in the menu bar, and of course this would raise the question of whether it's ok to break accessibility for search.

Comment 15

[Victor Porof [:vporof][:vp]]

(In reply to Dão Gottwald [:dao] from comment #14)
> (In reply to Rob Campbell [:rc] (:robcee) from comment #13)
> > Comment on attachment 763786 [details] [diff] [review]
> > proposed patch
> > 
> > regarding. cmd/ctrl-k, go ahead: steal it.
> 
> I don't think that's sound. You'd also need to prevent accel+k from being
> advertised as the search command key in the menu bar, and of course this
> would raise the question of whether it's ok to break accessibility for
> search.

AFAIK, there have been very many requests for having a discoverable and obvious keyboard combo clearing the console output from a number of users, indirectly through feedback or directly at conferences/ talks about our tools etc.

We also recently had lengthy talks about what shortcuts we should choose in our tools, and the consensus was that Chrome's picks generally make sense and are becoming de-facto, or at least very widely known and used, so we should go with them whenever possible and pertinent.

If that's not enough, here's my request too: please let's use accel+k, since I find it the most pertinent shortcut available in the current circumstances, and it's also more widely used than any other shortcut I know.

Customizing this per-platform is another thing we could do, but I don't see it as being of such importance in this particular case.

Comment 16

[Mihai Sucan [:msucan]]

(In reply to Rob Campbell [:rc] (:robcee) from comment #10)
> Comment on attachment 763786 [details] [diff] [review]
> proposed patch
> 
> Review of attachment 763786 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/devtools/webconsole/webconsole.js
> @@ +3809,5 @@
> > +        if (this._autocompletePopupNavigated &&
> > +            this.autocompletePopup.isOpen &&
> > +            this.autocompletePopup.selectedIndex > -1) {
> > +          this.acceptProposedCompletion();
> > +        }
> 
> why is this here?

This is here because what we did in bug 873250 is far from ideal. I played quite a bit with Chrome's Console and their completion menu allows Enter to select the suggestion after you press Up/Down and it makes sense. Much nicer to use that our current approach of always doing eval.

Do you want this removed?

> @@ +3872,5 @@
> > +        if (this.autocompletePopup.isOpen) {
> > +          this.clearCompletion();
> > +        }
> > +        break;
> > +      }
> 
> not strictly necessary for this bug. I'd almost prefer not riffing on
> autocompletion in this bug. It's separate. Not saying it wouldn't improve
> this, I just don't want to think about it in this review.
> 
> @@ +4199,5 @@
> >      this.lastCompletion = { value: null };
> >      this.updateCompleteNode("");
> >      if (this.autocompletePopup.isOpen) {
> >        this.autocompletePopup.hidePopup();
> > +      this._autocompletePopupNavigated = false;
> 
> all of these would go away.

Do you want me to take out the completion changes? As I understood from last week's meeting we are supposed to make keyboard usage nicer, and more consistent with Chrome. Does this make things worse?


(In reply to Rob Campbell [:rc] (:robcee) from comment #13)
> Comment on attachment 763786 [details] [diff] [review]
> proposed patch
> 
> regarding. cmd/ctrl-k, go ahead: steal it.
> 
> as for ctrl-p/n on mac, I don't care either way. I'm not sure many people
> use ctrl-p/n for history navigation or not. Would need more data.

Some people care about this, see bug 804845.

Thank you for the review.

I understand all the worries about changing/adding keyboard shortcuts, but we won't ever be able to satisfy everyone. We have had a lot of requests for a shortcut to jump to the filter field, a shortcut for the clear button and for better consistency with Chrome's web inspector. I believe this patch helps us move closer to those goals.

I wish we had a keyboard shortcuts "master" who we can ask for review and final decision making. :)

I welcome well-thought suggestions for improvements to keyboard accessibility and shortcuts for the web and browser consoles. I would like to see bugs being filed with ideas for solutions to problems like how users can more easily discover shortcuts, how to solve conflicts with existing shortcuts, and how to maintain good enough cross-platform and cross-browser consistency.

Thank you!

Comment 17

[Dão Gottwald [:dao]]

Can you re-summarize why you're hesitant against adding an access key for the clear button, just like the error console's clear button? That it needs to be picked with care to avoid conflicts isn't an argument, that's true for all access keys. That it wouldn't be exposed on Mac doesn't seem convincing either if that's the case for all access keys on Mac.

I'm also curious to hear how you plan to deal with the fact that Accel+K is the advertised key for search in the main menu.

Comment 18

[Mihai Sucan [:msucan]]

(In reply to Dão Gottwald [:dao] from comment #14)
> (In reply to Mihai Sucan [:msucan] from comment #8)
> > > There's the discoverability problem (see above). An access key wouldn't have
> > > that problem.
> > 
> > Yes, but take into account that adding an accesskey to the clear button
> > would steal two shortcuts, not one. One needs to be Ctrl-K or Ctrl-L - since
> > one of these is what is used for the majority of terminals/consoles out
> > there.
> 
> Have there been requests that we should support Ctrl-K/L either for the
> error console or the web console?

Yes, many, as victor pointed out. See Hacker News comments for devtools-related articles (one example), also see bugzilla.

> Can this be handled in a new bug?

There's not much value in splitting a patch for keyboard accessibility improvements into several small bugs where we will discuss every new/changed shortcut.

> This one was really supposed to be about standard, discoverable keyboard
> accessibility rather than special keys developers may or may not expect to
> work.

This bug is about adding shortcuts to functionality in the web and browser console, via access keys or not. I doubt a user would complain that Clear output is Cmd-K like in the majority of devtools out there, but it lacks an access key.

You should also note the target audience here: (web) developers. Things are more discoverable if they are more consistent with other similar tools.

> > This also depends on the language.
> 
> Right, access keys always need to be picked with special care. This isn't a
> new problem.

Cmd-K/L works irrespective of browser's language.


> > Access keys have the disadvantage of being different for every language.
> > Also, they are not discoverable on Macs - no underline.
> 
> Is this true? There's no way to expose access keys on Mac? In that case I'd
> say: just ignore Mac and make the access keys work for other platforms.

I tested on Mac and I saw no underlines. Am I missing something?

This patch makes access keys work for other platforms. The only request I see you have is to also add an access key to the Clear button. Is this correct? I can do that, but I don't see the obvious need when we also have Cmd-K/Ctrl-K.


> > Ctrl-N and Ctrl-P is native on Macs for inputs to move the cursor up and
> > down. The problem is really with MacOSX which chooses to use Ctrl-* for
> > accesskeys and for editing commands in inputs. This is not a jsterm thing.
> 
> Then you should probably use some other access key and document that other
> locales should't pick N or P either?

I'm inclined to kill accesskeys on Mac. These access keys also override other Ctrl-* shortcuts for editing text on Mac.


> (In reply to Rob Campbell [:rc] (:robcee) from comment #13)
> > Comment on attachment 763786 [details] [diff] [review]
> > proposed patch
> > 
> > regarding. cmd/ctrl-k, go ahead: steal it.
> 
> I don't think that's sound. You'd also need to prevent accel+k from being
> advertised as the search command key in the menu bar, and of course this
> would raise the question of whether it's ok to break accessibility for
> search.

This would only happen when the web console is open. Also note the new Cmd-F which breaks find in page - again, for consistency with other devtools (like those in chrome).

We have plans to make Cmd-K and Cmd-F available consistently through out our dev tools, similar to other devtools in other browsers.

Thank you!

Comment 19

[Mihai Sucan [:msucan]]

(In reply to Dão Gottwald [:dao] from comment #17)
> Can you re-summarize why you're hesitant against adding an access key for
> the clear button, just like the error console's clear button? That it needs
> to be picked with care to avoid conflicts isn't an argument, that's true for
> all access keys. That it wouldn't be exposed on Mac doesn't seem convincing
> either if that's the case for all access keys on Mac.

The argument was explained in one of the comments above: we add Cmd-K. Given keyboard shortcuts availability is scarce/really limited, going from no shortcut to clear the output to *two shortcuts* did not seem ideal to me. Maybe I am very wrong, so if you want I will just go ahead and add an access key.

If I am not mistaken, the "a" access key will not work for Macs because that is assigned the Ctrl-A shortcut on Macs, and Ctrl-A is expected to jump to the beginning of the line. I will need to double check.

> I'm also curious to hear how you plan to deal with the fact that Accel+K is
> the advertised key for search in the main menu.

For now, no plan. This is what other devtools do as well. Do you have a suggestion? What can I do here to address the problem?

(thanks for your patience here!)

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Access keys and keyboard shortcuts aren't the same thing, and there's no conflict to having both.

That Mac has a strange access key story also shouldn't really be an important factor, as long as there aren't functional conflicts. I don't know how access keys and text editing shortcuts generally interact on Mac, but if adding an access key doesn't make that conflict any worse (i.e. if the result of adding an "a" access key is that it just doesn't work on Mac), then there's no reason not to add it.

Comment 21

[Dão Gottwald [:dao]]

(In reply to Mihai Sucan [:msucan] from comment #18)
> This bug is about adding shortcuts to functionality in the web and browser
> console, via access keys or not. I doubt a user would complain that Clear
> output is Cmd-K like in the majority of devtools out there, but it lacks an
> access key.

In fact, if Ctrl+K would have worked before, I would have filed the very same bug, because I simply wouldn't have known about it. I'm used to keyboard shortcuts being exposed in the UI somewhere and I'm not used to reading help articles to figure them out, nor am I used to Chrome's dev tools.

> You should also note the target audience here: (web) developers. Things are
> more discoverable if they are more consistent with other similar tools.

Relying on other tools to familiarize users with keyboard shortcuts is poor UI. Note that when we've added keys for consistency with other tools in the past, we've either exposed them directly or added them in addition to the ones we expose (e.g. Ctrl+e for search for consistency with IE). An unexposed key alone isn't a complete accessibility story.

> > Right, access keys always need to be picked with special care. This isn't a
> > new problem.
> 
> Cmd-K/L works irrespective of browser's language.

Great, but I was responding to your concern that there could be conflicts with access keys. This obviously hasn't stopped us from adding other access keys and the clear button isn't special in this regard.

> I tested on Mac and I saw no underlines. Am I missing something?

Did you enable Full Keyboard Access?

> This patch makes access keys work for other platforms. The only request I
> see you have is to also add an access key to the Clear button. Is this
> correct? I can do that, but I don't see the obvious need when we also have
> Cmd-K/Ctrl-K.

I'm asking for something discoverable that doesn't require that I've used Chrome or some other tool before.

(In reply to Mihai Sucan [:msucan] from comment #19)
> If I am not mistaken, the "a" access key will not work for Macs because that
> is assigned the Ctrl-A shortcut on Macs, and Ctrl-A is expected to jump to
> the beginning of the line. I will need to double check.

If "a" doesn't work, this would leave you with "r" -- or some other random key, because access keys don't actually need to be part of the label.

> > I'm also curious to hear how you plan to deal with the fact that Accel+K is
> > the advertised key for search in the main menu.
> 
> For now, no plan. This is what other devtools do as well. Do you have a
> suggestion? What can I do here to address the problem?

I see no solution to this other than picking keys that don't conflict...

Comment 22

[Mihai Sucan [:msucan]]

(In reply to Dão Gottwald [:dao] from comment #21)
> > I tested on Mac and I saw no underlines. Am I missing something?
> 
> Did you enable Full Keyboard Access?

As far as I know, I did enable keyboard accessibility - eg. I see shortcuts in the menus. Where do I enable the Full Keyboard Access option? So I can double check.

> If "a" doesn't work, this would leave you with "r" -- or some other random
> key, because access keys don't actually need to be part of the label.

I will add an access key for the button as well.

Thank you!

Comment 23

[:Gavin Sharp [email: [e-mail]]]

Access keys just aren't discoverable on Mac, I don't think the Full Keyboard Access preference affects that in any way.

Comment 24

[Mihai Sucan [:msucan]]

Attachment: updated patch

Updated the patch to include an access key or the Clear button. The access key I picked is "r": "C" is taken by CSS, "l" is taken by Logging, "e" is used for the Edit menu, "a" is used by "jump to start of line" on Macs. "r" seemed free.

I added an ifdef for the Net button. I picked "N" as the access key for Windows and Linux, because it seemed available. On Macs "N" is not available as explained in previous comments, so I changed it to "t" which is available. "t" is not available on Windows and Linux: it is used by the Tools menu.

I'm keeping Cmd/Ctrl-K and Cmd/Ctrl-F for clear output and for focusing the filter input, until there's a better solution proposed.

All tests pass for me on Linux and Windows.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=19051dc100fe

If results will be positive I will land those patches in fx-team. Thank you!

Comment 25

[Mihai Sucan [:msucan]]

Previous try push was based on fx-team with oranges.

New green try push: https://tbpl.mozilla.org/?tree=Try&rev=0daeb0a45496

Comment 26

[Mihai Sucan [:msucan]]

Landed: https://hg.mozilla.org/integration/fx-team/rev/6d5d454fc9b1

Comment 27

[Victor Porof [:vporof][:vp]]

https://hg.mozilla.org/mozilla-central/rev/6d5d454fc9b1

Comment 28

[Ioana (away)]

Verified as fixed on Firefox 24 beta 7, on Windows 7, Ubuntu 13.04 and Mac OS X 10.7.5.

The following keyboard combinations work fine:
Ctrl/Cmd + K, Ctrl/Cmd + F, Alt/Ctrl + R/N/T/C/J/S/L.

Space, Enter and Tab display the following issues:
1. When focusing a log entry and pressing Enter, nothing happens. I would expect to see the following:
** the Inspect Network Request when something like this was focused: [14:43:31.548] GET http://fls-na.amazon.com/1/ba... [0ms]
** ag.hp.js (scrolled to line 15 if possible)
[14:33:55.893] "[Weather.Service] Request: Getting data for 10108"  ag.hp.js:15

2. When focusing "Log request and response bodies" from the Net menu and pressing Enter nothing happens. When doing this with any other menu item, it gets checked or unchecked.

3. On Windows and Ubuntu, Tab goes through the following in this order: Net, CSS, JS, Security, Logging, Clear, Input at the end of the dialog, logs, Filter. On Mac it goes: input at the end of the dialog, logs, Filter. When I focus one of the other items and I press Tab, the focus changes to nothing, then following Tab presses lead to input at the end of the dialog, logs, Filter. I'm not sure if nothing is correct here, but there is no item displayed as focused and nothing happens if I press Enter or Space.

4. When the Clear button is focused and I press Space, the button is pressed. When Net (or any other of the buttons with menus) is focused and I press Space, the menu is opened. When focus a menu item and pressing Space, nothing happens.

I would expect Space to work on the other buttons the same as on the Clear button: press the button, not the dropdown arrow.

If you prefer to keep it working like Enter and open the menu, then it should work like Enter when a menu item is focused too (check/uncheck it).

Before filing new bugs for these issues, I need to know which of them are by design and perhaps a reasoning that lead to that design.

Comment 29

[Mihai Sucan [:msucan]]

Thank you Ioana for verifying this bug fix and for the added details.


(In reply to Ioana Budnar, QA [:ioana] from comment #28)
> Verified as fixed on Firefox 24 beta 7, on Windows 7, Ubuntu 13.04 and Mac
> OS X 10.7.5.
> 
> The following keyboard combinations work fine:
> Ctrl/Cmd + K, Ctrl/Cmd + F, Alt/Ctrl + R/N/T/C/J/S/L.
> 
> Space, Enter and Tab display the following issues:
> 1. When focusing a log entry and pressing Enter, nothing happens. I would
> expect to see the following:
> ** the Inspect Network Request when something like this was focused:
> [14:43:31.548] GET http://fls-na.amazon.com/1/ba... [0ms]
> ** ag.hp.js (scrolled to line 15 if possible)
> [14:33:55.893] "[Weather.Service] Request: Getting data for 10108" 
> ag.hp.js:15

We have some bugs open about problems with keyboard accessibility, for example bug 588010. Once the patches from bug 760876 land you will be able to Tab to any link in the console output, and you can press Enter to perform the link action - same as click.


> 2. When focusing "Log request and response bodies" from the Net menu and
> pressing Enter nothing happens. When doing this with any other menu item, it
> gets checked or unchecked.

This might be a web console bug. Please file a bug so we can investigate.

> 3. On Windows and Ubuntu, Tab goes through the following in this order: Net,
> CSS, JS, Security, Logging, Clear, Input at the end of the dialog, logs,
> Filter. On Mac it goes: input at the end of the dialog, logs, Filter. When I
> focus one of the other items and I press Tab, the focus changes to nothing,
> then following Tab presses lead to input at the end of the dialog, logs,
> Filter. I'm not sure if nothing is correct here, but there is no item
> displayed as focused and nothing happens if I press Enter or Space.

This seems to be platform-specific and Gecko-related. The Web Console does not include any platform-specific logic for handling Tab order or how input and focus work.


> 4. When the Clear button is focused and I press Space, the button is
> pressed. When Net (or any other of the buttons with menus) is focused and I
> press Space, the menu is opened. When focus a menu item and pressing Space,
> nothing happens.
> 
> I would expect Space to work on the other buttons the same as on the Clear
> button: press the button, not the dropdown arrow.
> 
> If you prefer to keep it working like Enter and open the menu, then it
> should work like Enter when a menu item is focused too (check/uncheck it).

These seem to be related to how the XUL elements work - not webconsole-specific bugs.

> Before filing new bugs for these issues, I need to know which of them are by
> design and perhaps a reasoning that lead to that design.

Please file a bug for point 2. Point 1 is known. As for points 3 and 4 they seem to be valid issues, but I am not sure how we can fix them in the web console UI. Thank you!

Comment 30

[Ioana (away)]

(In reply to Mihai Sucan [:msucan] from comment #29)
> Please file a bug for point 2. Point 1 is known. As for points 3 and 4 they
> seem to be valid issues, but I am not sure how we can fix them in the web
> console UI. Thank you!

Thanks for all the information! I filed bug 915141, bug 915152 and bug 915155.