Comment 1 by jteh on 2014-09-24 04:01
Disallowing any key that is not a quick navigation key in browse mode would be extremely unwise. This would include alt+tab, the applications key to open a context menu, control+enter to open a link in a new tab, menu keys, other command keys, etc. Having a list of exceptions is unacceptable, since we can't know every command a user might wish to use.
Changes:
Added labels: wontfix
State: closed

Comment 2 by blindbhavya (in reply to comment 1) on 2014-09-24 10:02
Replying to jteh:

Disallowing any key that is not a quick navigation key in browse mode would be extremely unwise. This would include alt+tab, the applications key to open a context menu, control+enter to open a link in a new tab, menu keys, other command keys, etc.

Ok, fair enough.
Having a list of exceptions is unacceptable, since we can't know every command a user might wish to use.
I am not sure why it is not possible. Alphabet keys such as a, p, y, z and a few others are not quick navigation keys , so why would the user want them to be allowed and entered in the edit box? Please clarify. Am I missing something here?

Comment 3 by jteh on 2014-09-24 10:46
I meant a list of exceptions for all possible keys, not just alphabetic keys. We can't know every possible command key a user would use; e.g. alt+tab, control+enter, control+t, control+tab, alt+f, etc.

As to a list of exceptions for alphabetic keys, why should alphabetic keys be special?

Comment 4 by briang1 on 2014-09-24 13:41
Actually this ticket explains the issues I had with the lack of indication of mode if the next element is the same, as the last one. Thus, with a little distraction, it is indeed easy to be in an edit area, be in browse mode but think its focus mode and typ a word, then the minute you hit a defined shrt command key you go whizzing off to another bit of the page entirely. This is with automatic mode change on etc, of course.
So there could be some mileage in some form of protection from this.
My vote would be for the mode to be always announced on changes in the automatic mode, persoanlly.

Comment 5 by jteh on 2014-11-05 11:43
I'm still not sure of the exact solution here, but comments sparked as a result of quick nav in Word (#2975) suggest that this is important to users.
Changes:
Removed labels: wontfix
State: reopened

I am not able to reproduce this using the comment box on this issue for an example. When in browse mode and I press, Z, Y, P, or any punctuation/symbols, Windows makes an error tone and the key is not passed to the application. Closing, but if someone can reproduce and provide an STR, this can be reopened. Closing