269766 - Conflicting shortcuts: Ctrl+Enter has two meanings

Status: RESOLVED WONTFIX

(Toolkit :: Find Toolbar, defect, P2)

Description

[Timwi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.998
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.998

In Firefox 0.9, it was possible to type the text of a link and then press
Ctrl+Enter to open it in a new tab.

In Firefox 1.0, this sometimes still works, but sometimes it randomly decides
that Ctrl+Enter should mean "Highlight" (the button on the new Find toolbar). I
couldn't come up with a pattern when it chooses which. Annoyingly, whenever it
chose that it should mean "Highlight", it subsequently uses that meaning of
Ctrl+Enter in the same tab, which means it is now impossible to open the link in
a new tab without the mouse.

Reproducible: Sometimes
Steps to Reproduce:

Comment 1

[Matthias Versen [:Matti]]

alt+Tab is for opening a new Tab in 1.0..

Comment 2

[Phil Ringnalda (:philor)]

No, that's (ctrl|alt)-tab to open a new blank tab, a very different thing. This
is type a URL in the addressbar, but use ctrl-enter to open in a new tab rather
than enter to open in the current tab. It's probably a dup of one of the
"suddenly typing gets routed to the findbar instead of the page" bugs, but
they're a tangled lot, so I'm not sure which one.

Comment 3

[Phil Ringnalda (:philor)]

But no matter what, it's not the Accessibility component, since it's Find
Toolbar stealing the keyboard input.

Comment 4

[Timwi]

No, I am not talking about typing in the address bar; I'm talking about Find
Links As You Type within a webpage.

It's also not *only* a problem of the Find toolbar stealing focus; Ctrl+Enter
still has two conflicting meanings.

Comment 5

[Aaron Leventhal]

The other problem with Ctrl+Enter for highlight is that it's undiscoverable.
Let's rename it "Highlight all" and underline the a so it's Highlight _a_ll ?
Then people would no it's there. We did something similar for Match _c_ase.

Comment 6

[Aaron Leventhal]

Related to bug 280159 and bug 264349. All three would be fixed by using Hilight
_a_ll.

Comment 7

[Nickolay_Ponomarev]

*** Bug 288899 has been marked as a duplicate of this bug. ***

Comment 8

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

Using Alt+A now works (bug 280159), while Ctrl+Enter was left for compatibility (bug 294609). That doesn't really fix the inconsistency, but at least there is now an alternative.

Comment 9

[Mike Connor [:mconnor]]

This is as good as it gets.

Comment 10

[Timwi]

This is not acceptable; you can't have the same keyboard shortcut map to two different functions when the same window is visible. Basic UI design principle. Reopening.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't think so. All keys (and key combinations) are should be overridable by focused widget. In this case, if an anchor element has focus, the anchor element works the 'Ctrl + Enter' as 'open link in new tab'. If the editor of Find Toolbar has focus, it works 'Ctrl + Enter' as 'Hilight'. I think that this is clear.

Comment 12

[Timwi]

It is certainly not clear to non-technical users, especially in a situation such as this where the focus is actually a relatively insignificant detail. The user can type characters to find links, independent of whether the Find Toolbar has focus or not. All that counts is that it's visible, so users do not expect (and should not have to expect) that the behaviour of some shortcut changes so radically depending on this unnoticeable detail.

Besides, it is not necessary to have conflicting shortcuts. It is obviously possible to just change Highlight's shortcut away from Ctrl+Enter, and the problem is solved.

Comment 13

[Mike Connor [:mconnor]]

*-Enter does different things depending on find invocation, not just Ctrl-Enter, and the user will know how they're invoking Find.  FAYT is an advanced behaviour that has to be enabled, so I'm not concerned with a longstanding but minor inconsistency.  Changing the shortcut that the majority of users will have adapted to will cause more problems than the inconsistency has caused to date.  We've shipped this in two major releases, and the feedback has been negligible.

You're free to disagree, but you're not free to overrule me if you don't like my choice.