Closed
Bug 57675
Opened 24 years ago
Closed 23 years ago
More descriptive error message for non-http:// urls in What's Related
Categories
(SeaMonkey :: Sidebar, defect)
SeaMonkey
Sidebar
Tracking
(Not tracked)
VERIFIED
WORKSFORME
Future
People
(Reporter: bugzilla, Assigned: matt)
References
()
Details
(Keywords: privacy)
If you have the What's Related sidebar active and enter C:\ in the Location
field Mozilla tried to show What's Related for the link.
Youl then get a:
badurl
No data available
in the sidebar.
Expected:
Mozilla shouldn't try to show whats related info on file:// urls..
|
||
Comment 2•24 years ago
|
||
This looks similar to bug 53404, which is older, but has no additional comment.
|
||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.9
|
|
||
Updated•24 years ago
|
Priority: P2 → P3
Target Milestone: mozilla0.9 → mozilla1.0
|
||
Comment 4•24 years ago
|
||
How about making What's Related only see http urls? I get the "badurl" message
for finger and https urls, too.
|
|
||
Comment 5•24 years ago
|
||
We *don't* do what's related with file:// urls, or with anything that isn't
http:// for that matter:
if (0 != sUrl.indexOf("http://")) {
debug('TranlateContext: non-http argument:('+sUrl+')');
return kNoHTTPReasonUrl;
}
where kMAMIUrl = 'http://xslt.alexa.com/data?cli=17&dat=nsa'; and
kNoHTTPReasonUrl = kMAMIUrl + 'req_type=secure_intranet';.
Thus, when you're at a non-http:// url, we shortcircuit and just go to
http://xslt.alexa.com/data?cli=17&dat=nsareq_type=secure_intranet, which is the
`badurl' message that you see (go there and look).
So the choices here are:
* don't show anything at all in the What's Related Panel, that is, it would be
blank for non-http:// urls. I don't think this is a good idea; it doesn't tell
the user why he can't get What's Related urls for the site he's on.
* show our own message or webpage in this case.
* get Alexa to provide a more descriptive error message depending on the
req_type that we pass in (and we could provide more specific req_types than
just 'secure intranet', e.g. file_url, ftp_url, etc.).
I think the last option is the best. Reassigning to Matt because I have no
idea who the Alexa contacts are or how to get them to change this, cc'ing vishy
and johng.
Assignee: blakeross → matt
Status: ASSIGNED → NEW
Priority: P3 → --
Summary: shouldn't do what's related with file:// urls → More descriptive error message for non-http:// urls in What's Related
Target Milestone: mozilla1.0 → ---
|
|
||
Comment 7•24 years ago
|
||
Privacy leak and potential security hole, ccing mstoltz and nominating for
nsbeta1. I think the second option is best (we could discuss the specific
messages with Alexa, of course).
Keywords: nsbeta1
nav triage team:
Not important for beta1, marking nsbeta1-
|
||
Comment 10•24 years ago
|
||
*** Bug 70371 has been marked as a duplicate of this bug. ***
|
|
||
Comment 11•24 years ago
|
||
let's change kNoHTTPReasonUrl to
"data:text/html,<html><title>No Alexa</title><body><h1>Alexa only handles HTTP
urls</h1><p>You were visiting ... "
|
||
Comment 12•24 years ago
|
||
It's even unclear to what url the message is referred to.
open http://europe.cnn.com/SPECIALS/2001/mir/
then click on "size comparison" or any of the java panels links.
You get a badurl message while you are in front of a regular url. The
javascript link is out of sight.
In other words I think that "What's related" should refer to the url of the
mozilla's window it belongs to and not to the latest clicked link
|
||
Comment 13•24 years ago
|
||
Marking future since the bug is already marked nsbeta1-.
Target Milestone: --- → Future
|
||
Comment 14•23 years ago
|
||
*** Bug 75127 has been marked as a duplicate of this bug. ***
|
Reporter | |
Comment 15•23 years ago
|
||
works for me 20020115
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•