Bug 44420 – Bogus JS security exception when accessing an object from another frame

• Component: WebCore JavaScript
• Status: RESOLVED WONTFIX

Created attachment 65112 [details]
frameset + .js to demonstrate the problem

Unpack the attachment and load file index.htm from a local drive.
Webkit will produce a bogus security exception: Unsafe JavaScript attempt to access frame with URL ...... from frame with URL ...... Domains, protocols and ports must match.


Both files are stored locally, in the same directory.
The problem disappears when the files are loaded from a web server (rather than a local drive).
Due to this problem, JS applications using frames (think a HELP system (TOC in the left frame, content in the right frame)) break completely when accessed from a local drive.


The problem can be reproduced both in Safari (5.0(7433.16)) and Google Chrome (5.0.375.127).
Non-webkit based browsers (including ancient versions of Konqueror/KHTML) work fine. 
(I.e. they change the text in the left frame to: "OK - Innner HTML updated successfully.")


Please fix. 
If you are aware of a possible work-around in JS, please post.

[Alexey Proskuryakov]

I cannot reproduce this in Safari for Mac, but I think that Safari for Windows has different security rules.

[Alexey Proskuryakov]

See also: bug 29255.

[Adam Barth]

Not sure what's going on with Windows Safari, but this is "works as intended" for Chrome.  The policy there is that local files cannot access each other.  Feel free to star <http://code.google.com/p/chromium/issues/detail?id=47416> if you'd like to be email about changes to this policy.

[Sam Weinig]

(In reply to comment #3)
> Not sure what's going on with Windows Safari, but this is "works as intended" for Chrome.  The policy there is that local files cannot access each other.  Feel free to star <http://code.google.com/p/chromium/issues/detail?id=47416> if you'd like to be email about changes to this policy.

This is also works as expected for Windows Safari.  Mac safari has the opposite rule.

Why WONTFIX? 

What about the workaround (using file .allow_access) proposed in 
http://code.google.com/p/chromium/issues/detail?id=47416

Note that this issue makes WebKit unusable for viewing product documentation if the documentation is delivered as HTML bundle and happens to be using frames. (And virtually all documentation authoring tools -- e.g. Adobe's RoboHelp -- generate frame-based documentation systems.)

Note that technical writers (unlike webmasters) will not have the necessary skill to debug and report the problem. Also note that such problems are unlikely to be reported by bug report forms (Safari|Report Bugs to Apple...; Chrome | Report bug or broken page) because they cannot be reproduced on regular http:// URL's.

Second thoughts.

1) Is using .allow_access file flexible enough?

I have application ABC in directory C:/abc/ and application XYZ in directory C:/xyz.  I would like to allow both applications to access files in respective directories, however, in the paranoia mode I don't want application ABC to access files in C:/xyz.

So, maybe this .allow_access file should be a configuration file (much like apache's .htacces), one entry being application id.  

*) What other entries are needed? 
*) What should be the format of the file? (JSON?)
*) What other entries, if any, are needed?

An elegant and flexible solution might be picked by other browsers, I don't think an .allow_access hack will.


2) The backwards compatibility is broken for most legitimate and innocent applications (documentation systems using framesets). What about allowing local access for files that are older than 2010.08 even if if .allow_access does not exist? In this way existing documentation framesets will continue to work (unless copied). Newly generated documentation will have to be shipped with the .allow_access file.



I hope this is a legitimate comment, could you paste it to http://code.google.com/p/chromium/issues/detail?id=47416 (adding comments is restricted at the moment).