107160 - Mouseover link information - feature request

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Lloyd Wood]

I'd like to be able to mouseover a link, wait, and have the browser issue a HEAD
request for that link. The browser would then display useful information about
that link in a title-like tag. Useful information gleaned from the HEAD request
would include:

- Page not there or other errors (don't waste time clicking this link - useful      
  for search results).

- Page requires authorisation/password

- Page sends cookie (useful to know depending on your cookie settings.
  If you're checking every cookie, this becomes useful)

- Page last modified time/date

- offsite page (i.e. you will be sent to a different server)

- WARNING! HUGE DOWNLOAD IF YOU CLICK THIS!

It might make sense to pipeline other HEAD requests to the same server from the
page at the same time; but then you'd need to cache/refresh them, and it gets
complex.
The aim of this is simply to provide more information for the click decision;
lightweight HEAD requests are ideally suited to do that, especially if a 1.1
connection to the server is already open. If not and a connection must be
opened, the traffic/benefits tradeoff is more arguable.

L.

Comment 1

[Blu3]

Wouldn't this be better served as a right mouse option?

Right Button->Fetch Content information

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is in any case not DOM events.  Over to XP Apps; this seems like a decent
idea.

Comment 3

[Bradley Baetz (:bbaetz)]

eww. This would be slow, esp since we don't actually do pipelining yet. We do,
however, have an nsILinkChecker added by akk to do something similar to this for
editor.

Also note that some versions of the ns webserver will return a 400 response to
any HEAD request - try it on www.m.o, for example

Comment 4

[Lloyd Wood]

> Wouldn't this be better served as a right mouse option?
> 
> Right Button->Fetch Content information

It doesn't make sense to make this a right-click option. If the user is going to
make a click decision, he or she may as well click the link, rather than
deciding to click for a menu and navigate the menu to get information _about_
the link. The same reasoning as to why people try things out rather than read
manuals describing the things they can try out.

The aim is to improve the initial click decision (also the point of the title
tag); offering further options per link that you have to click to get to won't
do that. context-sensitive automatic help.

Note also that many sites are disabling the right-click menu altogether; these
are the sites whose links benefit most from additional transparent context.

And what's right button on a Mac? Your 'Fetch Content' says 'Load page' to me; 
that would not be consistent with HEAD meta-information about the HTTP 'object'.


> Also note that some versions of the ns webserver will return a 400 response to
> any HEAD request - try it on www.m.o, for example

That's broken behaviour.

Oh, has anyone filed a bug on mozilla.org telling them
to switch to apache?

Comment 5

[Lloyd Wood]

> Oh, has anyone filed a bug on mozilla.org telling them
> to switch to apache?

See 
http://bugzilla.mozilla.org/show_bug.cgi?id=107166

Comment 6

[sairuh (rarely reading bugmail)]

future, helpwanted

Comment 7

[Jesse Ruderman]

See also bug 109750, "[RFE] prepare the pages for displaying before you 
actually click on them".

Comment 8

[Asa Dotzler [:asa]]

-> default assignee

Comment 9

[Peter Trudelle]

->future

Comment 10

[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 11

[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 12

[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 13

[Lloyd Wood]

Enhancement request still valid for SeaMonkey 2.0a3.

Comment 14

[Robert Kaiser]

We are not planning to fix this in SeaMonkey - actually we even have disabled HEAD requests for downloads because they are not well-supported by websites in the real world.