The 7-29-99 build doesn't redirect the browser to the proper page. To recreate yahoo.com. Click on stock quote, the link www.yahoo.com/r/sq goes into the location instead of finance.yahoo.com

The redirection is working fine, the problem is the Location Bar is not updated with the new URL. It is a 302 redirect. To reproduce, simply go to http://www.yahoo.com/r/sq You will be redirected to http://finance.yahoo.com/?u correctly but http://www.yahoo.com/r/sq is still in the Location Bar. Not sure who gets this, assigning to radha, cc'ing rpotts

*** Bug 1561 has been marked as a duplicate of this bug. ***

Maybe I don't know what I'm talking about, but wouldn't it be better if 302s showed the source rather than target in the location bar, so if you bookmarked them you'd get the source and could be redirected elsewhere when the 302 target changes? But then again, maybe the solution is to bring up a dialog listing the choices when you've been involved in 302s and try to bookmark the current page.

Or is that a 307. Looking at the HTTP 1.1 RFC, I can't see the diff between 302/307.

nsWebShell doesn't get notified in OnEndDocumentLoad for the redirected url. It only gets notified for the original url and a couple of xul files in navigator/content/default. Reassigning to warren. he fixed up few things in redirection code recently.

Cc'ing Gagan because he's dealing with another location bar updating issue. Currently I believe that we're adding the redirect URL to the same load group as the original, and then removing the original. This has the property of only doing the OnEndDocumentLoad when the redirected URL completes. Maybe we need to swap the order so that the OnEndDocumentLoad fires, and then reuse the group to being another load (although at that point we'd need the doc loader, not just its load group). Rick: Help.

More docloader madness. Reassigning to Rick since he's going to work with Radha on that.

using today's build on win98, I can't reproduce this bug, the redirect does update the location bar. Marking fixed

Marking Verified.

actually, this is not working for me on any platform, using M9 or M10 builds, re-opening. Again, the problem is simply the URL bar is not updated on a redirect to the new URL. The actual redirect is working correctly.

that being said, it does not seem remotely close to an M9 stopper, so moving to M10, unless someone objects...

The URL bar is failing to update on current Linux builds from the tip as well. Another example of this behavior is http://www.mozilla.org/NPL/ returning a redirect to http://www.mozilla.org/MPL/

m11

Gagan, since you're looking at progress/status notifications, you should probably take this one too. I assume there will be some redirect observer interface accessible from the event sink getter that you can call from the http protocol. Then, the docloader will receive it and pass it to the webshell to display.

*** Bug 15857 has been marked as a duplicate of this bug. ***

we dont implement any http event sink as yet... thats why we wont get the redirects. However I think we should really be checking for the uri in the onEndRequest or someplace and use that to update. Taking over but probably is webshell owners(!?!)

*** Bug 17131 has been marked as a duplicate of this bug. ***

so should rpotts, travis or buster get this? ->12

This really is the same roblem as in 10647. we need to change the webshell to also give us an HTTPEventSink to correctly handle redirects. I guess this should eventually be a factor in the new webshell design (so travis should know) but probably rpotts would be involved in the implementation. *** This bug has been marked as a duplicate of 10647 ***

Marking Verified as a dup.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

reopening, todays linux build exibits this problem. not opening the bug this was duped aginst since i can only see the symptom and not the cause. also note that if you manually enter the URL in the location bar, there is a differant effect. an html page from freshmeat is loaded, then a redirection occurs which works fine. only when the link is followed with a click does it not update the location bar. milestone reset

this is now just a dup. *** This bug has been marked as a duplicate of 30783 ***

Verified dupe.