Build 3-18-99 WinNT - Go to above URL and click "link" - View this file using 4.51 and see the server name - View on 5.0, and see only the text outside the script tags Note for regression testing: referrer returns the URI of the page that linked to the page. The value is an empty string if the user navigated to the page directly (not through a link, but, for example, via a bookmark).

Also on Mac PPC

Moving to DOM Level 0. This is a property that existed in 4.x and before.

Umm...I thought we were done with M3. Jan, any reason for the change?

In the past, document.referrer was obtained from the URL_Struct. In Necko (Necco?), where would I look to find this information?

Necko isn't in yet, but you'd look for the server name using the connection object created for your request. More details come in when we land Necko.

Actually, the referrer is the URL of the page referring to the current one. Thinking about it a bit more, maybe this is information that WebShells can maintain, rather than relying (perhaps unreasonably) on netlib to do the right thing.

I dont agree with keeping the referrer cached in the document is the right thing. Cause this will fail on redirects. Several web sites on the net require you to refer from a specific opening page. (For example the adult ones require a warning page) This is accomplished thru redirects. So if you are on A, and you click on B, which redirects automatically to C, then C expects to see B as a referrer and not A. What you will be caching is A, and what you will get from Necko Magic is B. Make sense?

If Necko Magic can get this information for me, then great!

This one depends on Necko. Pushing off till M9 and post-Necko landing.

Let's get an update here. I suspect we want this fixed for beta, and now that Necko's in we might have a fighting chance. gagan: is the necko infrastructure in place? if so, could you give a short, sweet description of how to get the data? We can mark it HELP WANTED once we have something in here to guide people, and then vidur and I can duel for it if nobody else picks it up in time for beta.

Gagan/Rick: Do you think the referrer should be an attribute on http channel that the doc loader can set? Or should it be an argument passed into AsyncRead or the socket channel constructor? Rick/Judson: the docloader is going to have to propagate this into necko from the current document.

It occurs to me that this is information that can be propagated without Necko. The referring URL can be passed in as a parameter to LoadURL (the WebShell is both the caller and callee of LoadURL in the link clicking case).

Pam, Does image lib load urls too? I recall that it used to and that you set the referrer when appropriate. I was originally thinking that this was some sort of load group attribute? All urls in a load group are going to have the same root referrer url right? There's another referer bug out there but I can't find it. *** This bug has been marked as a duplicate of 7776 ***

the short/simple way to do this correctly is- get the channel in OnEndRequest, QI it to nsIHTTPChannel, and then do a- httpChannel->GetRequestHeader("Referer", &referer);

J: The imglib does load an url in IL_GetImage() [in if.cpp] through a call ic->net_cx->GetURL() which is ImageNetContextImpl::GetURL in nsImageNetContextAsync.cppp [in gfx]. In IL_GetImage.cpp there is code commented out which would add a referer. This was removed when the imglib was first 'BAMmed'. What should happen? Feel free to email me outside of the bug report or phone. -pn

Verified Duplicate