Open Bug 14027 Opened 25 years ago Updated 8 months ago

Indicate whether a link will open in a new window

Categories

(Core :: DOM: Navigation, enhancement, P3)

Product:
Core
Component:
DOM: Navigation
Type:
enhancement

Tracking

()

People

(Reporter: Crysgem, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted)

Attachments

(1 file, 3 obsolete files)

Solution study for cursor changing
972 bytes, patch
Details | Diff | Splinter Review
When passing the cursor over a link, it's URL (web-centric) will be displayed in the status bar. If the document is to be loaded in a new window, Mozilla should inform the user by that same expedient.
Target Milestone: M14
Move to M20.
QA Contact: leger → paulmac
Updating QA Contact.
Showing that a link will open in a new window would be better indicated by using a dotted underline for the link, than by status bar text. Reasons: (1) We don't check the status bar every time we're about to click on a link. So people won't notice the feature. We do, however, always look at the link, so it makes sense to alter the appearance of the link instead. (2) Many URLs nowadays are longer than the status bar, and any `(will open in new window)' text after the URL would be invisible in these cases. (3) Using a dotted underline would be consistent with Windows Help (and probably a few other hypertext systems too). (4) A dotted underline would be easier to implement, using CSS, than this suggestion -- about five minutes of editing the base style sheet. It also wouldn't need to be localized.
QA Contact: paulmac → claudius
>Showing that a link will open in a new window would be better indicated by >using a dotted underline for the link, than by status bar text. What about links that call window.open from href or from onclick? Website authors trying to implement something similar to pop-up definitions in windows help are likely to use javascript to pop up new windows, and mozilla won't be able to recognize the link as a "new window" link. This should be suggested to the people who make the web standards, so that it can be implemented in all browsers and all webpages consistantly.
`Suggesting it to the people who make the Web standards' won't fix the problem of Mozilla not immediately being able to tell whether an onClick is going to open a new window. But that onClick problem already exists with everything, not just links. This is an enhancement just for ordinary links, so that if the link has a target which starts with "_" and which is not "_top", a dotted underline is used to highlight it.
Move to "Future" milestone.
Target Milestone: M20 → Future
I'm attaching two patches to html.css to implement this for <A> links with target="_blank": 1. Uses a 1px border below the existing underline (to achieve a double underline effect) 2. Uses a 2px dotted border I also think that in addition to a different hyperlink design, there should be a small icon on the status bar that displays a different icon based on such things as: - Link Target: New window, frame, internal document anchor, onsite (same domain), offsite - Link Protocol: javascript, mailto, http, ftp, file, finger, etc.
Attached patch Double underline for <A> links (obsolete) — — Splinter Review
Attached patch Dotted underline for <A> links (obsolete) — — Splinter Review
Good work Tim, but three obvious things need fixing with that last patch. (1) You're using a border, when ideally you should be using an underline. (1a) The color doesn't match the link color (you know about that already). (1b) The distance between the text and the `underline' is dependent on the padding and padding-bottom properties of the element, when it shouldn't be. Fixing this requires the implementation of a new Moz-specific underline type. File a bug, if it doesn't exist already. (2) It won't work for target="foo", and the user will be expecting it to work for *any* window other than the current one. (I don't see how this can be fixed easily.) (3) It won't work for links without their own TARGET, in a document which has <base target="_blank" /> or whatever. (This could be fixed with a CSS selector, albeit a rather complicated one.)
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Bringing in iCab again: It indicates 'opening in a new window' by changing the cursor (pointer hand) to a pointer hand with two pieces of paper attached. So the user sees that the page will open in a new window but it doesn't change the style of a page as long as he is not intending to click a link. Some pages would really look strange if most links where underlined dotted. Authors will complain... Needed something like {-moz-cursor:newpage} In iCab this even works when the user forces 'new window' by pressing the command key (on the Mac, I guess controll-click is used in Windows to open a link in a new window).
If new-window links didn't look quite as beautiful as same-window links, and authors were encouraged to make fewer of their links open in new windows as a result, that would be no bad thing ... <http://www.useit.com/alertbox/990530.html>
*** Bug 69646 has been marked as a duplicate of this bug. ***
Taking this to see what I can do, but a foolproof algorithm for what will and won't open in a new window will be difficult.
Assignee: vishy → blakeross
Could you make this a box that contains an icon and a text description? (arrow going NE out of a window) [ms uses something like that on its web pages.] Then userChrome.css can style one invisible (by default make the icon invisible)
Generalizing summary until an appropriate implementation is worked out.
Component: Browser-General → HTML Element
Summary: [RFE] Status bar should display "Will open in New window" beside URL → [RFE] Indicate whether a link will open in a new window
*** Bug 76337 has been marked as a duplicate of this bug. ***
For future reference, the CSS rule we want is: a[href][target]:not([target="_self"]), link[href][target]:not([target="_self"]) { ... } We include LINK on the off-chance that the author styles LINK to make it visible. We don't include the equivalent selector for AREA, because that would make image maps look rather ugly (we don't usually give them a border); however, it should be included for a rule which changes the cursor rather than changing the border. [Marking dependency on the (fixed) bug 71647 at Daniel Glazman's request.]
Depends on: 71647
If indicating internal anchors distinctly is also fixed as part of this bug, the rule for *that* is: a[href^='#'], link[href^='#'] { ... } This won't handle the case where foo.html links to "foo.html#bar", but we can't do that without a new :-moz-local pseudo-selector, and I doubt that it's at all common on the Web. The other problem is that neither of these rules will work where TARGET is specified by the BASE element, because (contrary to what I said on 2000-07-19) BASE TARGET can't be selected for using current CSS selectors.
*** Bug 83252 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
SPAM. HTML Element component is deprecated, changing to Layout component. See bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
Attachment #11559 - Attachment is obsolete: true
Attachment #11560 - Attachment is obsolete: true
FYI - my suggestion (dupe bug 76337) never got discussed here, so I wanted to re-mention it. Instead of changing the link underline, I would like to see an alternate pointer appear. The pointer already changes from an arrow to a pointing-hand; what is involved in using a 3rd pointer image (for new-window links)? I realize that the real trick here is the logic (to determine which links will pop-up separate) but hopefully my suggestion can be incorporated into the ultimate solution.
Is this RFE still assigned? As 1.0 approaches, it would sure be nice to see at least ONE of the bugs I've voted-for be finished. ------------------------------ To repeat my previous (Nov. '01) comment: This doesn't need to be perfect! Even basic functionality, e.g. 75% accuracy, would be a huge (and original?) enhancement relative to other browsers. Also, could someone comment on the feasibility of using an alternate mouse- pointer (rather than an alternate underline or status-window message) to indicate new-window links?
*** Bug 122987 has been marked as a duplicate of this bug. ***
Tony: this is not a priority for me. Someone else will have to take it if it's to be finished in the near future.
Keywords: helpwanted
I see this one as a "It would be nice if..." item, but not a must-have... much more important for me is bug 78037, which lets a user set a preference to stop new windows from opening altogether unless specifically requested by the user.
-> nobody
Assignee: blaker → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Component: Layout → Embedding: Docshell
*** Bug 128019 has been marked as a duplicate of this bug. ***
*** Bug 134886 has been marked as a duplicate of this bug. ***
I would much rather have an icon of some sort in the status bar - modifying the appearance of the link sounds like a bad idea to me for several reasons: 1) It means over-riding the look of the link as defined by the site's author. What if they have turned off underlines for example? Showing a dotted underline when the link is meant not to have any underline is damaging the idea of a site author using CSS to control appearance. 2) What about links that are images? Most images have border set to zero (because borders around images are often ugly). Showing a weird dotted border just because target is set to blank will look weird. The border / underline changing thing is also un-intuitive. Will normal browser users understand why this is happening, especially when this feature is not present in other browsers they may have used? I check the status bar as a matter of habit to see where a link is going. A small icon to the LEFT of the url displayed in the status bar should be all that is needed to show that a link is going to open in a new window. Most users don't care anyway, but those of us that do will know where to look.
*** Bug 144739 has been marked as a duplicate of this bug. ***
This would be a great feature, a candidate for a future W3C recommendation. Is anyone still working on it? I could provide the icons.
Test study for a possible solution. This changes the cursor in case of both "link into the new window" and "scroll within the document" case. The cursors are lame, but unfortunately, adding new cursor natively would require coding across all supported gfx platforms (Qt, GTK, Windows, OS/2, etc.). I may try to look into that if I have time, but Linux only :-) Another (neat) solution would be to use custom cursors, but not until bug 38447 is resolved :-(
*** Bug 165405 has been marked as a duplicate of this bug. ***
*** Bug 168783 has been marked as a duplicate of this bug. ***
Blocks: 169678
*** Bug 173678 has been marked as a duplicate of this bug. ***
Summary: [RFE] Indicate whether a link will open in a new window → Indicate whether a link will open in a new window
*** Bug 176661 has been marked as a duplicate of this bug. ***
*** Bug 176974 has been marked as a duplicate of this bug. ***
*** Bug 177100 has been marked as a duplicate of this bug. ***
*** Bug 175336 has been marked as a duplicate of this bug. ***
FYI: Konqueror also marks this in the statusbar, adding "(in new window)" to the destination URL. So I am always looking there to see if this opens in new window or not. Changing mouse cursor can also be nice, maybe even better. Please read Jacob Nielsen's Designing Web Usablility ((c) 2000 New Riders Publishing) to see some nice cursor shape change ideas (from back in '98 and still no one of the great ideas made it into the browser world!!) Thanks.
*** Bug 191857 has been marked as a duplicate of this bug. ***
So my suggestion: It would be nice to see if the link wants to open a new window by hover over the link. Maybe you can add a kind of toolbar that appears if you hover over a link (like the toolbar in IE by hovering over images) where you can select: "Open Link in new Tab" "Force Link to open in this Window" "Open Link in new Window" and where you can see a small icon, which repesentates the normal behavior for this link. If you click on the link itself, it would use the normal behavior of the link.
I think floating toolbars only make navigation difficult and produce a lot of bugs. It's better to use a slightly modified mouse cursor (the usual hand with a small window on the background, for example) the way 'image autoresizing' does. What do you think?
Yeah, I would classify such a toolbar as overkill, better left for a separate project. In any case, it is beyond the scope of this bug. I like the slightly different icon idea (maybe a spark/star next to the hand, signifying new--see the compose new message icon in mailnews) Appending text to the url in the status bar would require too much eye work. You'd have to check down there before clicking on every single link in order for the feature to be useful. On the other hand, your eye is already focused on the cursor.
*** Bug 192754 has been marked as a duplicate of this bug. ***
*** Bug 196971 has been marked as a duplicate of this bug. ***
*** Bug 201892 has been marked as a duplicate of this bug. ***
*** Bug 201785 has been marked as a duplicate of this bug. ***
On Mac, the contextual menu (hold down Control while clicking the mouse, or just hold down mouse) includes "Properties", and "Properties" includes whether the link opens in the same or new window. So the information is available though not obviously so. If cursors can be programmed in, that would be good. A "new window" pointing hand could point SIDEWAYS. //Polly
that's right, it tells me that when i click on 'a' from this url: data:text/html,<a href=javascript:window.open('about:')>a it will open in the same window.
Technically, it does... the "javascript:" URI opens in the same window, but subsequently, when the window.open method is invoked, causes another window to open. I don't think there's any easy way that all the different possibilities of indirect window opening (JavaScript opening windows in addition to or instead of the main one, multimedia content types opened by external helper apps, etc.) can be detected and represented in the link properties shown prior to following the link. Incidentally, the "data:" URI given here is invalid in several ways; it contains characters not valid for unencoded URI use, and the embedded HTML document is invalid due to the mandatory TITLE element being missing, the A element not having a closing tag, and the HREF attribute value not being quoted despite containing non-name characters. The "javascript:" URI scheme is not in any standard, either, despite its common use.
people of late have ranted that mozilla's new target is end users. if an end user loads that document and gets an error message about it being malformed, then end user will be confused at best. i write short things that i know work well enough to demonstrate the point i'm trying to make. if i wanted to waste time writing a complete document i'd have done something else. i didn't. speaking of correctness, i'd have needed to wrap the js in void() to prevent the current page from changing. back to our end users. they're the new target audience. explain to them why when they clicked on a link like 'a' with a behavior similar to the one in my example they got a new window. for some reason they relied on this new feature you're adding which clearly told them the link wasn't going to open in a new window. oh and in case it wasn't clear from this bug, it is basically impossible to determine whether a link would open in a new window. a link could very well decide whether to open in a new window based on the time of day. data:text/html;charset=utf-8;base64,PHRpdGxlPjxhIGhyZWY9ImphdmFzY3JpcHQ6aWYoRGF0ZS5ub3coKSUyKXZvaWQod2luZG93LmxvY2F0aW9uPSdhYm91dDonKTtlbHNle3ZvaWQod2luZG93Lm9wZW4oJ2Fib3V0OicpKX0iPmE%3D I didn't specify a doctype, i'm fairly certain html (not necessarily html4 strict) lets me legally omit the closing tag. title is of course mandatory, but well.... anyway, the problem w/ this new data uri is that no human can read or understand it. but if it makes dan happy :). as for javascript: err, well... um... right, that's really easy to work around. i could use <a onclick="...;return false">a i suppose it's not uncommon while i'm at it... data:text/html,<title><a onclick="window.location='about:'">c<a href="mailto:">l<a href="news:">i<a href="telnet:">c<a href="mms:">k<a href="rtsp:">m<a href="callto:">e</p> Note that the preceding violates http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-meaningful-links The question from 'clickme' is should we identify things that will open in external apps (since they're almost certainly new windows)?
For chrissake's people, we've been **** around with this for FOUR YEARS! Can't we implement a partial solution, at least? The argument that "there's no way to always detect" is spurious IMO. There's already lots of features that don't work 100% (e.g. printing) but that hasn't stopped us from implementing them. Finally, if we want to convince end-users to abandon IE, we need helpful new features like this to differentiate us...
*** Bug 226510 has been marked as a duplicate of this bug. ***
RE: Comment #53. Thanks for providing a "link" to use for an example!
My 2 bits worth. I've been bumping into lots of documents that insist on opening up the link in a new window; since I browse with tabs this is really annoying. Sometimes I lose the window entirely under something else. In any case I usually end up killing the new window and then going back to the original link and opening it in a new tab. My proposed solution: 1) Make unusual links (i.e., ones that don't open in the same tab) visible to the user. My preference would be to have the cursur change to indicate the link type. The user could choose to alter the way the cursor changes (i.e., color, icon, audio) via the preferences. The other alternatives do not seem as good: browser status bar is too far away from my usual gaze and changing the link rendering interferes with the static view of the document). 2) Augment the right-click options to allow the user to select from the options o Open link (do what it was going to do) o Open link in new window (that one's already there) o Open link in new tab (already there) o Open link in this window/tab (this allows window/tab reuse).
Sorry to spam this, but I thought I'd just mention you can already stop new windows being opened by setting the preference "browser.block.target_new_window" to true. They will then open in the existing tab. Hopefully this post will help to stop to many people posting here - I've not been bothered about this bug being fixed since I've known of this preference. Maybe the developers could add a checkbox in the preferences dialog - it's obviously popular preference.
To a very large extent, there is already an MSIE add-on ( http://www.draig.de/LinkBar/ ) which customizes the cursor when a link has a target="_blank" attribute (see bug 240042 for more info). Trying to detect and deal with href="javascript:FunctionNameOpeningNewWindow();" ... will be difficult to do. Even distinguishing a target frame from a window name or non-existent frame can be difficult. I think Mozilla should use the same cursor as IE LinkBar uses and also should first try to deal with target="_blank" links.
*** Bug 299210 has been marked as a duplicate of this bug. ***
*** Bug 313116 has been marked as a duplicate of this bug. ***
*** Bug 268984 has been marked as a duplicate of this bug. ***
http://www.computerworld.com/securitytopics/security/story/0,10801,100535,00.html In this web page there is a link for www.distrowatch.com in the middle of the screen. The cursor does not change to "crosshair" or "move" as written in my userContent.css /* Change cursor for links that open in new window */ :link[target="_blank"], :visited[target="_blank"], :link[target="_new"], :visited[target="_new"] { cursor: crosshair; } /* Change cursor for JavaScript links */ a[href^="javascript:"] { cursor: move; }
dsfsdfd
Filter on "Nobody_NScomTLD_20080620"
QA Contact: claudius → docshell

I'm getting sick of opening a set of links, then checking, and finding each one is just

javascript: void(0)

... because they weren't actually links.

Since many of these are embedded in buttons, I don't think using different text mark-up would work. Could using different cursor icons?

The status bar does show javascript: void(0), but it's hard to check the status bar while moving the cursor.

Severity: normal → S3
Attachment #9385363 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: