Incorrect base URL used on redirected pages

VERIFIED FIXED

Status

()

defect
P3
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: dp, Assigned: gagan)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dogfood+])

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
This has happened to me many times now. I would click on a link or do a form
post and the url beta2 goes to would be missing a component. If I do it again,
it would work.

Like now: I went to http://lxr.mozilla.org , pasted some text and hit [Text
Search]. The url this resolved to the first time around was:

http://lxr.mozilla.org/search?string=09f689e0-b4da-11d2-a68b-00104bde6048

instead of

http://lxr.mozilla.org/seamonkey/search?string=09f689e0-b4da-11d2-a68b-00104bde6048

But then, I try again, it works now.
(Reporter)

Comment 1

19 years ago
Nominating for beta3.
Keywords: nsbeta3

Comment 2

19 years ago
Happens with Linux M18 2000-08-08-20 also.  Tested on
http://www.w3.org/TR/html4/ .  Clicking on the link for "Tables" the first time
takes me to http://www.w3.org/TR/struct/tables.html .  Clicking the second time
takes me to http://www.w3.org/TR/html4/struct/tables.html

This is dogfood.

Comment 3

19 years ago
*** Bug 48795 has been marked as a duplicate of this bug. ***

Comment 4

19 years ago
I can't provide a reliable test case, but I can definitely vouch for the
presence of this bug. I have mostly seen it shortly after user authentication,
esp. with Apache 1.3.13-dev, although I imagine it happens with other servers too.

Comment 5

19 years ago
The w3c.org page is a reliable testcase.

Comment 6

19 years ago
*** Bug 48843 has been marked as a duplicate of this bug. ***

Comment 7

19 years ago
not seen on win95
Keywords: pp
The problem can be reproduced by going to:
http://lxr.mozilla.org/seamonkey
instead of
http://lxr.mozilla.org/seamonkey/

The former HTTP-redirects to the latter.  (I think it may be that once the page
is cached in session history as the latter things are OK.)

I really think I've seen a bug on this before, but I can't find it.  This is not
at all specific to form submission - when the page is loaded by the first URL,
all the relative URLs on the page are wrong (e.g., the "mozilla/" link is to
http://lxr.mozilla.org/mozilla/ instead of
http://lxr.mozilla.org/seamonkey/mozilla/ .
Summary: Sometimes we form the wrong url → Incorrect base URL used on redirected pages
See also: bug 32359, bug 48385
Exactly the same as this bug (I think):  bug 48885, bug 48927.

Considering the bug#s, this seems like a regression.

Comment 10

19 years ago
*** Bug 48927 has been marked as a duplicate of this bug. ***

Comment 11

19 years ago
This bites me all day while I'm trying to testcase, triage, and dupe bugs. 
Nominating for dogfood consideration.  Note that duplicate bug 48310 was already
approved for dogfood+.  Also dupes are reported on other platforms -> all/all.

Please when trying to reproduce, carefully note trailing slashes.  My initial
reproduction steps should have been these:

1) http://www.w3.org/TR/html4
2) Click on "Tables"
Keywords: ppdogfood
OS: Linux → All
Hardware: Other → All

Comment 12

19 years ago
*** Bug 48310 has been marked as a duplicate of this bug. ***
Old bugs on the issue:  bug 3134, bug 10647
Still open:  bug 27048.  [is this a dup?]
Related: bug 30271
Keywords: dogfoodpp
OS: All → Linux
Hardware: All → Other
Keywords: ppdogfood
OS: Linux → All
Hardware: Other → All

Comment 14

19 years ago
*** Bug 48405 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
carrying over dogfood+ from bug 48310. Here's leger's comment from when
she marked it dogfood.

>------- Additional Comments From leger@netscape.com 2000-08-14 14:29 -------
>
>Putting on [dogfood+]...we need this fixed for daily work. ckritzer, how does 
>this look on all platforms with Aug 14 builds?
Whiteboard: [dogfood+]
This bug is still present in linux 2000081505.

Comment 17

19 years ago
Seems to have been fixed in MacOS 2000081504.

Comment 18

19 years ago
Yet, the URL displayed in the task bar below upon mouseover (ex.1) and the URL in 
the location window after clicking the linke (ex.2) are somewhat weird.
1)http://www.w3.org/TR/html4#minitoc
2)http://www.w3.org/TR/html4/#minitoc

Comment 19

19 years ago
Wrong. The bug is still present in Mac OS 2000-081504.  Sorry for the confusion.  
The link only worked when the browser went back to the page from another page 
whereupon the thrash was added to the URL in the location window.

Comment 20

19 years ago
*** Bug 49282 has been marked as a duplicate of this bug. ***
*** Bug 48674 has been marked as a duplicate of this bug. ***

Comment 22

19 years ago
*** Bug 49353 has been marked as a duplicate of this bug. ***

Comment 23

19 years ago
*** Bug 49321 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

19 years ago
*** Bug 49264 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 25

19 years ago
*** Bug 48527 has been marked as a duplicate of this bug. ***

Comment 26

19 years ago
Could be the good old problem that we are not updating the url after a redirect
(from http://host/path to http://host/path/)
(Assignee)

Comment 27

19 years ago
yup thats what it is... am looking to see what caused the regression. 
(Assignee)

Comment 28

19 years ago
*** Bug 48636 has been marked as a duplicate of this bug. ***

Comment 29

19 years ago
*** Bug 49599 has been marked as a duplicate of this bug. ***

Comment 30

19 years ago
Let's make sure and check all of these dupes when the bug resolves.  Almost all
of them have given the URLs where they had the problem.

Comment 31

19 years ago
*** Bug 49344 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Keywords: mostfreq
(Assignee)

Comment 32

19 years ago
I can't seem to locate what caused the regression but the problem here is
essentially that on a redirected page all the links carry the the baseURI of the
original page and hence a ton of things break. Necko is doing the right thing
here but its just that we don't get the right baseURI to make abs them
correctly. 

Ccing all the relevant people who might have a clue as to what changed in
docshell that caused this. mscott any ideas?
(Assignee)

Comment 33

19 years ago
*** Bug 49488 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 34

19 years ago
Finally figured out whats going on here. hyatt's recent checkins to change 
GetURI to GetOriginalURI (in nsDocument::Reset()) broke the mechanism. I have a 
fix but this is in hyatt's code so I have to get it reviewed from him. Will 
attach the diffs here.
(Assignee)

Updated

19 years ago
Keywords: patch
(Assignee)

Comment 36

19 years ago
*** Bug 22886 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 37

19 years ago
*** Bug 48270 has been marked as a duplicate of this bug. ***

Comment 38

19 years ago
*** Bug 49711 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 39

19 years ago
*** Bug 49552 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Blocks: 49547

Comment 40

19 years ago
*** Bug 49736 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 41

19 years ago
fix checked in. r=hyatt
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
*** Bug 49798 has been marked as a duplicate of this bug. ***

Comment 43

19 years ago
*** Bug 49795 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Blocks: 49460

Comment 44

19 years ago
Looking at build 2000082208, the fix appears to have corrected the immediate 
problem, but may have introduced a new one. Prior to this build, the URL 
displayed in the navigation toolbar was being changed to the redirected value 
(which I believe is the desired behaviour). But with this build, the displayed 
URL remains in its original form, rather than the redirected one.

For example, if I enter the URL "http://www.ento.csiro.au/ice2004", the page now 
renders correctly, but the URL in the navigation bar continues to read 
"http://www.ento.csiro.au/ice2004", rather than 
"http://www.ento.csiro.au/ice2004/" (that trailing backslash is the bit that 
should change...)

Comment 45

19 years ago
Yes, I see this new problem as well.  Reopening and modifying summary line from:

   Incorrect base URL used on redirected pages

to

   Incorrect URL displayed for redirected pages
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Incorrect base URL used on redirected pages → Incorrect URL displayed for redirected pages
(Assignee)

Comment 46

19 years ago
Nope that is a separate bug (I have reopened bug 30783) and am setting the 
status back to what the original problem was. And closing this. 
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
Summary: Incorrect URL displayed for redirected pages → Incorrect base URL used on redirected pages

Comment 47

19 years ago
verified
Linux 2000082508
Win NT 2000082508
Status: RESOLVED → VERIFIED

Comment 48

19 years ago
*** Bug 50750 has been marked as a duplicate of this bug. ***
*** Bug 50284 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.