Closed
Bug 107160
Opened 23 years ago
Closed 16 years ago
Mouseover link information - feature request
Categories
(SeaMonkey :: UI Design, enhancement)
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
![]() |
||
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
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
Reporter | ||
Comment 4•23 years ago
|
||
> 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?
Reporter | ||
Comment 5•23 years ago
|
||
> 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 7•23 years ago
|
||
See also bug 109750, "[RFE] prepare the pages for displaying before you
actually click on them".
Comment 8•23 years ago
|
||
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
![]() |
||
Comment 10•16 years ago
|
||
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
![]() |
||
Comment 11•16 years ago
|
||
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
![]() |
||
Comment 12•16 years ago
|
||
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
![]() |
||
Updated•16 years ago
|
Group: core-security
Reporter | ||
Comment 13•16 years ago
|
||
Enhancement request still valid for SeaMonkey 2.0a3.
Status: UNCONFIRMED → NEW
![]() |
||
Comment 14•16 years ago
|
||
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: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•