Closed Bug 15315 Opened 25 years ago Closed 25 years ago

relative links with fragments don't work if base URL ends in "/"

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: gagan)

References

()

Details

(Whiteboard: FIX ATTACHED)

Attachments

(2 files)

DESCRIPTION:  In http://www.fas.harvard.edu/~dbaron/sat/na/ , the relative links
with fragment identifiers (all the links in the bulleted list) don't work.  If I
use the URL http://www.fas.harvard.edu/~dbaron/sat/na/index.html (the same page)
they work correctly.

I think this problem is specific to relative links with fragment identifiers.
However, it also occurs within frames, even when the frame URL does not end in
"/" (although the frameset URL does).

STEPS TO REPRODUCE:
 * Load http://www.fas.harvard.edu/~dbaron/sat/na/
 * Click on a link in the bulleted list, e.g., "Colorado State University"

EXPECTED RESULTS:
 * Different page loads and goes to "Colorado State University" section

ACTUAL RESULTS:
 * nothing happens

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-09-29-08-M11
 * Linux, viewer, 1999-09-29-08-M11

WORKS CORRECTLY ON:
 * Most other browsers

ADDITIONAL INFORMATION:

An alternative way to reproduce (with frames) is to
 * go to http://www.fas.harvard.edu/~dbaron/sat/frames.html.en
 * click on "N & S American Images" in the upper left
 * click on "Colorado" in lower left ... nothing happens.
Three more points:
 * I checked that the problem is specific to relative links by adding a link to
http://www.yahoo.com/index.html#test in the above page.  I can't leave it there
forever, though.
 * It's clear it only happens with fragment identifiers because the other
relative links in the page (i.e., at the bottom), work.  (Unless it's specific
to a certain type of relative link, but I don't think so: see
http://www.fas.harvard.edu/~dbaron/sat/asia/ or
http://www.fas.harvard.edu/~dbaron/sat/siteinfo/ )
 * My comment above about the frameset URL ending is "/" was erroneous.  It
clearly doesn't.
I will look into this
I don't think this is an urlparser bug or even a necko bug. The relative url is
correctly parsed (can be observed at the status line), the link is simply not
executed.

The funny thing is: If you click once on one of the non working links, then use
one of the working links on the bottom of the page, then hit the back-button,
the previously not loaded page is suddenly loaded.
This bug is based on the nsWebShell static PRBool EqualBaseURLs(nsIURI* url1,
nsIURI* url2) implementation. It thinks too often that urls are equal,
especially when one is part of the other. This happens for example if the base
url is without filename (implicit index.html) and the reference has one. It
searches then for the anchor in the current document ...
Whiteboard: FIX ATTACHED
*** Bug 13759 has been marked as a duplicate of this bug. ***
This bug (as reported, but not necessarily the problem in the code) seems to
have been fixed between the builds of 10-05 and 10-08, replaced by a new
problem.  Now, the links in http://www.fas.harvard.edu/~dbaron/sat/na/ work, but
hitting back from one of them (for example "Colorado State...") doesn't work -
it just moves to the top of the page.

This is what I see in Linux apprunner 1999-10-08-08-M11 and 1999-10-11-08-M11.

See also bug 15441.
I was looking at that code that Andreas Otte submitted a patch - and it looks
like there could be some other problems with it.  For example, it doesn't seem
to check the protocol, the port, or possibly the "search" part of the URL - the
nsIURL interface isn't completely clear to me, and it doesn't seem too well
documented.  Could this cause problems going from, say: http://www.eb.com/ to
http://www.eb.com:180/ or from http://psych.upenn.edu/ to
gopher://psych.upenn.edu/ ?  Should it be using the URL interfaces more, rather
than parsing the URL itself?

(Well, now that I look, I see a problem in the 10-03 builds with the
http://www.eb.com to http://www.eb.com:180/ that I mentioned.)
You are right, my fix changed it from nearly non working to half working. The
whole URL has to be checked, not only host and path (path includes param and
query). I will do another fix.

There is also an interesting problem with SessionHistory and failed loads of
URLs. Sometimes you see failed loads of urls (sometimes just successfully
visited) which are immediatly followed by a successfull load. However one entry
from the SessionHistory is missing after that and Back goes back two steps.
Maybe this is related.
And then there's the problem that the comparisons on protocol and host should be
case insensitive...
I *think* radha checked in the attached fix, because it fixed another bug too...
This should probably be marked fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
well... looks like this is resolved then.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
verified: Linux 2000040307
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: