Closed Bug 276879 Opened 21 years ago Closed 20 years ago

Firefox - CD/HDD relative addressing issue when using frames

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: modio, Assigned: bugs)

Details

Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0 On my c: drive, I've got a web page which uses frames, and it works fine with both FF and IE6. I have a second web page with a link pointing to the first page; this link works OK with IE6, but not with FF - FF finds the first web page OK, but then fails to load the frames. My two web pages are in different folders, and the problem is that when FF tries to load the frames, *it looks in the wrong folder*. Whereas IE6 recognises that the addresses of the pages it needs are relative to the folder containing the first web page, FF treats the addresses as being relative to the folder containing the second page (i.e. the one with the hyperlink). I don’t have much knowledge of HTML, but I figure that this may be a bug in FF. (I apologise in advance if the problem is in my HTML.) The problem can be easily reproduced as follows: c:/test0/page1.htm <HTML><FRAMESET rows=40,* > <FRAME src="page1A.htm"> <FRAME src="page1B.htm"> </FRAMESET></HTML> c:/test0/page1A.htm <HTML> <P>Top<P> </HTML> c:/test0/page1B.htm <HTML> <P>Bottom<P> </HTML> c:/test1/Test Link.htm <HTML> <P><A HREF="..\test0\pagel.htm"> Test Link<A><P> </HTML> When this link is executed, FF loads c:/test0/page1.htm OK, but then it looks for the two frames in c:\test1\ rather than c:\test0\, and of course they are not there.
Reporter, note that a URL like "..\test0\pagel.htm" is wrong. It should be "../test0/pagel.htm". Does it work better with this fix ?
(In reply to comment #1) > Reporter, note that a URL like "..\test0\pagel.htm" is wrong. It should be > "../test0/pagel.htm". Does it work better with this fix ? Thank you. Yes, it works fine if you replace ‘\’ with ‘/’, but unfortunately this doesn't help me. I have a CD which was produced with MS Word 2000; all the links are internal within the CD, and they all use ‘\’ rather than ‘/’. The links *all* work OK with IE6. Except for a few, most of them do with FF, too; the ones that don't are all ones which point to a target page which a) uses frames *and* b) which is stored in a different folder to the page with the calling link. The HTML in my bug report reproduces the condition on the Word-produced CD. If you click directly on the page itself, ‘c:\test0\page1.htm’, this works fine with FF. However, if you first load the page ‘c:\test1\test link.htm’, and then execute the link, FF finds the target page ‘c:\test0\page1.htm’ OK, and this page tells FF what it should be loading into each of the frames (‘page1A.htm’ & ‘page1B.htm’); but when FF tries to translate these relative addresses into absolute addresses, it gets it wrong - FF actually ends up with ‘c:\test1\page1A.htm’ & ‘c:\test1\page1B.htm’ rather than ‘c:\test0\page1A.htm’ & ‘c:\test0\page1B.htm’. As a result FF displays two error messages saying that there are pages it can't find, and though it does display the target page and its frames & borders, the frames themselves are empty. Les Bedford
(POSTSCRIPT to comment #2) I’ve experimented a bit with Word 2000. When you create a hyperlink, and “Browse for: File”, the hyperlink that Word automatically creates uses ‘\’ rather than ‘/’ e.g. ‘..\test0\page1.htm’. If you save this as HTML, IE6 is quite happy with it. However, having done the “Browse for: File”, you can then manually change the delimiters from ‘\’ to ‘/’, and Word is quite happy to accept this change. (So it *is* possible to get it right with Word, but you have to go out of your way to do it.) So the problem is that Word is automatically generating ‘bad’ HTML (though it’s happy with ‘good’ HTML, too), and IE6 is happy with either. FF is also generally happy either way, too, except in the particular circumstances that I’ve identified.
try mozilla 1.8a5 - I think darin fixed this... (unless I misunderstood bug 249282)
URL: (CD & HDD)
(In reply to comment #4) > try mozilla 1.8a5 - I think darin fixed this... (unless I misunderstood bug 249282) Where can I find Mozilla 1.8a5? I've just done a fresh download, & I'm still picking up the same version as I already have, which is: Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.