Closed Bug 30783 Opened 25 years ago Closed 24 years ago

location bar needs updated on redirects.

Categories

(Core :: Networking: HTTP, defect, P3)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mscott, Assigned: mscott)

References

Details

(Whiteboard: [nsbeta2-][PDT-][nsbeta3+]) 

This fell out of Bug #27048. If you visit a url that's a redirect, the page
loads correctly and all the links (both relative and absolute) get resolved
correctly.

However, the actual location bar itself doesn't get updated with the new url.

PDT would like us to fix this by 3/8 if we can.
Nominating for beta1 per discussion with PDT team.
Status: NEW → ASSIGNED
Keywords: beta1
Target Milestone: M14
Looks like this may be related to 10647.  Changing component to Networking.
Component: Browser-General → Networking
[PDT+] w/b minus on 3/8
Whiteboard: [PDT+] w/b minus on 3/8
Travis was telling me that proper implementation of this feature requires
landing his new nsIWebProgress interface. We probably don't want to take that
for beta at this point in the game just to pick up this problem.

Unless I can think of a hack, don't hold your breath that we'll get this for
beta (esp by tomorrow 3/8)

*** Bug 30987 has been marked as a duplicate of this bug. ***
Per comment about needing webshell landing to get this right... and having
passed 3/8... transitioning to PDT- for beta1, plus for beta2
Whiteboard: [PDT+] w/b minus on 3/8 → [PDT-] plus for beta2
Moving my remaining M14 bugs to M15 which is the next targeted milestone.
Target Milestone: M14 → M15
*** Bug 32233 has been marked as a duplicate of this bug. ***
Blocks: 31863
not a m15 stopper.
Target Milestone: M15 → M16
Taking this bug and marking it as a dependency on my other one 33870
Assignee: mscott → travis
Status: ASSIGNED → NEW
Depends on: 33870
Should be fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Putting on beta2 keyword radar since this was "plus for beta2" during beta1 
triaging
Keywords: beta2
Keywords: nsbeta2
Why was this bug marked for OS other? Bug 27048 from which this is derived has
OS all, marking this likewise. If there's a good reason it should be other,
please correct me.

Works for me too on both Win 95 2000042708 and Linux 2000042709, so marking
verified fixed.
Status: RESOLVED → VERIFIED
Keywords: beta2
OS: other → All
seeing this again now.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Putting on [nsbeta2-] radar.  PR2 is way outta here.  Putting on nsbeta3 nominee 
radar.
Keywords: nsbeta3
Whiteboard: [PDT-] plus for beta2 → [nsbeta2-][PDT-] plus for beta2
With an 0823 build Mozilla actually displayed the right URL after a redirection
from http://localhost/foo to http://localhost:8100/ but only a couple of times.
Mostly it shows the first URL. Perhaps there's a timing issue somewhere.
->mscott
Assignee: travis → mscott
Status: REOPENED → NEW
nsbeta3+ per triage meeting.
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2-][PDT-] plus for beta2 → [nsbeta2-][PDT-][nsbeta3+]
*** Bug 10926 has been marked as a duplicate of this bug. ***
This should be fixed in tomorrow's builds. Thanks dp. 
forgot to mark it as fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
-> http
Component: Networking → Networking: HTTP
QA Contact: asa → tever
Verified.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.