W3C home > Mailing lists > Public > public-secondscreen@w3.org > June 2018

Re: [presentation-api] Behavior of window.reload() on presentation receiver page

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Fri, 15 Jun 2018 11:52:39 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-397597655-1529063558-sysbot+gh@w3.org>
 (This is orthogonal to the problem raised here and could be addressed in a separate issue, but that was prompted by it and touches on the same spec text, so I'll raise it here).

@mfoltzgoogle Are we really not defining navigation behavior in terms of HTML5, though? The Presentation API does not link to the navigate algorithm in HTML, but it still uses the terms defined there, and I'm not sure about the expected behavior in practice.

Typically, the mention of "Chrome closes presentations that attempt to navigate" makes me wonder whether the spec should not be adjusted to clarify the expected behavior when the receiving page attempts to navigate.

The [navigate](https://www.w3.org/TR/html53/browsers.html#navigated) algorithm is described in HTML 5.3. It includes a step that essentially says that if the browsing context is not "allowed to navigate", then the algorithm should be aborted. A `SecurityError` may be thrown in some cases, and user agents may offer to open the URL in another browsing context otherwise (FWIW, the algorithm is the same in the HTML LS version - see the definition of [navigate](https://html.spec.whatwg.org/#navigate) there - although the description of that step is tad more convoluted).

So, when the Presentation API spec says "The top-level browsing context MUST NOT be allowed to navigate itself", my understanding is that attempts to navigate should simply do nothing (or perhaps throw a `SecurityError`). I would not expect such attempts to close the browsing context in particular.

I'm not sure whether the exact behavior matters in practice. It could perhaps be left up to implementations, except it's always easier to test a specific behavior than a range of possibilities... In any case, I think the sentence "The top-level browsing context MUST NOT be allowed to navigate itself" should be updated.

If we want to link to the usual navigate algorithm and abort attempts to navigate, then we could simply link to [allowed to navigate](https://html.spec.whatwg.org/#allowed-to-navigate) in the Presentation API, as a way to say that we're patching it to have it return false for receiving browsing context (except for fragment and reload navigations).

If we rather want to close the receiving browsing context when attempts to navigate are made, then we should say so explicitly, as in "The user agent MUST close the receiving browsing context if it attempts to navigate itself, except..."

PS: I mentioned testing, I note we'll need a couple of new test cases in the test suite to check the behavior.

GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/449#issuecomment-397597655 using your GitHub account
Received on Friday, 15 June 2018 11:52:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:19:04 UTC