On Sep 17, 2012 8:22 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Sep 2012, Brian Kardell wrote:
Ian, you hit the nail on the head with the text section that raised the
issue but I still am not entirely sure that I understand... Doesn't this
imply that in a case like *.wordpress.com
On Tue, 18 Sep 2012, Brian Kardell wrote:
I think you are saying that each subdomain does get a seperate area, but
the spec encourages prompt or at least informative communication to the
user to prevent at least obvious misuse and runaway scenarios.
Specifically what degree to which they
On Tue, 12 Jun 2012, James Graham wrote:
In particular, what stops such navigations from re-triggering the unload
handler, and thus starting yet another navigation?
I've updated the spec to have guards in place for 'pagehide' and 'unload'.
(Not yet 'beforeunload'. Should we do that too?)
This is all great; thanks for the quick turnaround!
I've also made back()/forward()/go() not work during the document's unload
handler, since that could be used for griefing. I'm tempted to disable it
entirely for all docs a la alert(), but I've no idea if that's Web-
compatible and I suspect
On Tue, 18 Sep 2012, Justin Lebar wrote:
This is all great; thanks for the quick turnaround!
I've also made back()/forward()/go() not work during the document's
unload handler, since that could be used for griefing. I'm tempted to
disable it entirely for all docs a la alert(), but I've
I've also made back()/forward()/go() not work during the document's
unload handler, since that could be used for griefing. I'm tempted to
disable it entirely for all docs a la alert(), but I've no idea if
that's Web- compatible and I suspect not.
I don't know what you mean by the last
On Tue, 18 Sep 2012, Justin Lebar wrote:
The issue isn't a history.back() which crosses origins -- that seems
fine -- but rather calling history.back() on a cross-origin window.
(Sorry that wasn't clear.)
Aah, ok. The spec already says that's not allowed. You can't get to the
History