517316 - Opening non-hyperlinked URLs (using context menu) should not send referrer

Status: NEW

(Firefox :: Menus, defect)

Description

[Jesse Ruderman]

See bug 454518 comment 17.  Bug 515932 added a mechanism that may help here.

Comment 1

[Nochum Sossonko [:Natch]]

Is this suppose to encompass the link (real <a href=) context menu as well? Afaik, the non-hyperlinked context menu uses the same function to do this. Is it wrong to send the referrer on non-hyperlinked urls, but correct to send them when using a real link (which is being opened via the context menu on the link, in a new tab/window, not through direct click-through)?

What about right-click, choose "Copy Link Location", then load it into the browser, or drag-n-drop the link on the tab bar?

Specifically, is there a spec saying when and when not to send the referrer, or is this just common convention?

Comment 2

[Jesse Ruderman]

Referrer should be sent if you right-click a hyperlink and select "open in new tab", but not if you right-click selected text and do the same.  I think it's just convention.

Comment 3

[Mike Connor [:mconnor]]

Reasoning would be good here...

Comment 4

[Jesse Ruderman]

Bug 454518 comment 20 argues it about as well as I could.

Comment 5

[Alex Bishop]

(In reply to comment #1)
> Is this suppose to encompass the link (real <a href=) context menu as well?

No.

> Afaik, the non-hyperlinked context menu uses the same function to do this.

That can be changed.

> Is it wrong to send the referrer on non-hyperlinked urls

Yes.

> but correct to send them when using a real link (which is being opened via
> the context menu on the link, in a new tab/window, not through direct click-
> through)?

Yes. Whether it's done by clicking or using the context menu, it's still direct interaction with the link (recall that using the 'Open Link in New Tab' context menu item is identical to middle-clicking or holding down Ctrl/Cmd while clicking the link).

> What about right-click, choose "Copy Link Location", then load it into the
> browser

Shouldn't send a referrer because it's not a direct interaction (it's extracting data from the link and then using it for later input, which is two distinct steps).

> or drag-n-drop the link on the tab bar?

I would have said that if it was a real link, this should send a referrer but I just checked and that doesn't happen. I guess you could argue that drag-and-drop isn't a direct interaction (it's another case of extracting data and using it as later input), so I can accept that.

Dragging and dropping a plain text URL on the tab bar should never send a referrer.

> Specifically, is there a spec saying when and when not to send the referrer,
> or is this just common convention?

I'm not aware of anything authoritative and the relevant bit of the HTTP 1.1 spec (RFC 2616 section 14.36) is a bit vague.

However, I think referrers should be sent only when the referring page has established a direct, actionable association with the target URL, either by offering a real link or by incorporating the target URL in some way (e.g. loading it into an img or iframe element). Just including a plain text URL (which, if bug 515512 is fixed, might be as simple as a domain name like www.mozilla.org) isn't a strong enough association.

Think about it from the perspective of the target page, which will actually receive the referrers. If I were running such a page, I would expect any referrer URLs to belong to pages that were either linking directly to my page or incorporating it in some way (img or iframe element etc.). I wouldn't expect any of them to just mention my URL in plain text.

Comment 6

[Alex Bishop]

Now that bug 515512 is fixed, it seems that URLs with a scheme (like http://www.mozilla.org/) have a referrer sent but URLs without (like www.mozilla.org) do not. Which is just inconsistent.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to Alex Bishop from comment #6)
> Now that bug 515512 is fixed, it seems that URLs with a scheme (like
> http://www.mozilla.org/) have a referrer sent but URLs without (like
> www.mozilla.org) do not. Which is just inconsistent.

Are you sure? Bug 515512 shouldn't have had any effect here, AIUI. We don't do anything special based on whether there's a scheme or not for "plaintext" links.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

Not tested, and contains some gratuitous cleanup, but I think this should do the trick. Needs tests!

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch