Just to clarify, I'm only looking to add exception throwing to cross-origin property accesses of the location object, not for the whole window object.
As for real-world uses of location.href throwing an exception, a new comment just got added to: http://code.google.com/p/chromium/issues/detail?id=17325#c16 Comment 16 by r...@electronicinsight.com, Today (4 minutes ago) There is definitely real-world use case for this for WebKit. At Sprout (http://sproutinc.com) we have a generic platform to design mobile HTML5 ads. We allow designers to link elements in top window and new window. If they choose "top window", in Android 2.2 the "top window" link will just refresh the current page when doing "window.top.location.href = url". We need a way to test for the security exception and then do window.open(url) instead when that security error is trapped. Mihai On Tue, Aug 17, 2010 at 3:28 PM, Adam Barth <aba...@webkit.org> wrote: > On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak <m...@apple.com> wrote: >> On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote: >>> On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak <m...@apple.com> 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). >> >> Yes, a small handful of objects that hang off of Window are accessible >> cross-origin and have their own security checks. However, one property of >> Window is handled very differently between WebKit-based browsers and what >> the spec calls for. someCrossOriginWindow.document returns undefined in >> WebKit-based browsers, but it returns a document object per the spec which >> then does its own security check on every property access. This is >> unfortunate because the attack surface is increased and performance suffers. >> And it's not Web-compatible to just throw on access to the document property >> - Web apps expect they can always ask for the document, and it's the *next* >> property access that throws, which is fulfilled by returning undefined since >> accessing a property of the undefined value throws in JS. For cases like the >> location object, it doesn't matter much either way. > > I believe the spec no longer exposes someCrossOriginWindow.document. > (As to whether it throws a security exception or returns null, I'd > have to look more carefully.) > > Adam > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
