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)
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.
Reporter | ||
Comment 1•25 years ago
|
||
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•25 years ago
|
||
I will look into this
Comment 3•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Whiteboard: FIX ATTACHED
Reporter | ||
Comment 7•25 years ago
|
||
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.
Reporter | ||
Comment 8•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
Reporter | ||
Comment 11•25 years ago
|
||
And then there's the problem that the comparisons on protocol and host should be case insensitive...
Reporter | ||
Comment 12•25 years ago
|
||
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
Assignee | ||
Comment 13•25 years ago
|
||
well... looks like this is resolved then.
Comment 14•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
You need to log in
before you can comment on or make changes to this bug.
Description
•