Open Bug 14027 Opened 25 years ago Updated 2 years 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, 2 obsolete files)

Solution study for cursor changing
(deleted), 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) (deleted) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Dotted underline for <A> links (obsolete) (deleted)
        — 
          — 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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: