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)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: bugzilla, Assigned: matt)

References

(
URL
)

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..
-> me for an initial look..
Assignee: matt → blakeross
This looks similar to bug 53404, which is older, but has no additional comment.
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.9
Priority: P2 → P3
Target Milestone: mozilla0.9 → mozilla1.0
*** Bug 53404 has been marked as a duplicate of this bug. ***
How about making What's Related only see http urls?  I get the "badurl" message 
for finger and https urls, too.
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 → ---
*** Bug 55281 has been marked as a duplicate of this bug. ***
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-
Keywords: nsbeta1 → nsbeta1-
spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay
*** Bug 70371 has been marked as a duplicate of this bug. ***
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 ... "
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

Marking future since the bug is already marked nsbeta1-.
Target Milestone: --- → Future
Keywords: privacy
*** Bug 75127 has been marked as a duplicate of this bug. ***
works for me 20020115
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.