Enter key shortcut is activating unintentionally about brief

[Keith94]

I just noticed this issue has already been reported on mozdev’s bugzilla here. But will this ever get fixed?

[tanriol]

@ancestorak, why at all do we need to listen for key events in the XUL overlay instead of doing the same in the Brief tab? Are the events we need not available at that moment?
Actually, it seems to be not a very nice idea as this makes the Brief tab a "magic" one that may behave unlike any other tab. Do we really need that?

[ancestorak]

The motivation is that the Brief's tab can lose focus even though it is selected, preventing shortcuts from working. It forces the user to click within the tab to refocus it. It is annoying at best and makes Brief seem broken at worst, if the user isn't familiar with the concept of focus.

Of course, it is a problem with all websites, but for them it is a necessary inconvenience because they are untrusted and the browser obviously cannot let random websites access chrome events. This doesn't mean that Brief, which is a privileged application, must share this deficiency.

However, Brief should indeed be more careful about overloading keys that are used by the chrome window, such as Enter and possibly Space. I believe the right way to fix this bug is to carry out actions associated with those keys only if Brief's tab is indeed focused. This shouldn't be too hard.

[tanriol]

If we treat Brief as a privileged application, probably we should make it more noticeable. Right now it looks like an ordinary tab and may be treated as such almost in every case... for me it's a pinned tab just like Gmail or several other webapps.

If the actions are carried out only when Brief's tab is focused, we return to the standard configuration. What's the difference in this case?

[ancestorak]

If we treat Brief as a privileged application, probably we should make it more noticeable. Right now it looks like an ordinary tab and may be treated as such almost in every case... for me it's a pinned tab just like Gmail or several other webapps.

The goal is to make it just work™, so that the user doesn't have to think about such technical distinctions - which most users don't even understand anyway.

If the actions are carried out only when Brief's tab is focused, we return to the standard configuration. What's the difference in this case?

The difference would be that it would affect just the one or two problematic keys, instead of all of them.

[tanriol]

I've moved the listeners into the Brief tab as a part of migrating to XUL-less Brief. Fixed.

[Keith94]

Cool. :)