- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Mar 2017 13:38:41 +0000
- To: public-secondscreen@w3.org
I'm probably missing something but I find it strange to set the _sandboxed top-level navigation browsing context flag_ on the receiving browsing context, given that it is a top level browsing context. As far as I can tell, HTML never does this, it only sets that flag on nested contexts. Said differently, my understanding is that a browsing context can always navigate itself in practice, meaning it can for instance always call `window.location.reload()` to reload itself. This would be a no-op if the flag is set. That may be what you want to achieve, but being able to navigate itself also seems needed to use [the `History` interface](http://www.w3.org/TR/html51/browsers.html#the-history-interface). More precisely, the page may call `pushState` for in-app routing (as done in [Backbone.js](http://backbonejs.org/#History) and other JS frameworks). In itself, this does not trigger any navigation. Now "user agents may discard the Document objects of entries other than the current entry" at any time, so calling `go` or `back` to traverse that history could potentially trigger a navigation. Setting the flag as suggested would make the application crash. -- GitHub Notification of comment by tidoust Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/414#issuecomment-283341694 using your GitHub account
Received on Wednesday, 1 March 2017 13:38:48 UTC