122668 - document.location=foo in bookmarklet sends current page as referer

Status: RESOLVED WONTFIX

(SeaMonkey :: Bookmarks & History, defect)

Description

[Nathanial Hendler]

I have an HTML page with a link on it that looks like this...

<a href='http://retards.org/bookmarks/redirect.php?id=783
redirect.php?id=783'
onmouseover='window.status="http://freshmeat.net/projects/apb/"; return true;'
onmouseout='window.status=""; return true;'>link</a>

The redirect.php script on my server sends the browser a redirect to
freshmeat.net in the header.  If I look at my server's logs, it will show that I
have a request for redirect.php and that the referrer is freshmeat.net.

This is because my Mozilla 0.9.7 browser is sending the wronge referrer.  I
don't know if it's the server redirect (using Location: in the header) or the
javascript that is screwing it up.  Basically, when I look at my server logs, it
says that every site that I go to using this method, has sent traffic to me,
which is clearly not the case.

Please let me know if there is anything else I can provide you with to help you
figure this out.  It isn't a problem with Mozilla 0.8

Thanks,
Nathanial Hendler
Tucson, AZ USA
http://retards.org/

Comment 1

[Darin Fisher]

Nathanial: can you provide a live testcase on the web?  or can you attach a
sample HTML document that can be used to demonstrate the problem.  thx!

Comment 2

[Nathanial Hendler]

Darin,

Ok, I started setting up a test page, and realized that my initial guess was
wrong.  There is a problem, but now I (think) I know how to help you duplicate it

In my 'Personal Toolbar Folder' I have a bookmark where the Location is a string
of javascript.  Here is what it looks like...

javascript:document.location =
'http://labs.retards.org/bookmarks/add_bookmark.php?form_title=' +
escape(document.title) + '&form_url=' + escape(document.location)

When I click this bookmark, it's supposed to take the title and url of the page
I'm on, and put it into form elements on my website.  When I do this, I get a
referrer for the page I was on in my website's logs.  Mozilla 0.8 didn't used to
do this, and other browsers haven't shown to do this either.

You should be able to add a bookmark to your personal toolbar folder and put the
above javascript in the Location field with it pointing to a server you have
access to the logs on, and reproduce the problem.

Thanks for looking into this.

PS - I was thinking the Summary of this bug should be changed to "Wrong referrer
info sent w/ javascript bookmark", but I didn't want to screw anything up.

Nathanial Hendler
Tucson, AZ USA
http://retards.org/

Comment 3

[Darin Fisher]

changed summary -> reassigning to badami for investigation.

vinay: this bug may be best owned by someone working on docshell or xpapps.

Comment 4

[Jesse Ruderman]

Here's a simple test:
javascript:document.location = "http://validator.w3.org/check/referer"; void 0

Nathanial, are you saying that you don't expect that bookmarklet to work?  I 
would expect it to work, because when you run a javascript: URL from a 
bookmark, you're running it as part of the page you're on.

Comment 5

[Nathanial Hendler]

> Nathanial, are you saying that you don't expect that bookmarklet to work?  I 
> would expect it to work, because when you run a javascript: URL from a 
> bookmark, you're running it as part of the page you're on.

I expect the bookmarklet to work, just not that way.  I expect a referrer to be
sent if a url was the referrer via a click on the actual page.  I don't expect a
page to be a referrer because a someone used a bookmarklet.  It seems like it
makes the whole referrer concept less useful.  The data becomes less valuable. 
My main problem with it is that it's never worked that way in the past, and no
other browsers that I've used show this behavior.

I would strongly urge the Mozilla team to change this behavior.  I assumed it wa
a bug, but I guess it was a design decicion.  Sorry if this shouldn't have been
submitted.

Nathaial Hendler
Tucson, AZ USA
http://retards.org/

Comment 6

[Jesse Ruderman]

The check/referer bookmarklet above works in Netscape 4 and in Opera 6.  It
doesn't work in IE 6 (which surprised me).

I understand how this makes referer information less valuable, but remember that
there are also bookmarklets that send you to URLs that *are* links within the
page.  Two examples are "search links" and "linked pages".  If the referers
weren't sent for the links and <img> tags generated by those bookmarklets, the
bookmarklets would stop working on some sites, especially porn sites.  

I think it's more important to keep those links working than to ensure that all
referers are "correct".  Also, since you own the site that your bookmarklet
sends you to, you can just ignore referers to that URL.

Comment 7

[Nathanial Hendler]

Jesse,

I think Javascript executed on (from within) a webpage should send the referrer
of that page.  Javascript executed because I selected something in my bookmarks
should not.  

If I'm on Mozzila's site, and I use my browser's bookmarks dropdown to go to a
porn site, when that porn site's webmaster looks at his logs, he's going to
think that Mozilla links to him.  I just don't see how that's the right way to
do things.

Also, regarding the part where you say "since you own the site that your
bookmarklet sends you to, you can just ignore referers to that URL."  I can do
that, but I've also helped write an open source online bookmark system, that
counted on this behavior of Mozilla, and IE (IE still behaves the way I expect).
It's used by several hundred people (I know, it doesn't compare to the number of
porn sites)

I just wonder about the issue with "keeping these sites working" when this
behaviour didn't exist in Mozilla 0.8 and doesn't exist in IE6.

If you're sure about your desicion to leave it as it, can there be a preference?
or switch or something?

Thanks,
Nathan
http://retards.org/

Comment 8

[Nivedita (gone)]

I think the behaviour indicated here is appropriate because, all the bookmarks 
are considered as links, hence they would have the Referer:  as the originating 
page. If some one thinks otherwise, please convey the same.

Comment 9

[Stuart Parmenter]

*** Bug 123293 has been marked as a duplicate of this bug. ***

Comment 10

[Jonas Jørgensen]

According to RFC 2616, section 14.36:
   "The Referer field MUST NOT be sent if the Request-URI was
    obtained from a source that does not have its own URI, such
    as input from the user keyboard."

A bookmarklet is a piece of JavaScript which I either type in manually or
copy'n'paste from somewhere else. It does NOT have its own URI, thus it should
not generate a Referer header. Confirming bug.

Comment 11

[Jesse Ruderman]

How can bug 123293 be a dup?  Bug 123293 says referrers aren't sent, and isn't
specific to bookmarklets.  This bug says referers should not be sent for
bookmarklets.

Most bookmarklets that load urls so do in one of the following ways:
1. Send the selected text to a search engine. (google, webster)
2. Send the url to a page using a query string. (latest wayback archive aka
de404, validate, blogdex)
3. Send something else from the page to a search engine. (collect buglinks)
4. Select one of the links on a page and going to it. (printer friendly)
5. Modify the url of the current page in a predictable way. (up, inc, dec)
6. Relist the links on the page in a different format. (search links, linked
images, linked pages)

In the first three cases, only a few popular search sites are affected.  A
little noise is added to their referrer logs, which isn't a big deal.  In the
last three cases, not sending the referrer would actually break stuff (like in
bug 123293).

IE seems to use a heuristic do differentiate between the cases:
document.location= is assumed to be a case where it's slightly better not to
send the referrer, but anything else (adding an img tag, document.writing a link
in a new window) is assumed to be a case where it's necessary to send the
referrer.  That means IE gets cases 4 and 5 wrong.  As a result, my inc and dec
bookmarklets don't work on porn sites in IE.

Comment 12

[Darin Fisher]

mass move of bugs assigned to vinay to me

Comment 13

[Jesse Ruderman]

See also bug 93885.

Comment 14

[Darin Fisher]

mass futuring of untargeted bugs

Comment 15

[u60234]

*** Bug 182640 has been marked as a duplicate of this bug. ***

Comment 16

[benc]

from bug 93885:

------- Additional Comment #5 From Johnny Stenback  2001-09-30 17:09 -------

javascript: URL's in the URL bar have everything to do with the current page,
that's just how it works, in mozilla, and in all other browsers. Try
javascript:alert(window.location.href) in any browser and you'll get the URL of
the current page.

WONTFIX, again.

If that is the case

--
This is a problem w/ bookmarks thinking that it can safely send a javascript URL
to the URL bar.

If you use a normal URL in the URL bar, the current page is not sent as the
referer, this problem only happens w/ javascript: URLs.

-> bookmarks. I guess they'll have to add some logic to support this, or
convince Johnny to change javascript:

BTW, I suggest you change the summary emphasis that it sends the current page
URL. Just sending any incorrect URL for Refer: is not going to sound nearly as
serious.

Comment 17

[Jesse Ruderman]

Not sending the referer when a bookmarklet does document.location=foo would
break several bookmarklets, as I described in comment 11.  We've already seen an
example of not sending referers (in a different case) breaking bookmarklets: bug
123293 (now fixed).

Re comment 10:
A bookmarklet is not a "source that does not have its own URI".  A bookmarklet
is JavaScript that is run as if it were part of a web page.

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 209029 has been marked as a duplicate of this bug. ***

Comment 19

[Boris Zbarsky [:bzbarsky]]

See bug 209029 comment 1, which basically says exactly what comment 16 says...

Comment 20

[Jesse Ruderman]

*** Bug 234736 has been marked as a duplicate of this bug. ***

Comment 21

[Ray Booysen]

Reassigning as per Bug #32644

Comment 23

[Philip Chee]

WONTFIX: See Comment 16