Closed Bug 8353 Opened 25 years ago Closed 25 years ago

Relative links point to wrong directory

Categories

(Core :: Networking, defect, P3)

x86
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: chriss, Assigned: gagan)

References

()

Details

Attachments

(1 file)

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.
Target Milestone: M7
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.
Target Milestone: M7 → M8
m8 -> necko landing
Blocks: 7232
Attached patch proposed patchSplinter Review
Assignee: vidur → gagan
Status: ASSIGNED → NEW
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.
Target Milestone: M8 → M7
vidur...if ya checked this in last night could you mark Resolved/Fixed?  Thanks!
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed checked in on 6/18/99.
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: