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

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 2

[Andreas Otte]

I will look into this

Comment 3

[Andreas Otte]

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.

Comment 4

[Andreas Otte]

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

Comment 5

[Andreas Otte]

Attachment: This patch fixes the problem for me.

Comment 6

[Warren Harris]

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

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.)

Comment 9

[Andreas Otte]

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.

Comment 10

[Andreas Otte]

Attachment: Another shot at the problem, it's working fine for me with this (no Back problems, complete spec checked)

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

And then there's the problem that the comparisons on protocol and host should be
case insensitive...

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I *think* radha checked in the attached fix, because it fixed another bug too...
This should probably be marked fixed.

Comment 13

[Gagan]

well... looks like this is resolved then.

Comment 14

[leger]

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

component.

Comment 15

[Tom Everingham]

verified: Linux 2000040307