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/

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!

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/

changed summary -> reassigning to badami for investigation. vinay: this bug may be best owned by someone working on docshell or xpapps.

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.

> 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/

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.

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/

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.

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

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.

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.

mass move of bugs assigned to vinay to me

See also bug 93885.

mass futuring of untargeted bugs

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

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.

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.

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

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

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

Reassigning as per Bug #32644

WONTFIX: See Comment 16