* 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.
Created attachment 2446 [details] Test Case
Confirmed, but renamed. Safari doens't take file:// for iframe src, it DOES however take http://localhost/ sources.
Created attachment 2455 [details] Improved and reduced testcase Same procedure as for the first testcase.
FYI, this is also an issue with XMLHttpRequest objects, too: They don't respect a local "file://" src, either.
Wouldn't this allow "stealing" local documents, thus opening a security hole? For local testing, I use relative URLs, seem to work fine.
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.
Created attachment 3354 [details] A similar case that works
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...
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.
(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?
> 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?
BTW, the primary reason for the reduced testcase to fail is that it lacks a slash in the URL: "file://Users..."
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.
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!
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.
It does seem to be fixed in 2.0.2 (416.12). Thanks.