279223 - "Open link in new window" in status bar

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, enhancement, P5)

Description

[zupi]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When I hover a link with the mouse pointer, the status bar normally displays the
URL the link points to, e.g. "http://www.mozilla.org". But it doesn't give any
information whether the link opens in the current window/frame or in a new window.

What about status bar messages like:
> Open "http://www.mozilla.org"
and
> Open "http://www.mozilla.org" in a new window
?

Inspired by Safari on Mac OS X. But still prefering Firefox :-)
Greets from Germany!

Reproducible: Always

Comment 1

[Bruce Davidson]

I'm surprised but a thorough sweep for dupes doesn't reveal an existing request
for this. Bug 268984 is asking for effectively the same feature, but presented
in a different way. I'm not going to dupe one against the other, but if one ever
gets implemented we may want to wontfix the other.

See also bug 257600 for Camino; fixing this bug in Gecko would make that one
easier for us.

Comment 2

[Jesse Ruderman]

Bug 14027 is the same bug for Seamonkey.

Comment 3

[Ihar 'Philips' Filipau]

Also, cool feature found in Safari, is when you press modifier keys (Alt, Ctrl, Shift) which affect the way link open, status bar also changes.

E.g. while hovering on link Safari would set status bar to some thing like "Open http://whatever.com in this window". If you would press Cmd/Ctrl - standard modifier to force link to open in tab - status would reflect that by changing text to "Open http://whatever.com in tab beneath current one". ("beneath current" is displayed in my case to reflect that I have option set to open new tabs in background).

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Would be a nice bit of polish and probably a good first bug for someone if we can get it for Bon Echo Beta 1.

Comment 5

[Mike Connor [:mconnor]]

Nice to have, but not a blocker.  Would be glad to take a patch though.

Comment 6

[Peter Kasting]

Attachment: first cut

Here's a first cut.  This patch will make the browser say "Open <url> [in new window|tab]".

Known problems:
* I assume a link opens a new window if it has a non-empty target.  This isn't really true, but I wasn't convinced doing a straight check against "_blank" was good either.  I suppose the accurate way would be to try and somehow check whether the target exists.  If it does, we could say "in another window" or something.  In fact, maybe that language is vague enough to just use now.
* I don't check the user's modifier keys.  There's no DOM event here, so instead I'd need to install key listeners and keep track of the key state.  If I did that, then I could probably update the link status on the fly, so if you pressed the ctrl key repeatedly you'd see the status change as appropriate.
* I don't do anything super-sophisticated, like catch crazy javascript actions that would pop open windows or whatever.
* Putting "in new xxx" after the end of the URL is often very hard to notice.

I don't know if this patch is even good enough to be helpful, so I haven't requested review.  It might be nice to get some input from others.

Darin suggested that a lot of link-handling stuff could be completely redone to not go through nsWebShell.cpp, but to just directly use mouse and keyboard listeners in browser.js.  That might make fixing this right easier.  I'm not sure I want to tackle it.

Comment 7

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

Instead of a prefix and suffix, this should just use "Open %S in a new tab" and "Open %S in a new window" with getFormattedString instead of getString. This makes it easier for localizers to understand what they're translating, and makes it easier to deal with languages where the word order may be different.

Comment 8

[Peter Kasting]

That doesn't seem like much of a win, since in most cases we won't be opening in a new window OR a new tab, and I want it to just say "Open %S".

Or do you think we shouldn't change the status bar behavior for "normal" links, and just leave them as raw URLs without action words?

Comment 9

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

(In reply to comment #8)
> That doesn't seem like much of a win, since in most cases we won't be opening
> in a new window OR a new tab, and I want it to just say "Open %S".

So have "Open %S", "Open %S in a new tab", and "Open %S in a new window" strings, then. I'm not commenting on which strings you should be using when, I'm commenting on the method you're using to read and display the localized strings.

Comment 10

[Peter Kasting]

Attachment: Use getFormattedString

OK, this makes gavin's suggested change.

Comment 11

[Ian Pottinger]

I think it would be more useful if the action text consistently appeared in the same location, in this case the beginning of the line. Hence:

New Window: %S
New Tab: %S
Goto: %S

"Goto:" is for links that open in the same tab or the same tab-less window. Having the action text at the begining also avoids the problem of long URLs pushing the text off screen and provides one consistent spot at which to glance. Optionally, you could precede the action text with an easily distinguished icons for even quicker recognition.

Comment 12

[Peter Kasting]

Presenting the location before the URL definitely solves the "hard to notice" problem better, but "Goto" is clunky.  Maybe "Same Tab:", but that feels clunky as well.

There's an existing bug (somewhere) on modifying the mouse cursor over links for new tabs/new windows, which might be better UI than an icon in the status bar, though I'm not sure.  I don't know whether that bug is exclusive with or complimentary to this bug as things stand.

Comment 13

[zupi]

Why not simple?

Open: %S
Open in new window: %S
Open in new tab: %S

Comment 14

[zupi]

Are there any plans to add this feature to 2.0?

Its not in beta 1, I see :(

Comment 15

[Peter Kasting]

No.  My patch is not good enough, and there's no one (including me) with time to really nail this.  Also this isn't the sort of feature which would be accepted at this point in the game, even if we did have a fantastic patch.

It's keyworded helpwanted, so if you know of anyone who's like this in, please try and convince them to work on it :D

Comment 17

[Dick Guertin]

Read 384613.  It covers TWO tab situation caused by target="_blank" AND the user holding down a Command modifier key that also would "Open in a new tab".  There also is discussion of Download, which hasn't been mentioned so far.

Comment 18

[Jesse Ruderman]

The "TWO tab situation" is a separate bug that will not be fixed by improving the status bar text.  Please file it with a simple testcase and steps to reproduce.

Comment 19

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

If a link opens in the same tab the best option could be to mantain the old behaviour and show only the address without comments:

New Window: %S
New Tab: %S
%S 

to avoid "jumping" of adrresses could be used

%S opens in new window
%S opens in new tab
%S

but this does not solve problem with long addresses...

Comment 20

[Dick Guertin]

(In reply to comment #18)
> The "TWO tab situation" is a separate bug that will not be fixed by improving
> the status bar text.  Please file it with a simple testcase and steps to
> reproduce.
> 
I would NOT hold down a modifier key if I knew the link would open in a new tab, and that's the "improvement".  This would avoid the TWO tabs problem.  However, I will also file this as a "bug", not an enhancement.

Comment 21

[Dick Guertin]

I submitted Bug 384924 concerning TWO TABS.  I still believe having the Status Bar indicate things just like Safari would be a welcomed improvement.

Comment 22

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 23

[:Gijs (he/him)]

Safari stopped doing this, as far as I can tell.

We cannot reliably predict the target of the URL so that is already best effort, and it's even worse for where the link opens (e.g. click handlers that call window.open(..., "_blank") and cancels navigation in the same tab). After product+UX discussion, the decision was not to go ahead with this.