Bug 3593 – iFrame Doesn't seem to Respect a local "file://" src

• Component: Frames
• Status: RESOLVED WORKSFORME

[David Wheeler]

* SUMMARY

When I load a page from my local file system, and point a frame to another file on my file system, the 
frame will not load the local page. This makes local testing difficult.

* STEPS TO REPRODUCE
1. Open the test case in a text editor, and point the frame source to another file on your local file 
system. 
2. Open the test case from your local hard drive.
3. Note how the local file does not load in the iframe, even if you use file://
4. Change the iframe source to a page served by a Web server (e.g., http://www.apple.com/).
5. Note how the iframe now loads the page.

* RESULTS
Locale files do not load in iframes, while remote files served by a Web server do.

* EXPECTED RESULTS
I expect local files to load in iframes just like remote files do. Such is the case in Firefox. This also has 
ramifications for my JavaScript work, wherein I attempt to assign to frames[0].location.href and nothing 
happens unless the URL I assign to location is served by a Web server.

[David Wheeler]

Created attachment 2446 [details]
Test Case

[Joost de Valk (AlthA)]

Confirmed, but renamed. Safari doens't take file:// for iframe src, it DOES however take http://localhost/ 
sources.

[Joost de Valk (AlthA)]

Created attachment 2455 [details]
Improved and reduced testcase

Same procedure as for the first testcase.

[David Wheeler]

FYI, this is also an issue with XMLHttpRequest objects, too: They don't respect a local "file://" src, either.

[Alexey Proskuryakov]

Wouldn't this allow "stealing" local documents, thus opening a security hole?

For local testing, I use relative URLs, seem to work fine.

[David Wheeler]

No, relative URLs don't work, either. That was my original report. It didn't even occur to me that file:// 
overall was the problem until Joost de Valk renamed this bug report.

One should be able to use file:// locations (relative or absolute) if the refering document is also local.

[Alexey Proskuryakov]

Created attachment 3354 [details]
A similar case that works

[Alexey Proskuryakov]

Indeed, I was speaking about "improved and reduced testcase" by Joost de Valk. In that case, 
document-relative paths DO work: simply change "file://Users/jdevalk/webkit/testcases/font-
hover.html" to just "font-hover.html" (assuming you have such file in the same directory).

As for your original testcase, looks like it is the first frames[0].location that really fails - both <iframe 
src="test.html"> and the timer work fine. This is probably a bug. Please the the attached test case "A 
similar case that works" for an example of what works for me.

I do not think that the location of the document should affect security restrictions anyhow. Otherwise, 
someone could file a bug with an archived malicious testcase in WebKit bugzilla...

[David Wheeler]

FYI, I retract my comment about XMLHttpRequest not respecting file://. It seems like Safari just sets the 
status to null when it's a local file. I'm not sure that's an appropriate status, but it's easy enough to check 
for.

[David Wheeler]

(In reply to comment #7)
> Created an attachment (id=3354) [edit]
> A similar case that works

Does not work for me in Safari 2.0 (412.2). Maybe you're using a build from CVS?

[Alexey Proskuryakov]

> Does not work for me in Safari 2.0 (412.2). Maybe you're using a build from CVS?

Works for me in 312, 412.2 and ToT (open try.html; "test.html" is displayed, to be replaced with "foo.html" 
a few seconds later)... Some timing/caching issue? My Mac is a G4/1.25DP.

Regardless, something strange is certainly happening to local files. Perhaps, this issue should be renamed 
in a more general manner, and wait for someone to seriously look into it?

[Alexey Proskuryakov]

BTW, the primary reason for the reduced testcase to fail is that it lacks a slash in the URL: "file://Users..."

[Maciej Stachowiak]

As far as I can tell, the sole problem with the test case given is that it's missing a slash - it should be 
file:///Users/... or file://localhost/Users... (or for convenience file:/Users/...), not file://Users/...

The two slashes make WebKit interpret Users as a hostname, so the path is not found. Please reopen if a 
syntactically correct test case shows a problem, or if there is evidence that two slashes before a path is 
accepted by other browsers.

[David Wheeler]

Well, if you look at my original test case (http://bugzilla.opendarwin.org/attachment.cgi?id=2446), you'll 
see that it's not explicitly using file:// or a URL ending in a slash. It's just using a file name, such as 
"foo.html". It's a relative path. And for me, it does not load the local file in the iframe. I'm using Safari 2.0 
(412.2.2).

If this is fixed in CVS, then cool. I look forward to the next release!

[Maciej Stachowiak]

I can't reproduce a problem with the original test case, either in the cvs version or the version shipped in 
Denver. A "test.html" in the same directory loads fine as a relative reference to a local file. The absolute 
URLs work fine too, when I change them to paths that exist.

The "improved and reduced" test case uses "file://Users" and so is buggy. I don't see a bug here that I can 
reproduce.

[David Wheeler]

It does seem to be fixed in 2.0.2 (416.12). Thanks.