486208 - Relative references to root don't resolve from file:// pages on Windows

Status: RESOLVED DUPLICATE of bug 257321

(Firefox :: File Handling, defect)

Description

[Beau Sheil]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

If one has a page that makes relative references to "root" e.g. src="/foo/..." this works correctly when either (a) served by HTTP or (b) if the referring page has source "file://..." and the file system has a well defined root. But on Windows, where the source page will have some URL like "file://C:/mumble" a reference of the form "/foo/.." resolves to "file:///foo/..." which is the foo directory in the non-existent root of the file system. That is, the disk drive component of the source has been dropped and the reference is meaningless.

This is arguably "correct" but it's not very helpful. If one has a set of Web pages that share some common resources (images, scripts) it's common and useful to have these in a top level directory. This works fine on a server but breaks when you move the whole page set and run it from a local disk.

FWIW, IE resolves the root in such relative references back to the disk volume, so things work as expected there.

This is closely related to bug 13607 - what is the interpretation of file:/// on systems with no clear root e.g. Windows.

It's really not clear what "root" on a non-rooted file system should mean - which is why 13607 has been open for nearly 10 years. But it would be convenient to be able to SAY. Could we perhaps have a preference item that specifies a directory to be used when looking for local file system "root"? That would be similar in spirit to the root specification that almost all HTTP servers allow. Or perhaps a policy preference to leave the volume in the relative base?

Reproducible: Always

Steps to Reproduce:
1. Create a page with an img src of "/foo/img.jpg"
2. Load it from a local file on Windows
3. Image will be broken no matter where you put the foo directory containing img.jpg
4. Works fine on Unix or a HTTP server if foo is in the right place
Actual Results:  
Reference to img.jpg in Windows becomes "file:///foo/img.jpg" which does not resolve

Expected Results:  
Find img.jpg in foo on the same disk volume as the source page was loaded from. ie, "file://C:/foo/img.jpg" if the source page was on C: This behavior is shown by IE

Comment 1

[u360807]

This is duplicate of Bug 257321