Closed Bug 107160 Opened 20 years ago Closed 12 years ago

Mouseover link information - feature request

Categories

(SeaMonkey :: UI Design, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: L.Wood, Assigned: trudelle)

Details

(Keywords: helpwanted)

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.
Wouldn't this be better served as a right mouse option?

Right Button->Fetch Content information
This is in any case not DOM events.  Over to XP Apps; this seems like a decent
idea.
Assignee: joki → pchen
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: DOM Events → XP Apps
Ever confirmed: true
QA Contact: vladimire → sairuh
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
> 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?
> 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
future, helpwanted
Keywords: helpwanted
Target Milestone: --- → Future
See also bug 109750, "[RFE] prepare the pages for displaying before you 
actually click on them".
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
->future
Target Milestone: --- → Future
Product: Core → Mozilla Application Suite
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
Status: NEW → UNCONFIRMED
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
Group: core-security
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
Group: core-security
Enhancement request still valid for SeaMonkey 2.0a3.
Status: UNCONFIRMED → NEW
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.