Closed
Bug 8353
Opened 25 years ago
Closed 25 years ago
Relative links point to wrong directory
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
M7
People
(Reporter: chriss, Assigned: gagan)
References
()
Details
Attachments
(1 file)
549 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M7
Comment 4•25 years ago
|
||
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
Updated•25 years ago
|
Status: NEW → ASSIGNED
Component: DOM Level 0 → Networking Library
Comment 6•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M7 → M8
Comment 7•25 years ago
|
||
m8 -> necko landing
Comment 8•25 years ago
|
||
Updated•25 years ago
|
Assignee: vidur → gagan
Status: ASSIGNED → NEW
Comment 9•25 years ago
|
||
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.
Assignee | ||
Comment 10•25 years ago
|
||
approved patch if it fixes the problem.
Comment 11•25 years ago
|
||
vidur...if ya checked this in last night could you mark Resolved/Fixed? Thanks!
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 12•25 years ago
|
||
Fixed checked in on 6/18/99.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 13•25 years ago
|
||
Working fine now. Marking verified.
Comment 14•25 years ago
|
||
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. ;-)
Comment 15•25 years ago
|
||
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.
Description
•