This appears to be a regression since Eric Krock told me he doesn't see this problem with the 6/10 build. I'm running today's build 6/16. On this page: http://www.e-saito.com/a6_pics/ Relative links point one level up in the hiearchy. For example: <br><font face="Arial,Helvetica"><font size=-1><a href="hardened_hangars.jpg">Hardened aircraft hangars</a></font></font> Generates: http://www.e-saito.com/hardened_hangars.jpg Instead of: http://www.e-saito.com/a6_pics/hardened_hangars.jpg Everything works OK with 4.61 too.
this works fine for me on 990616 build - win95
The bug appears to be intermittent. I just went back to the site with the June 16 build and the pages loaded fine. I then went to mozilla and back to the page and then had the link problem. I have screen shots that compare seamonkey and 4.6 if you want to see the difference. Look at the URL at the bottom of each: Seamonkey: http://www.e-saito.com/bug_sm.jpg Nav 4.6: http://www.e-saito.com/bug_46.jpg
This bug affects both the actual link that gets loaded and the displayed link.
I'll start looking at it for M7. Jan's right - this sounds bad enough that it could be a M7 stopper.
I think I have reproduceable steps. I'm running a P166 w/Win98. 1. Launch apprunner - opens to mozilla 2. type www.e-saito.com 3. click on pictures of A-6 link 4. click on "hardened hangars" link 5. picture loads OK 6. click on blue mozilla icon in upper right corner and go to mozilla.org 7. repeat steps 2-4 8. link is incorrect and goes to wrong page
Status: NEW → ASSIGNED
Component: DOM Level 0 → Networking Library
The problem comes about when netlib doesn't put in the trailing slash for the URL specified. The relative URLs are resolved relative to the document URL. If the document URL is missing the trailing slash, the "a6_pics" component is treated as a file name and stripped out in the resolution code. My current theory is that the trailing slash isn't included when the file is coming out of the cache.
m8 -> necko landing
The problem occurs when we try to get the URL out of the cache. The cache code is modifying the URL spec, but not setting the address_modified flag which is later used to sync up the nsIURL wrapper with the underlying URL_Struct. The proposed patch sets the address_modified flag when the URL is found in the cache by adding the trailing slash. Gagan, I'm forwarding the bug to you to approve the patch. I think this should go into M7 (cc:ing chofmann). If it goes into M8, we might as well wait for Necko.
approved patch if it fixes the problem.
vidur...if ya checked this in last night could you mark Resolved/Fixed? Thanks!
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Fixed checked in on 6/18/99.
Working fine now. Marking verified.
Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)
Bulk move of all Networking-Core (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.