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

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.

Bug 14027 is the same bug for Seamonkey.

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).

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.

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

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.

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.

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?

(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.

OK, this makes gavin's suggested change.

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.

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.

Why not simple? Open: %S Open in new window: %S Open in new tab: %S

Are there any plans to add this feature to 2.0? Its not in beta 1, I see :(

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

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.

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.

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...

(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.

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

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