On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak <[email protected]> wrote: > 1) It means the access control goes in fewer places - we don't have to have > access control on every document property, only window properties.
I'm not quite sure I understand this. At least for the location object, I see an explicit check in JSLocationCustom.cpp: http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71. Throwing the exception would happen there too (it won't require custom getters for each property). > So in general I'm not in a rush to change this. However, if the original bug > involved a compatibility problem on a real site (it doesn't really say), > then maybe that would be a stronger reason to change. I've asked Joseph (the original reporter of http://crbug.com/17325) where he ran into this. However, in the meantime, a quick code search shows this pattern elsewhere too. For example, Dojo has this snippet (in http://svn.dojotoolkit.org/src/dojo/trunk/hash.js): try{ //see if we can access the iframe's location without a permission denied error var iframeSearch = _getSegment(iframeLoc.href, "?"); //good, the iframe is same origin (no thrown exception) And FCKEditor (a WYSIWYG editor) has this at http://dev.ckeditor.com/browser/FCKeditor/trunk/fckeditor.js#L167: try { if ( (/fcksource=true/i).test( window.top.location.search ) ) sFile = 'fckeditor.original.html' ; } catch (e) { /* Ignore it. Much probably we are inside a FRAME where the "top" is in another domain (security error). */ } Mihai _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
