102912 - E-mail links in link toolbar/bookmarks are not marked

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
   http://www.bath.ac.uk/~py8ieh/home.html
   Open the More menu.
   There is an item labelled "Authors" which looks like a link to a web page.
   Click it.

ACTUAL RESULTS
   A mail client loads.

EXPECTED RESULTS
   There should be a clear indication that the link is in fact a link to an
   e-mail address, e.g. "Email Authors" or a mail icon or something.

cc'ing usual suspects as per bug 102832.

mpt: could you give us some UI advice here? Thanks!

Comment 1

[Gervase Markham [:gerv]]

Perhaps bookmarks of mailtos in general need a new icon.

(Although, for me, clicking the Authors link at the moment takes me back a page
and appends #author to that URL. Very weird.)

Gerv

Comment 2

[sairuh (rarely reading bugmail)]

cool new feature!

->claudius, since he tests toolbars.

Comment 3

[Tim 'Tool-Man' Taylor]

I agree.  Clicking a mailto LINK is disconcerting when you expect it to load a
page and instead it doesn't do anything for a few seconds then pops up an email
composition window.  In lieu of or in addition to a new mailto icon, perhaps we
can change the text of the menuitem to reflect what will happen, switching
between "Email the Author" for mailto: links and "About the Author" for all others.

Actually, I'm not a big fan of switcheroo menu items, so I suggest that both
menu items be present at all times, each activitated by the appropriate LINK
type and URL.

Comment 4

[Christopher Hoess (gone)]

I don't think I like the idea of having two menu items at all times, one or the
other of which will always be disabled.  I'd prefer having it show different,
appropriate icons for the different protocols (http, mailto, tel...)

Comment 5

[Gervase Markham [:gerv]]

Other sorts of link maybe mailto: as well, so changing the text of the item
doesn't scale. Changing the icon does. (Are there any other URL types which need
special treatment? Should we give the same icon to news:// and snews:// URLs?)

Who did the original icons? Can they be persuaded to do some more? :-) CCing
hewitt and marlon.

Gerv

Comment 6

[Andrew Thompson]

Any icons for news should probably be patterned after those already found in the 
mail & news folder pane, for consistency's sake.

Comment 7

[Ben Bucksch (:BenB)]

From bug 109602:

Introduction:

The assumption is that the bookmarks / links lead to webpages (http, https). We
should make clear in advance, when that assumption is wrong.

For example, <link rel=made> is often used for webmaster email addresses, while
I would like to use it for an "About this page" link. However, visitors of my
site might have learned from other sites, that "Authors" menu item often pops up
a Message Composer window, which they didn't want, so they will be scared to
check my Author link (which goes to an About this Page page, which might be
exactly, what they are looking for).

Reproduction:
Either
1. Link Toolbar
1.1. Create webpage with <link rel="made" href="page.about.html">.
1.2. Visit that webpage
1.3. Look at Link Toolbar|More|Authors
2. Bookmark
1.1. Right-click on linked email address, bookmark
1.2. Open bookmarks, look at the new bookmark

Actual results:
Both entries have a "Bookmark" icon, making them indistinguishable from
bookmarks to webpages. However, activating the entry opens a Message Composer
window.

Expected result:
Can see beforehand what will happen. The email links have a different icon.

Comment 8

[Ben Bucksch (:BenB)]

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

Comment 9

[m_mozilla]

just a note that the UI change needs to follow the URL not the LINK type.

Various contact URLs can be http URLs. For example, instead of a webmaster email
you might have a link to a page listing alternate addresses for non-webmaster
type questions, and then a form to fill out for a webmaster-type question (so
the webmaster can also sniff your user agent string if that's useful).

-matt

Comment 10

[Matthew T (active 1999-2002)]

In my ancient spec for the Links Bar I said that any link for which the URI 
began was of the form foo:bar, rather than foo://bar, should be rendered in 
italics. That includes mailto:, obviously, and jabber:, and others which 
haven't been invented yet or which Mozilla hasn't heard of and can't possibly 
have distinguishing icons for.

Comment 11

[Ben Bucksch (:BenB)]

> any link for which the URI began was of the form foo:bar, rather than
foo://bar, should be rendered
> in italics.

That's broken. I don't know the jabber scheme, but if it's really not jabber://,
what sense does it make to make that italics, while
<irc://irc.mozilla.org/#mozilla> not?

Comment 12

[Matthew T (active 1999-2002)]

Simple. jabber:[e-mail] (like mailto:[e-mail]) goes to a person*, whereas
irc://irc.mozilla.org/#mozilla (like ftp://ftp.mozilla.org/) goes to a place.

* or reasonable approximation thereof

Comment 13

[Ben Bucksch (:BenB)]

<irc://irc.mozilla.org/BenB> goes to a person (connects you to irc.mozilla.org
and queries BenB), if I understood it correctly.

Comment 14

[Christopher Hoess (gone)]

URIs containing "//" after the scheme simply use the generic URI syntax for
hierarchical URIs described in RFC 2396. The distinction between URIs of form
<scheme>:<scheme-specific-part> as referring to a person and
<scheme>://<authority><path>?<query> going to a location is nonsense. (i.e.,
data: URIs).

Comment 15

[Sascha Claus]

news:foobar is also no person. A solution would be to add something similiar to
HTML/CSS classes to catch it with a browser/user stylesheet. You could use the
scheme and "slash" if it's of type "://".

http://foo/  -> class="http slash"
ftp://bar/   -> class="ftp slash"
news:foobar  -> class="news"
jabber:foo   -> class="jabber"
jabber://bar -> class="jabber slash"

(class attribute used as example) So it's easy to style it with the
browser's/user's stylesheet. Another solution would be the CSS3 selector

[href^="http://"]
[href^="jabber:"]
<URL:http://www.w3.org/TR/css3-selectors/#selectors>

Comment 16

[Chris Neale]

workable css3 selector - try the following in userChrome.css

will affect bookmarks and link toolbar

menuitem[href^="mailto:"],
.bookmark-item[statustext^="mailto:"] {
  border-bottom: 1px dashed red !important;
}

obviously a more appropriate style; border / list-style-image could be used
asin bug 109669 I presume
Orbit Retro :

menuitem[href^="mailto:"] {
  list-style-image: url("chrome://communicator/skin/bookmarks/bookmark-item-u.gif");
}

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420