If a frame has the source URL of the form file://localhost/D|/SomeFile.html the frame will not be rendered if the root document is not loaded via a file:// URL. The WebObjects info center (part of WebObjects) for example will trigger this behaviour. This error occures with Mozilla build 2001091303 (0.9.4) on Windows 2000 with service pack 2. I have not tested other platfroms. Netscape 4.7x and Internet Explorer will render frames with such an URL correctly. Bug reproduction: Create a test.html in a webserver document root that contains -- snip <html> <head> <title>Test</title> </head> <frameset rows="*"> <frame src="file://localhost/C|/LocalDocument.html"> </frameset> </html> -- snip Modify the frame source to point to a local file. Open the test.html document via the webserver and the frame rendering will fail. Open the test.html document via open file from the file menu and frame rendering will work.
This worksforme on win98 and win2k, 2001102603. Copied the html below to d:\inetpub\webroot\test.html and changed the reference to "file://localhost/C|/LocalDocument.html" ... created the LocalDocument.html, entered file://localhost/D|/InetPub/wwwroot/test.html into the location, and the localdocument appeared properly ... Reporter, can you please try to reproduce this on a more recent build and let us know (within 10 days) if you're still seeing this behavior? Thanks.
Tobias John, please don't put bug comments into attachments ... bug comments go in the bug comments field :) Reproducing here for the benefit of the average bugzilla user: "It works if you specify a URL like file://localhost/D|/InetPub/wwwroot/test.html in your address field. What does not work is if you specify a URL like http://localhost/test.html assuming, that the directory d:\InetPub\wwwroot is mapped to http://localhost/. This works with IE and Nestcape 4.78. This is an issue if you have web applications running on your local machine that acesses and displays local documents that are not in the document root ofthe webserver serving the application. An example for such an application is the WebObjects Info Center. Maybe this is a bug of the application, since the application itself could serve the document, but IE and Netscape 4.78 do not show this behaviour and I think Mozilla should behave the same in this case. (I think that this may be an access permission problem and at a first galnce I can not see any security issues watching your own local documents)." Personally, I'm not sure what the correct behavior is on this ... I can see on both sides of the fence. (Security issue/non-issue) ... I'll try to round up someone to look at this.
Oops, forgot to mention that I -can- reproduce this. Accessing the frameset document via file:// will show the localdocument, but accessing it via http:// only shows a blank page. (no error messages)
-> Security, I'm pretty sure this is a known issue
Please try adding this line to the prefs.js file in your user profile directory (with Mozilla not running): user_pref("security.checkloaduri", false); Does that make the problem go away? It probably will. That will tell us whether this is a CheckLoadURI problem, which it appears to be.
Yes. Adding user_pref("security.checkloaduri", false); to the prefs.js will wake the problem go away.
OK, this behavior is correct - a frameset document from the Web cannot load a frame from file://. This prevents some security problems. If you need this to work, set the pref I mentioned above.
Verified on build: 2001-12-11-o3-Trunk platform: Win NT Tested both scenarios as mentioned above and the prefs setting. The test case works fine.