122989 - form controls block keyboard shortcuts

Status: VERIFIED DUPLICATE of bug 119696

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Iuri Fiedoruk]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.8+) Gecko/20020129
BuildID:    2002012921

Ok, there you are, happily using mozilla, then you decide to open a new tab,
press ctrl+t and... nothing! try ctrl+n to open a new window and ... nothing.
Sometimes happens, sometimes don't.

Reproducible: Sometimes
Steps to Reproduce:
1.navigate and keep trying to use hotkeys
2.
3.

Actual Results:  sometimes hotkeys stops working, works again after a while, or
only when restarting mozilla

Expected Results:  the combination keys should work everytime

Comment 1

[Peter Trudelle]

we need steps to reproduce in order to do anything with this.

Comment 2

[gavin long]

Reporter, can you have a read of the rather cryptically-summarised bug 76495
(specifically comment 67, which summarises the problem wrt to keystrokes), and
let us know if that's the problem you're seeing?

Comment 3

[Iuri Fiedoruk]

Nops, dosen't seem to be the same.
About steps to reproduce... well I simply use mozilla for a long time and sometimes 
combination keys don't work, so I have to start it again.
Just now when writing this, I found something very interesting!
I can't use ctrl+n when focus is in this textarea.
So maybe, the problem happens with pages that have a javascript that sends the
focus to some form and then key combinations stop?
If so, I think ctrl+n should keep working even when your focus is on a textarea.
Ctrl+T seems to be workin, but ctrl+h and other keys dosen't.
Hope this new info helps :)

Comment 4

[Peter Trudelle]

->bryner

Comment 5

[Diego Biurrun]

Does it happen when you are typing in a textarea?  Hotkeys are disabled then. 
It may also be that you have a form control or something selected, hotkeys do
not work then either.
Please try the following:  The next time your hotkeys stop working, click into
the page content so as to unselect any textareas or form controls.  Does this
solve your problem?

Comment 6

[Iuri Fiedoruk]

Yes, this solves the problem.
But wait! Don't close the bug :)

I think it should not behave this way. Keys should not stop when the focus is on
a form!

Comment 7

[Diego Biurrun]

Resummarising the bug, now that we know what the problem is, and over to
keyboard navigation.

Textareas block keyboard shortcuts because of the handy emacs bindings.  You can
make Alt the accel key to work around this.

Comment 8

[Aaron Leventhal]

-> akkana

Comment 9

[Akkana Peck]

This is the way it's supposed to work -- the lowest level widget (e.g. the form
control) takes precedence.  So for the conflict between text control bindings
and xul bindings I'd say wontfix.  I wish our window-level bindings or our
default accel key had been chosen to avoid conflicts, and I lobbied strongly for
that, but they weren't.

This isn't strictly a text field binding specific issue, though -- ^T (the first
case reported in this bug) isn't an emacs binding.  In fact, I don't see it
anywhere in unix/platformHTMLBindings.xml or htmlBindings.xml.  I don't know
where that binding is defined -- Aaron, do you know?

Back to Aaron for that part.

Comment 10

[Diego Biurrun]

Akkana, can you elaborate on this?  I can understand that textfields might block
some keystrokes because of emacs bindings, but why should form controls do
that??  Why would I want to press C-w or C-n on a dropdown list?

Comment 11

[Akkana Peck]

Actually, I'm not sure what the key bindings are for non-text form controls or
where they're defined; I just know there are some.  Maybe aaron knows more about
that.  Maybe ^T is a binding on some non-text form control.

Comment 12

[Martin Macok]

Isn't bug 119696 a special case of this? Or is this a dupe of it?
Same with bug 128995.

And I hope this is on topic on this bug:

When I open a new tab (^t) and load a page in it, very often while the page is
loading (looks like waiting for dns reply or tcp reply), I cannot use shortcut
keys (like ^w, ctrl+pg_up, ^n). I must swith to different tab by mouse to make
mozilla responding to shortcuts again.

Comment 13

[Diego Biurrun]

Martin, what you are seeing are bug 76495 (not being able to interact with a
loading page) and bug 37638 (the URL bar has focus and therefore key bindings do
not work).
This bug is a dupe, I will mark it as such now.

Comment 14

[Diego Biurrun]

Why the heck didn't I mark this as dupe right away?  People are strange ...

*** This bug has been marked as a duplicate of 119696 ***

Comment 15

[:deanis74]

v