Steps to reproduce: 1. Go to http://neat.jpl.nasa.gov/. 2. Click or middle-click a link to one of the jpgs. 3. Admire the tic-tac-toe pattern. 4. javascript:alert("Referrer: " + document.referrer); Result: empty string Expected: http://neat.jpl.nasa.gov/ Mozilla does know the referrer, since reloading works correctly on porn sites that require referrers. It's just not exposing it to the DOM of the page constructed around the image. This bug breaks the "go to referrer" bookmarklet, which is used to return from an image to a thumbnail gallery that was accidentally closed. The bookmarklet works correctly in IE, Netscape 4, and Opera.

I'll take this; this is pretty simple to fix.

Dup of bug 96485 or bug 123293 ?

Dupe 96485. 123293 is asking to fake the referrer for Pornzilla.

This is not a dup of 96485 or 123293. Those bugs are about Mozilla sending incorrect/no referrers to servers in two cases, while this bug is about letting javascript see the referrer in a third case.

This is basically a copy/paste from nsHTMLDocument::StartLoad(). Jesse, care to review?

Comment on attachment 89821 [details] [diff] [review] Patch to fix sr=jst, but what about non-ASCII characters in the referrer? UTF-8? Or do we just don't care for now?

nsHttpChannel uses GetAsciiSpec to get the referrer string from the nsIURI object. So what we're doing here is fine... (the string is just URL-encoded)

Comment on attachment 89821 [details] [diff] [review] Patch to fix r=sicking

fixed on trunk.