Currently, users can only find the link type *after* pressing it (for example after their mail client or download manager is launched). It is true that the status bar may be informative for some, but it really only helps knowledgeable users. Moreover, some sites even bother to hide this data. When such links are hovered on, Mozilla should display an informative icon, adjacent to the normal hand-shaped cursor. This way, users will not be surprised when windows pop-up or when client applications are launched. Here are a few examples: javascript:parent.openWin('/popup.html') -> a pop-up link -> display a window icon. http://www.files.com/downloads/file.zip -> a download link -> display the file extension (zip in this case). mailto:user@mail.com -> a mailto link -> display a letter shaped icon. Hovering over NNTP (newsgroups) and FTP links should display 'News' and 'FTP' respectively. More details can be found in the following mozilla.wishlist discussion: http://snurl.com/enhanced_cursors Prog.

FYI: window.open() links and internal # links are covered by bug 14027

You're right Mats and it seems that the mailto part of my RFE is covered by Bug# 90213: "[RFE] Specific mousepointer when hovering mouse over a mailto: link" If this bug (169678) is approved, it would probably depend on Bug# 38447 "Implement Handling of URI Values on CSS2 "cursor" Properties" So basically, all of these bugs discuss visual indication of special links. This one adds download, FTP and NNTP links. Aren't all of these cursor enhancements supposed to expand on the same cursor-shape functionality (which is not there at the moment)? Prog.

Well, since bug 14027 and bug 90213 are already approved ...

Changing component to the same as bug 90213 (made more sense than bug 14027) and reassigning to owner of that component.

*** Bug 173403 has been marked as a duplicate of this bug. ***

reassign

*** Bug 240042 has been marked as a duplicate of this bug. ***

To a very large extent, there is already an MSIE add-on ( http://www.draig.de/LinkBar/ ) which customize cursors for these 3 kinds of links (see bug 240042 for details, installation, demo). The only difference with the provided description of this bug is that it only covers target="_blank", not href="javascript:FunctionNameOpeningNewWindow();" ... which might be difficult to do. a[target="_blank"] {cursor:-moz-open-blank-window !important;} a[href$=".exe"] {cursor:-moz-download-trigger !important;} could be added into the html.css file or be made available to the userContent.css. The .cur files for these 2 cursors are already available at my site. I don't know how to embed these into the mozilla trunck code though. Other .cur files could be designed (shape, color, outline) too. CSS3 hyperlink also asked: "How are secondary (or even tertiary) links styled? Do they need to be? Or should their interactivity be left up to the user agent?" http://www.w3.org/TR/2004/WD-css3-hyperlinks-20040224/#open-issues I think customizing cursors might be an answer.

CC added: A. Thompson

Here's another problem that this bugfile could solve: unidentified .pdf links. Go to http://ospreymediagroup.com/corporate/Default.asp?section=publications and then click the "Map of Osprey's Coverage Areas" link at the bottom of the page. Now, if you are not careful and/or don't look at the statusbar, you will be opening Acrobat reader (and that takes time, cpu, RAM, etc) and will be downloading a 995KB .pdf file! This bugfile could include to identify accordingly link referencing .pdf file; even google.com does that when listing search results. If bug 38447 was fixed, I would create a win32 .cur cursor (that's easy) for pdf files and I would definitively include, say, this css rule in my userContent.css file: a[href$=".pdf"] {cursor:-download-pdf !important;}

Testcase for this bug: http://www10.brinkster.com/doctorunclear/Bugzilla/MetaDemoPageCursors.html When viewing with MSIE 6, one can see the customized cursor, otherwise an equivalent image shows it in the table.

Very convincing examples. Just one small note, the idea here is that the browser will initiate these cursors, not the website. Prog.

(In reply to comment #12) > Very convincing examples. Just one small note, the idea here is that the browser > will initiate these cursors, not the website. > Of course. Agreed. The page may be using cursor: url() for demonstration/display purposes but what this bug rightfully requests is customized cursors implemented into Mozilla. Declarations like a[href$=".exe"]:not([onclick]) {cursor: -moz-downloadexe.cur !important, auto;} could be in html.css or ua.css or cursors could be hard-coded in Mozilla.

Similar functionality is already available for Firefox (and Mozilla) as an extension: "TargetAlert is an extension for the Firefox web browser that provides visual cues for the destinations of hyperlinks. If a hyperlink points to a something that is not a web page, then TargetAlert will try to append an icon to the hyperlink that represents its destination." http://www.bolinfest.com/targetalert/ Prog.

CCing Michael Bolin, the author of TargetAlert. Prog.

Let me oppose the idea of this bug getting ever fixed. Once the bug 38447 is fixed, it should really be a webmaster's solution (on per-site basis) how to mark external links (i.e. links to other sites), mailto: links (i.e. e-mail addresses), new window links (i.e. JS-popups and _blank-marked), and so on. It seems to be a really ridiculous idea that the browser will initiate these cursors, and not the website. The cursor shape over a hyperlink, as well as the colour and the background and the font and the text-decoration of that hyperlink itself, is normally the webmaster's realm. If you want the browser to notify, let it happen inside the browser UI (for example, fix bug 257600), and not on the page itself. And even if I am wrong and this in not going to become a common webmaster's habit, let this bug be fixed by an extension (based on the cursor: url(...) CSS2 property, and providing chrome URLs, when bug 38447 is fixed), and only by an extension, and not in the browser core or in default XUL. This will let some of us not to install such an extension. And, which is even more important, this will let some other ones of us to choose between several extensions offering different cursor sets. Please do not kill the diversity and let us all live in the variety of different possibilities. Thank you. And please note that the aboved mentioned extension (fixing this bug) is blocked only by bug 38447. It's just a three or five lines of CSS2 and a bunch of XUL, and a manifest of RDF -- and, of course, a directory full of cursors ;-) Personally I am already using cursors on my website to mark links that open new windows. If you're on Windows, try to launch an instance of Internet Explorer 6 and visit http://mithgol.pp.ru/Mozilla/ -- and then hover the upper hyperlinks (leading to Bugzilla and to Bug 32218). You'll notice that the cursor is not a standard one, and the link tooltip (<a title="...">) is pretty informative. But these are my own markings, and I really don't want any browser to interfere. I have a real reason, haven't I?

> append an icon to the hyperlink that represents its destination." > It's an image. It's not setting the css property cursor as requested by this bug. I tested this rule a[href$=".pdf"]:not([onclick]):after {content: url("path/Cursor_Pdf_Icon_.gif");} with the latest Mozilla build and it worked. > it should really be a webmaster's solution (on per-site basis) how to mark > external links Well, this is why bugs are filed here: webmasters usually do not mark (with an icon or with the title attribute or otherwise) external links. In fact, above 95% of all webmasters out there do not use valid markup and css code for their pages, ignore/do not follow WCAG guidelines, still try to open unrequested popups, add music, blinking+moving banner ads, etc,et... That is why modern browsers try to implement features (flashblock, popup blocker, etc) which will protect users and will enhance their experience, safeguard usability and accessibility of pages, etc.. and that is in the best interests of web authors themselves. > this in not going to become a common webmaster's habit Exactly my point. This bug is a needed enhancement. Another *proof* that this bug is needed is that a majority of links referencing 500+ KB .pdf file are not properly marked in any way (with title attribute or icon or cursor - *because MSIE 6 support user-defined cursors*) that they will trigger Acrobat Reader and then start automatically a long download for modem users out there. There is already quite a lot of documentation that would support this bug's goals.

(In reply to comment #16) > Once the bug 38447 is fixed, it should really be a webmaster's solution (on > per-site basis) how to mark external links (i.e. links to other sites), mailto: > links (i.e. e-mail addresses), new window links (i.e. JS-popups and > _blank-marked), and so on. It seems to be a really ridiculous idea that the > browser will initiate these cursors, and not the website. > > The cursor shape over a hyperlink, as well as the colour and the background and > the font and the text-decoration of that hyperlink itself, is normally the > webmaster's realm. The browser and user provide the defaults. The author then suggests a particular style, which the user usually accepts (but may reject by disabling styles). > If you want the browser to notify, let it happen inside the > browser UI (for example, fix bug 257600), and not on the page itself. The cursor isn't part of the page; it's part of the UI. I agree that changing the cursor to indicate the type of a link's target is too invasive to use as a default. (In reply to comment #16) > http://www.files.com/downloads/file.zip -> a download link -> display the file > extension (zip in this case). A file on a server needn't have a "file extension" (i.e. a set of letters that follows a dot and indicates the file's type); if it does, the extension needn't match the actual file type. E.g. it's valid to serve a PNG image as http://foo.bar/index.html, but with a MIME type of image/png. There's no way to know the type of content at a given URL without requesting that URL.

> Let me oppose the idea of this bug getting ever fixed. I hope you can still keep an open mind. For starters, tips and tricks submitted by mozilla.org offer the crosshair cursor for identifying links opening new windows. I'm sure you'll agree with me that this is definitely not best. Change the cursor for links that open in new window http://www.mozilla.org/support/firefox/tips#lay_linkcursornew That mozilla.org tip is a good example of a bad cursor being proposed to identify types of links. That mozilla.org tip proves the need for a distinct, meaningful cursor clearly indicating a link which will open a new window. > It seems to be a really ridiculous idea that the > browser will initiate these cursors, and not the website. > > The cursor shape over a hyperlink, as well as the colour and the background and > the font and the text-decoration of that hyperlink itself, is normally the > webmaster's realm. Why should we (every single website authors) need to create our own cursors? I would not trust 99% of so-called webpage authors out there to be able to create meaningful, intuitive, useful for navigation cursors like those (pop-up/download/mailto) covered by this bugfile. 95% of all those so-called webpage authors already can not write well designed documents using valid markup code, valid css code and without nested tables. You can not really expect them to read cursor specs, download or buy cursor softwares and do their own like professionals. Such expectations are unrealistic. > If you're on Windows, try to launch an instance of Internet Explorer 6 > and visit http://mithgol.pp.ru/Mozilla/ -- and then hover the upper hyperlinks > (leading to Bugzilla and to Bug 32218). You'll notice that the cursor is not a > standard one, and the link tooltip (<a title="...">) is pretty informative. I think your "opening in a new window" cursor is well done, meaningful, intuitive, even more descriptive, meaningful and better than http://www.draig.de/LinkBar/ "opening in a new window" cursor.

Okay, you now convinced me. However, I still think that if there are any CSS rules this fix is going to introduce (and, yes, there are; bug 38447, when fixed, will makes this one fixable via CSS-only solution for this bug, at least partly), then these rules should not take any precedence over webmaster's cursor: url(...) CSS-rules for the same elements. I mean, your point is really, really good: I can not, seriously, expect 95% of all those so-called webpage authors to read cursor specs, download or buy cursor softwares and do their own like professionals. Such expectations are unrealistic. However, if 5% (or even less) of them still read all the specs, grab all necessary soft, do some creative work just to see that Firefox ruins it all using its own cursors instead -- well, then all that webpage authors will be greatly upset, I guess. If you argee, than we'd find a way to make this bug fixed only in certain circumstances where and when it's not already fixed by website. If there's already cursor url() defined for element via CSS, then it should be kept intact. Some of such cursors, I'm sure, will be much better done, more meaningful, more intuitive, and a lot more descriptive than my humble bitmaps that impressed you that much. When bug 38447 is fixed, url()-value will become cross-platform instead of former MSIE-only, and thus we'll get here and there groups and teams really dedicated to making truly artistic cursors. Following this intention, having visited http://www.w3.org/TR/CSS21/cascade.html#cascading-order and read subsection 6.4.1 of CSS level 2 revision 1, and some adjacent subsections, on topic of definig cascading order, calculating a selector's specificity and all that matters of the cascade and precedence, I've finally found there the following order of importance (in ascending order): 1. user agent style sheets 2. user normal style sheets 3. author normal style sheets 4. author important style sheets 5. user important style sheets It's a well-known habit to flavour all CSS hacks in userContent.css (and it's expected that bug 179006 will allow simple extensions to achieve the same results) with !important mark, thus giving them the highest order of importance in CSS cascade. However, the CSS fix for this bug MUST NOT be given !important value, because author's url()-rules should dominate. The CSS fix for this bug may also be driven to user agent style sheets, with the least importance, to override only default cursors. Specificity of CSS2.1 selectors should also be taken into account. Our typical rule (one of CSS rules fixing this bug) will start with type selector followed by attribute selector, e.g. A[target=_blank] { cursor: url(chrome:.../popup-cursor.cur); } and so it will have the specificity of (a=0;b=0;c=1;d=1). This declaration will (as far as I understand) override less specific A { cursor:... }; -- and that's intended by our bug summary. This declaration will, however, be overridden by author's rules of the same specificity (but of higher importance), for example, A.newWindow { ... }. This effect will allow authors to make their own cursors and enjoy having them shown by Mozilla and/or by Firefox. Seems good, but there are some problems. 1) DIV.makeAllLinksFancy A { cursor: url(myMegaHyperSuperCursor.cur); } has higher specificity than A[target=_blank] { cursor: url(chrome:.../popup-cursor.cur); } 2) DIV#theOnlyOne A { cursor: url(myMegaHyperSuperCursor.cur); } has even higher specificity! 3) I have a feeling that I was wrong and the most important less specific A { cursor:url(...); } overrides even more specific A[target=_blank] { cursor:url(...); } of lesser importance. Importance is more important than specificity. So the attempt of authors to change cursors over links inside larger blocks of content will effectively render our fix unusable :-( That's a trap. Probably the fix should discard my above mentioned idea, and the rules must, after all, be marked !important. However, these rules should be discarded if class="..." attribute for link element is non-empty. And there is a way! Using CSS3 negation pseudo-class (described at http://www.w3.org/TR/css3-selectors/#negation -- however, I'm not sure whether Gecko supports it!), the rule would be something like A[target=_blank]:not([class]) { cursor: url(chrome:.../popup-cursor.cur) !important; } put into userContent.css, thus getting the fifth (the highest) degree (level) of importance, and a good enough specificity. And still discardable, if website authors use A.newWindow { cursor: url(...); }. But discarded also for <a class="underline">, A.underline { text-decoration: underline; } won't match :not([class]). Damn! Okay, the third approach merging the above two: A[target=_blank]:not([class]) { cursor: url(chrome:.../popup-cursor.cur) !important; } --> user important style sheets, highest importance AND A[target=_blank] { cursor: url(chrome:.../popup-cursor.cur); } --> user agent style sheets, lowest importance Looks great, huh? -=- Appends to A.anyClass { notcursorproperty: anyvalue; } our user agent style sheet value, though user important style sheet fails to negate [class] selector -=- Overrides DIV.anyClass#anyID A { cursor: url(); } by user agent style sheet value, because of higher importance -=- Leaves A.authorClass { cursor: url(); } intact, because user important style sheet fails to negate [class] selector, and user agent style sheet has lower importance So the bug will be fixed, and the authors still can use class selectors (e.g. A.authorClass) for their own cross-browser graphic fix for this bug, and our fix won't harm this habit. Why we expect authors to use class selectors for this? Because MSIE does not support attribute selectors like [target=...]. So we have the ready solution for the most simple pop-up links: A[target=_blank]:not([class]) { cursor: url(chrome:.../popup-cursor.cur) !important; } --> user important style sheets, highest importance AND A[target=_blank] { cursor: url(chrome:.../popup-cursor.cur); } --> user agent style sheets, lowest importance It should be changed accordingly for the other subtasks of bug fix. For example, the download_name.exe fix: A[href$=.exe]:not([class]) { cursor: url(chrome:.../popup-cursor.cur) !important; } --> user important style sheets, highest importance AND A[href$=.exe] { cursor: url(chrome:.../popup-cursor.cur); } --> user agent style sheets, lowest importance

This was a really long comment, and it happened not to come out entirely correct and clear after all. Example: -=- Overrides DIV.anyClass#anyID A { cursor: url(); } by user agent style sheet value, because of higher importance should read: -=- Overrides DIV.anyClass#anyID A { cursor: url(); } by user important style sheet value, because of higher importance Some other phrasing also needs revision, but that'll be less necessary bugspam, so I won't.

(In reply to comment #20) > However, if 5% (or even less) of them still read all the specs, grab all > necessary soft, do some creative work just to see that Firefox ruins it > all using its own cursors instead -- well, then all that webpage authors will > be greatly upset, I guess. This sounds like a reasonable default, but the browser should also offer a way to override cursors specified by the page, just like it does with custom context-menus or status-bar text. Prog.

(In reply to comment #20) > Okay, you now convinced me. The problem is that after a good chat with timeless, he convinced me that fixing this bug under current javascript environment is not recommendable. The problem basically is that such custom cursors could mislead users, could deceive users: no hint is better than abused hinting. In at least 2 cases, mozilla might not be able to evaluate correctly (thus anticipate) types of links: when the page is js-driven with setTimeout code and when events bubble up in the containment hierarchy triggering event listener code. You might be able to evaluate what some code does for a particular node (an <a href="...">) but then the rest of the document might interfere or negate what was evaluated on such particular node. So, the properties of a link might say "a", the javascript code might do "b", the setTimeout might do "c" and js code in the containment hierarchy might do "d" (and all these a, b, c and d things might be conflictual, complementary, overriding and/or negating each other) and mozilla would have to evaluate a mass of code *before* a mouseover of such particular node and render the correct cursor. CSS code/rules based on parsing html attribute value strings is already not reliable, trustworthy. > If you argee, than we'd find a way to make this bug fixed only in certain > circumstances where and when it's not already fixed by website. If there's > already cursor url() defined for element via CSS, then it should be kept intact. Of course. That was my original understanding too. > When bug 38447 is fixed, url()-value will become cross-platform > instead of former MSIE-only, and thus we'll get here and there groups and teams > really dedicated to making truly artistic cursors. You and I already can create cursors and can use them for our specific pages when bug 38447 is fixed. > 1. user agent style sheets > 2. user normal style sheets > 3. author normal style sheets > 4. author important style sheets > 5. user important style sheets Mozilla complies with such set of css parsing and cascading rules and MSIE 6 too. That's not the problem with fixing this bug. The fix I was hoping for would have been coded in the user agent [default] stylesheets; therefore leaving, granting all veto powers and latitude to other [2, 3, 4 and 5] levels of coding to be done. Sorry about all that.

Well now what's the use of status string? The status string displays "Done" when you've got the whole page -- however, it could happen that setTimeout() is active, and some JavaScript function soon will bring you to another page of the Web, or change some content of the current page, so it's not all "done" already. The status string displays URL when your cursor hovers over a link, but that's only "a", and there are "b", and "c", and "d" as well. So is the status bar misleading, or even deceiving? Sometimes. Is, then, abused statusbar worse than no statusbar at all? Yes, it is. But the ability to abuse our statusbar -- the ability technically available via JavaScript -- is not enough to give up. There are lots of pages that don't use any JavaScript at all. Lots! There are, also, pages that don't abuse statusbar this way, though they use some JavaScript somewhere. And that's why Firefox still has its statusbar under each page or tab, and Mozilla has it also. Now, what bug 169678 -- this bug -- is about? It's a visual presentation of URLs that appear on the statusbar. Just a visual hint. No more, no less. And, yes, it is abused when statusbar is abused, and with exactly the same technique. But Mozilla and Firefox demonstrate URLs on statusbars, and they may change cursor shape as well. Why? Because many pages don't use JavaScript at all, though they have mailto:, and have target="_blank" pop-ups, and links to download EXE files, et cetera, et cetera. timeless is against the custom cursors in this bug, because he is always against custom cursors -- I am convinced now that he has always thought that bug 280331 is unfixable, that's why he never posted this bug to Bugzilla, thinking of it as of a useless act, and I, finally, had to do it myself. And that's why he opposes most of bugs which are blockers of bug 280331 -- he'd rather see all of them wontfixed, because this lowers the pressure of bug 280331. All the same argumentation (based on JS abuse methods) may be used against the display of URL on statusbar as well as against cursor shape, but the statusbar is not affected by bug 280331, so timeless is against cursor shape, but he never said a word against the existence of statusbar. I -- quite the contrary -- think that bug 280331 is able to be fixed, and that technical ability is the hope for us all. And that's important: we should think separately of separate problems, even when they are adjacent. This bug is one problem, and bug 280331 is another. Abusing visible URLs -- when onClick="...", and/or setTimeout(), and/or event hierarchy, are used against visible URLs -- it is the third problem, separate from this bug, separate from bug 280331 as well, and related to security. None of these three problems should be wontfixed in Bugzilla -- but they should be solved separately. Existence of all the three must be acknowledged, and then they should be separated to different bugs in Bugzilla, though possibly connected via "depends" and "blocks" relations. It's possible to display some URL in statusbar when hovering the link which itself is used for something different via JavaScript. But statusbar exist, unless you switch it off via View --> Status Bar. Cursor shape, frankly speaking, reflects the same URL, though partly -- sometimes its prefix (mailto:), sometimes its suffix (.exe, .pdf, etc.) So why statusbar exists, but fixing this bug under current JavaScript environment is not recommendable? They (cursor shape and status bar) share the same JavaScript environment, don't they?

-=- in reply to comment 22 -=- The browser should offer a way to override cursors specified by the page, but that's a separate problem. It stands closer to bug 38447 than to this bug. Actually, you'd create a separate bug out of your valuable comment, then add bug 38447 as a dependence, because bug 38447 blocks your bug (i.e. you cannot request control over a value which is not yet implemented). Your demand is actually equivalent to the ability to switch off the fix for the bug 38447 -- to switch it off by some about:config property, or even by checkbox in options window. Right?

-=- more in reply to comment 22 -=- And then you'll need asking Christian Biesinger -- cbiesinger@gmx.at -- for help. He's fixing bug 38447 and so he'll know better how to implement limitations to his own fix. He'll know it better then anyone else in the system. Ask him.

am i always against custom cursors? i actually had to think about at least one of the four bugs that was mentioned to me. i'm first and foremost opposed to hints which can be abused to trick users. and yes, this means that i'm not a fan of the way people abuse the status bar, i'm hoping to eventually find time to deal with that too.

I've seen this implemented in Konqueror (unfortunetly for e-mail links only) and I love it. It lets user easily know what kind of link he is clicking.

Filter "spam" on "guifeatures-nobody-20080610".

I accidentally bumped to this one while searching for something else. Doesn't this need to be for firefox and perhaps tb as well? Also, it's been quite some time since it last got attention and I think it should be a won't fix. Reason is that there already is a extension that does this for firefox called 'Link Alert': https://addons.mozilla.org/en-US/firefox/addon/3199 http://linkalert.googlepages.com/ ...once you've installed it, go to: http://linkalert.googlepages.com/testpage.htm to test/see in action the protocols and filetypes it supports. I've been using it for a long time without any issues and I think we should focus on helping the developer to support sm and tb instead of reinventing the wheel from scratch. As a matter of fact, I'll send him/her an email right after posting this and see what can be done. Once this is done, we can mark this bug fixed and point people to this addon. If it is considered very important, we could request to have it implemented as a core feature. But I think developers feel that such things should stay as addons and after all they need to focus in other critical bugs and features missing that are considered 'blocking'. What do you people think?

scratch my comment about it being a firefox issue as well. It seems that firefox already supports the links/cursors shown in: http://www.gtalbot.org/BugzillaSection/MetaDemoPageCursors.html ...and it displays the exact same images as shown in the screenshots of ie6. The 'Link Alert' addon I mention enhances it a lot though. Give it a try.