10926 - 301/302 Redirects don't update location Bar

Status: VERIFIED DUPLICATE of bug 30783

(Core :: Networking, defect, P3)

Description

[solomonr]

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

Comment 1

[Paul MacQuiddy]

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

Comment 2

[Paul MacQuiddy]

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

Comment 3

[Matthew Tuck [:CodeMachine]]

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.

Comment 4

[Matthew Tuck [:CodeMachine]]

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

Comment 5

[Radha on family leave (not reading bugmail)]

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.

Comment 6

[Warren Harris]

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.

Comment 7

[Warren Harris]

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

Comment 8

[rubydoo123]

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

Comment 9

[leger]

Marking Verified.

Comment 10

[Paul MacQuiddy]

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.

Comment 11

[Paul MacQuiddy]

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

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

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/

Comment 13

[chris hofmann]

m11

Comment 14

[Warren Harris]

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.

Comment 15

[cls]

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

Comment 16

[Gagan]

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(!?!)

Comment 17

[Paul MacQuiddy]

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

Comment 18

[chris hofmann]

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

Comment 19

[Gagan]

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 ***

Comment 20

[leger]

Marking Verified as a dup.

Comment 21

[leger]

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

component.

Comment 22

[Jeremy M. Dolan]

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

Comment 23

[Gagan]

this is now just a dup.

*** This bug has been marked as a duplicate of 30783 ***

Comment 24

[Scott Brodmerkle]

Verified dupe.