Closed Bug 161955 Opened 22 years ago Closed 22 years ago

RFE: When link is focused, Accel+T to open link in new tab, Accel+N to open link in new window

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: aaronlev, Assigned: aaronlev)

Details

(Whiteboard: WONTFIX?) 

I would like to change the behavior of Accel+T and Accel+N when a link is
focused, so that it opens the new tab or new page with the page pointed to by
the current link.

For one thing, this would make type ahead find for links much more useful (see
bug 30088).

What do people think?
Why? You can open a focused link in a new tab/window by pressing Ctrl+Enter.
You have to find and set a pref to get Ctrl+Enter to open in a new tab, which
means you have to know about the pref.

Also, Ctrl+Enter is only 1 key, and there are 2 things people want to do. Some
people want to be able to choose. Also, having explicit keystrokes for each
command makes it easier to document.

Finally, Ctrl+Enter is not mnemomnic and hard to remember. People already know
Accel+T and Accel+N might discover this.

I think this would be very nice and still be consistent. Do you disagree?

Let me throw it back at you - why not?
because the keys mean _*new* <foo>_ not _/open/ <bar> in new <foo>_
Exactly.  There are many times I have a link in focus but want to open a new
window or tab.  The behavior of these shortcut keys shouldn't vary depending on
whether a link's focused.
Well it doesn't sound popular at this point :)
What if it only uses the current link if they are type ahead find mode. In
otherwords, they got to this link by typing characteres, and typeaheadfind
hasn't timed out yet?

So the user could type "rea" Accel+T to open the "read more" link in a new tab.
> You have to find and set a pref to get Ctrl+Enter to open in a new tab, which
> means you have to know about the pref.

If you are enough of a poweruser to want separate keystrokes for opening a link
in a new tab and window, you most likely already know about that pref.

> Also, Ctrl+Enter is only 1 key, and there are 2 things people want to do. Some
> people want to be able to choose.

On Windows (I don't know about other operating systems) you can open the context
menu (from where you can choose open in new tab/window) using the key between
the right ctrl and the right windows key. I use that whenever I want to open a
focused link in a new window using the keyboard (I have ctrl+enter set to open a
new tab).

> Well it doesn't sound popular at this point :)

Indeed :-)
how about accel-space and accel-shift-space? (i can't think of accel space doing
anything interesting or useful in any app)
> What if it only uses the current link if they are type ahead find mode.

That would be very, very inconsistent. I'd rather Ctrl+T/N always opened the
link in a new window or tab than have it only happen in you are in ahead find mode.
Won't alt-enter open the focused link in a new tab/window, at least if you have
the pref that alt-enter in the urlbar opens in a new tab/window?  If not, it should.

Making accel-T/accel-N sounds fine to me.  The only objection I can see is that
it does mean that if a link is focused and you really want a blank or homepage
window, you'd have to go through some gyrations to get the focus away from a
link.  But that's probably not a common problem, and one can always hit stop in
the new tab/window.
> Won't alt-enter open the focused link in a new tab/window

Uh, make that ctrl-enter.
I'm inclined to think that changing the meaning of something as basic as
accel-N based on focus (something which, as a developer myself, I know many
users have trouble with) is a Bad Thing.

Often I want to double-check something (in a separate window) before I submit
a form; if I happened to be on the submit button and pressed accel-N and Mozilla
submitted the form instead of simply opening a blank window, I would probably be
pretty {frustrated,angry,...} until somebody explained to me why accel-N wasn't
(always) New Window -- I'd probably file a bug report on that, too.
You've got the totally wrong idea, I don't know how you thought Accel+N could
submit!
With this RFE, Accel+N would still open a new window, it would just use a
different starting page if you were on a link.
Perhaps this would only happen if they used type ahead find to get to the link.
> I don't know how you thought Accel+N could submit!

I think he meant that it would submit the form in a new window (not current
possible; bug 17754).

> With this RFE, Accel+N would still open a new window, it would just use a
> different starting page if you were on a link.

Maybe you've already hit submit, and you are now staring at a confirmation page.
That page has no buttons -- instead, it has a link to a page that will activate
whatever changes you submitted in the form. You tab to that link, then decide to
double-check your changes before following the link, so you press Ctrl+N to get
a new window...
What if a <meta> were put in front of <accel>-T and <accel>-N?  Would it be OK
then?  Would that still work for accessibility?
This is (IMHO) a bad idea. Let's not make our accelerators unpredictable. They
should consistently do the same thing, always (within that app -- Mail and
Browser are not the same app, of course).
Whiteboard: WONTFIX?
Too unpopular!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
right-o
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.