- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 16 Jul 2009 20:39:39 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Jonas Sicking <jonas@sicking.cc>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
On Jul 16, 2009, at 8:04 PM, Ian Hickson wrote: > On Thu, 16 Jul 2009, Maciej Stachowiak wrote: >>> >>> HTML5 just says that new History, Location, etc, objects are created >>> for each (inner) Window object. Is this not accurate? What do >>> browsers >>> do? >> >> Creating new ones on navigation is indeed correct, but a separate >> issue >> from making sure cross-origin cross-frame access to things like >> history.back() is safe for both parties. > > In HTML5, you can't access .history cross-domain, and you can't get > to the > prototype of the .location object (the only thing you can do > to .location > is set the .href member). > > Are these restrictions Web-incompatible? WebKit-based browsers allow cross-origin back(), forward() and go() on History, and replace(), reload() and assign() on Location, in addition to setting of href. I can't say definitively that all of those are needed to be Web compatible. Firefox allows access to at least location.replace() and history.back() cross-domain, and I would tentatively guess at least these two are required for Web compatibility. postMessage() (or, say, focus()) is another example of something that needs to be accessible cross-origin, and I don't think you can fully hide its prototype because call() and apply() should be usable on it, for example. I haven't thought through exactly how this needs to work. The point is mainly that anything accessible cross-origin probably can't just follow the normal rules for building a prototype chain. Regards, Maciej
Received on Friday, 17 July 2009 03:40:19 UTC