119478 - [FIX]Referer not sent when using the Site Navigation toolbar

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Henrik Gemal]

The Referer is not sent when I navigate a site using the Site Navigation toolbar.
I have a toolbar which include a link to http://validator.w3.org/check/referer
but it doesn't work since Referer is not sent when I press the link in the Site
Navigation toolbar.

build 20020111

Comment 1

[Stuart Ballard]

Adding to the linktoolbar-uber-meta-bug.

This seems like a valid bug, and it seems to be related to the issue that keeps
coming up: There is no way to programmatically (using XP-connectable JS
interfaces) do the exact same thing that clicking on an <a href> link does. This
covers things like target="foo" and security checks as well as supplying a
referer.

Ideally I'd like to see this fixed by exposing the exact operation, equivalent
to clicking on an <a href> link, to some JS-accessible interface
(nsIWebNavigation?).

Comment 2

[Darin Fisher]

this bug then belongs to the site navigation folks... they need to ensure that
they are setting an referring URL on the http channel that gets created as a
result of the link click.  see nsIHttpChannel::SetReferrer for details.  perhaps
the solution is just a matter of poking docshell in the right way?!?

-> XP Apps for starters... i don't know who owns the Site Navigation Toolbar

Comment 3

[Stuart Ballard]

XPApps is right afaik. The issue is that we use nsIWebNavigation to click the
link, and last time I checked that didn't support "target", security checks, or
referer, so all those things have to be done manually. Right now we just do the
security checks.

Comment 4

[Peter Trudelle]

->rpotts, who seems to own the interface at least.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to fix

Comment 6

[Boris Zbarsky [:bzbarsky]]

The attached patch fixes this bug, but depends on the infrastructure added in
the patch that fixes bug 48902.  With that in mind, Stuart, would you review?

Taking bug

Comment 7

[Stuart Ballard]

I don't suppose you want to implement the same magic for "target", do you? :)

The patch looks good, but since I don't have the capability to build I'll have
to wait till bug 48902 appears in nightlies before I can test this. I'll do a
full review then.

Do you have any answer to my comment #1 - as to why it's so damn hard to emulate
the (seemingly trivial) behavior of "clicking a link" from JS? I can't help but
feel that it's something that comes up often enough that it should be a simple
API: eg document.loadURI(href, target) that would do the security check, set the
referer, use the right target frame/window, and all that stuff that we currently
have to work so hard to get right. IMHO, the behavior when a user *actually*
clicks a link should go through the same codepath as when it's invoked
programmatically, eg by the linktoolbar.

Comment 8

[Henrik Gemal]

Stuart: I think you should file a bug about that issue...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 65797 [details] [diff] [review]
Patch to fix

adding target is simple enough.  Will do once bug 48902 lands, since the change
will cause conflicts with that patch.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 65797 [details] [diff] [review]
Patch to fix

OK. well, looks like I got confused.  There is no
scriptable way to set target yet... can we fix
this and file a separate bug (on rpotts) to support
a scriptable target?

reviews, again?

Comment 11

[Christopher Hoess (gone)]

Comment on attachment 65797 [details] [diff] [review]
Patch to fix

r=choess

Comment 12

[Blake Ross]

Comment on attachment 65797 [details] [diff] [review]
Patch to fix

sr=blake

Comment 13

[Boris Zbarsky [:bzbarsky]]

checked into trunk

Comment 14

[Henrik Gemal]

v 20020221