Overview: The first link on this Contents page, to the Preface, coded as <a href="http:preface.html">Preface</a>, is transformed into "http://preface.html/" in the Location bar by Mozilla instead of the intended "http://www.tuxedo.org/~esr/writings/taoup/preface.html" Also, the Contents page is not only still visible after "http://preface.html/" fails to load, but the "Preface" link still works, so additional attempts pile up in the Session History - clicking on [Back] as many times does work to return to the Contents page, but no feedback is given in the state of the Location Bar widgets that anything is happening. Steps to reproduce. 1. Load the page at the URL above (the "Contents page"). 2. Click on the first link, "Preface". 3. Observe the throbber, spinner, Location Bar, and the title. 4. Repeat step 2 a few times. 5. Click on [Back] as many times, then once more. Actual Results: A. The Location bar immediately shows "http://preface.html/". B. The throbber and spinner will be active for a while, then the [Stop] button grays. C. The Contents page will still be visible, and the Title bar will not show "Preface". D. The Contents page will remain visible through Step 4. E. The [Back], [Forward], [Reload] and [Stop] buttons give no feadback during step 5, until the Contents page is reached again. Expected Results: A. The Preface page, at "http://www.tuxedo.org/~esr/writings/taoup/preface.html" will load, and the title bar will change to "Preface". B. [Back]-navigation will work normally. Does not work correctly with: 2000-01-01-08-M13 nightly binary on Windows NT 4.0sp3 Works correctly with: NN 4.7 on Windows NT 4.0sp3 Additional Information: The relevant spec seems to be in section 5.2 of RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", <URL:http://www.ietf.org/rfc/rfc2396.txt>, which specifies steps to be taken to resolve relative URLs. The RFC discusses URLs of the form "http:preface.html" as follows: >(3) If the scheme component is defined, indicating that the reference >starts with a scheme name, then the reference is interpreted as an >absolute URI and we are done. Otherwise, the reference URI's >scheme is inherited from the base URI's scheme component. >Due to a loophole in prior specifications [RFC1630], some parsers >allow the scheme name to be present in a relative URI if it is the >same as the base URI scheme. Unfortunately, this can conflict >with the correct parsing of non-hierarchical URI. For backwards >compatibility, an implementation may work around such references >by removing the scheme if it matches that of the base URI and the >scheme is known to always use the <hier_part> syntax. The parser >can then continue with the steps below for the remainder of the >reference components. Validating parsers should mark such a >misformed relative reference as an error. This workaround is probably needed, early in the URL parsing. This is the converse of bug 19917, "4.xP Partial URLs of the form //hostname/path resolved wrongly", were the scheme is left out and the <net_path> and <path_segments> are left in. email@example.com, does the link to the "Preface" page work for you with the local fixes you made for bug 19917, or does this need more coding yet? QA: the problems with the SH observed after step 3 are almost certainly a distinct bug unrelated to the URL parsing code, but once the URL parsing is fixed, these problems are almost certain to be masked. This should really be a new bug, but who should get it? The same sort of problem showed up in bug 21005, "Unclosed <TITLE> completely blocks painting of canvas", before it was fixed (Actual Results:B) and in at least one other fixed bug, and apparently will continue to get triggered whenever the URL loading gets confused. Without its own report, this problem will never get fixed because the fix for new page loading problems will always mask it again.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
Yes, this is bug 22251 again - but this seems to have nothing to do with the <BASE> element - the same problem happens here without it. Marking this as a DUP of 22251. firstname.lastname@example.org, any ideas who should catch the problem of the previous page still being active, and the SH piling up load attempts? I'll write that up as a new bug for clarity - if I haven't done that by the time you are ready to VERIFY, this should show up in the diff to remind me! *** This bug has been marked as a duplicate of 22251 ***
No, my changes will not help here as I said in bug 22251. This one is really nasty, it goes completely against the current logic we have to detect relative URLs.
Verified dupe of 22251
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.