169678 - Cursor shape should reflect the type of link hovered on (e.g. pop-up/download/mailto...) (different cursors for links to new windows)

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[Prognathous]

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:[e-mail] -> 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.

Comment 1

[Mats Palmgren (inactive)]

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

Comment 2

[Prognathous]

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.

Comment 3

[Jo Hermans]

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

Comment 4

[Torben]

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

Comment 5

[Kenneth Herron]

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

Comment 6

[Hixie (not reading bugmail)]

reassign

Comment 7

[Gérard Talbot]

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

Comment 8

[Gérard Talbot]

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.

Comment 9

[Gérard Talbot]

CC added: A. Thompson

Comment 10

[Gérard Talbot]

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;}

Comment 11

[Gérard Talbot]

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.

Comment 12

[Prognathous]

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

Prog.

Comment 13

[Gérard Talbot]

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

Comment 14

[Prognathous]

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.

Comment 15

[Prognathous]

CCing Michael Bolin, the author of TargetAlert.

Prog.

Comment 16

[Sergey Sokoloff]

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?

Comment 17

[Gérard Talbot]

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

Comment 18

[Grey Nicholson (they/them)]

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

Comment 19

[Gérard Talbot]

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

Comment 20

[Sergey Sokoloff]

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

Comment 21

[Sergey Sokoloff]

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.

Comment 22

[Prognathous]

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

Comment 23

[Gérard Talbot]

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

Comment 24

[Sergey Sokoloff]

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?

Comment 25

[Sergey Sokoloff]

-=- 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?

Comment 26

[Sergey Sokoloff]

-=- more in reply to comment 22 -=-

And then you'll need asking Christian Biesinger -- [e-mail] -- 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.

Comment 27

[timeless]

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.

Comment 28

[Jure Repinc (JLP)]

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.

Comment 29

[Serge Gautherie (:sgautherie)]

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

Comment 30

[klonos]

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?

Comment 31

[klonos]

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.