Sorry, forgot to provide 'expected result' and 'what happens instead':

What is the expected result?
Chrome should send the referer header also when opening the link in a new tab.

What happens instead?
The header is not send :)

(No comment was entered for this change.)

Taking these to triage.

We need an automated test case for this.

 Issue 2482  has been merged into this issue.

Does this mean the "Referer" variable in HTTP Header is missing? If so, I think we 
need a server side script to test this.

It works fine in IE7 and Firefox304, but has same issue in Safari32.

To make the reduction work, an application server is needed to interpret jsp file and 
the href property of A tag in test-standard.html is also needed to change 
accordingly.

Will try to set up an internally accessible server later.

test-standard.html 465 bytes   Download

http-header-info.jsp 659 bytes   View   Download

Is the test in place?

Here is the test: http://go/1935-reduction

Ready for engineering.

Referrer, not Referer please.

(No comment was entered for this change.)

See the spec at http://tools.ietf.org/html/rfc2616#section-14.36 for the correct 
(mis)spelling.  :)

I wonder if Eric's work related to https://bugs.webkit.org/show_bug.cgi?id=20806 will 
change/fix this.  I am assigning this to him for comment.

Eric, if you have not fixed this then we need to upstream this bug to WebKit as it 
also happens on Safari.

This sounds similar to another bug that fixed:
http://code.google.com/p/chromium/issues/detail?id=3224
(ctrl-click / shift clicking links didn't send referrer):

jon:
Unfortunately 20806 is in limbo right now, still trying to get someone to review it...

ananta:
I am unable to load your reduction at http://go/1935-reduction

Ok, so the specific problem is opening a new tab/window via the context menu.

When you ctrl-click or shift-click the link, the navigation is initiated via the renderer, and as of http://code.google.com/p/chromium/issues/detail?id=3224 we set the referrer in the navigation.

HOWEVER, when you do the same action by having opened the context menu, the navigation is instead initiated by the browser, and the referrer at 
this point is not known:

The problem code is in render_view_context_menu_controller.cc:

    case IDS_CONTENT_CONTEXT_OPENLINKNEWTAB:
      OpenURL(params_.link_url, NEW_BACKGROUND_TAB, PageTransition::LINK);
      break;

    case IDS_CONTENT_CONTEXT_OPENLINKNEWWINDOW:
      OpenURL(params_.link_url, NEW_WINDOW, PageTransition::LINK);
      break;


Really OpenURL should be being passed a referrer for the link (otherwise it will default to none).

The right fix is probably to extract the referrer from the renderer, and include it in the params.
Note that the simple fix of using the current tab's URL as referrer is insufficient, since the link could have come from a subframe.


Assigning back to Jon for prioritization.



(The bug is in the chromium ui browser code, so removed the webkit and newhttp labels).

Loss of Referer is a big enough deal that I think we do need to fix it in 2.0.  As 
Eric has identified the problem as being in the browser I am setting the Area as 
Browser UI. 

(No comment was entered for this change.)

 Issue 9755  has been merged into this issue.

What's the status of this bug?

Bump http://sebastians-pamphlets.com/webkit-please-rescue-the-http_referer/

Noticed that chrome also does send the referrer information after a meta refresh. This 
behavior is not expected compared to other browsers. This gives everyone the 
opportunity to send referrer information regardless of user actions. Affiliates could 
use this method to redirect an adwords campaign directly to the affiliate advertiser. 
The advertiser will not be able to detect the possible scam because the referrer 
information is invalid. IE or FF consider that it should be empty.

What is your response to this?
http://sebastians-pamphlets.com/webkit-please-rescue-the-http_referer/

'Google Chrome' doesn't send Referrer while opening new tab.

Is this bug fixed? 

Couldn't this bug get a higher priority? Especially in the context of the rising 
adoptions of Google's First Click Free. It's pretty annoying to only get full content 
if the window was opened in same tab.

Area-UI-Features label replaces Area-BrowserUI label

Seconding comment 21: sending refer(r)er on META REFRESH is unexpected and - in my
opinion - incorrect.

Comment 21 is very important!
I have tested with:
In html:
<meta http-equiv="refresh" content="0;url=http://example.com"
This sends a HTTP_REFERER but must be blank.
in PHP:
header('Refresh: 0; url='http://example.com';
This sends a HTTP_REFERER but must be blank.
In html/javascript:
<body onload="location.href='http://example.com">
This sends a HTTP_REFERER but must be blank.
I think this is very important issue en must be soon resolved.
FF and IE are oke.

(No comment was entered for this change.)

(No comment was entered for this change.)

This also affects pages and extensions that use the document.referrer property.
The document.referrer property for clicks that open in a new tab is populated only 
after a ctrl-click, but not after a context-menu Open in New Tab.

I heartily agree with prioritizing this higher.

This is not a bug, it is a nice to have feature. There should also be a way to turn 
globally turn off referer headers, since clients do not actually have to supply a 
referer according to the RFC.

@beefsprocket You're dead wrong. I'm all for a way to turn off HTTP_REFERER headers, 
like in PrefBar, but generally sending those is expected behavior, IOW a quasi 
standard, therefore a *must have*. 

IDK about preferred stats tools for analytics (which reading the linked site seems to 
be the only reason to want the referer string). Expecting a browser to provide website 
operators with nice to have info as a quasi-standard borders on just plain 
entitlement. This is not a bug, it is a feature request. It shouldn't detract from 
more important bug fixing work.

@jamonation It's not only about analytics, and you obviously didn't read the article. 

Not sending the HTTP_REFERER breaks functionality. 

The current behavior totally irritates users. 

For example many sites protect the content in their members area by checking the 
referrer (I can think of better methods to implement hotlink protection, but that's 
reality). If the referrer is empty or points to another domain, then images, vids and 
whatnot aren't delivered to the user agent, often the request bounces to the login 
script. 

Now explain to a user why their browser behaves differently depending on the method 
used to open a link (e.g. left click vs. "open in new tab/window" from the context 
menu). That's a support nightmare, and pisses off both users and webmasters/site 
owners.

If Chrome would generally leave the HTTP_REFERER blank, then users who've paid for 
the content wouldn't use Chrome, but at least the behavior would be consistent. Site 
owners would just post a warning like "Chrome can't handle our site, please download 
IE6 here" or so. 

Not that I'd like to see the Web plastered with crap like that, but it would be the 
right thing to do if your "sending a referrer is nice to have, hence not important" 
take on this issue would be valid. Of course it's just uninformed, or based on 
ignorance, I don't know and honestly couldn't care less. Every experienced webmaster 
will tell you that you're dead wrong, provided you'd bother to ask before you speak 
out.

I disagree on the above suggested handling of the HTTP_REFERER after meta refreshs.

Un-delayed (0 seconds) as well as short-delayed (from my tests like 5 seconds or 
less) meta refreshs are handled like 301 redirects across the boards. For example all 
major search engines interpret such client sided redirects as a permanent redirect. 
More info:
http://sebastians-pamphlets.com/google-and-yahoo-treat-undelayed-meta-refresh-as-301-
redirect/
The same goes for JavaScript redirects by the way. All immediate client sided 
redirects are handled more or less equally to server sided redirects.

Regardless whether search engines handle immediate meta refreshs as 301 or 302, or 
even 307, the user is obviously not supposed to consume the current page, but the 
redirect's destination. The keyword is "redirect".

From a users's perspective, the technology used to redirect an HTTP request is not 
transparent. In other words, a user doesn't care whether the redirect is performed as 
a meta refresh or via HTTP response header. Webmasters on free hosts, blogging 
services etc often can't do server sided redirects, so they have to use meta 
refreshs.

Hence meta refreshs and alike, at least those that take the user to another resource 
within a very short period of time, should be handled as real redirects, that means 
the browser should send the URI where the user clicked a link as HTTP_REFERER.

Sorry for breaking the link. Here you go:
http://bit.ly/clzILH

I middle click to open a new tab.  Then right click on the same link and copy the 
link.  Then go to the new tab and paste the link into the address field.  

Middle click works fine in Foxfire, opening the correct link.

My vote is that this needs to be fixed.  This has been going on for awhile.  Why 
hasn't it been fixed?  And would it come out as an update to IE 8?

And how can we complain to IE 8 developers to get them working on a fix?