Re: [presentation-api] Receiving browsing context needs additional flags set

@mfoltzgoogle said:
> Do these in-app routing frameworks expect new Document objects in 
the history when using the History API? Or are they just using it as a
 convenient way to store application state within the same Document?

That's the part I missed :) In my mental model, using `pushState` 
would create new Document objects in the history. That is not the 
case! In other words, navigating the history that the receiver app may
 create should always work with the flag set, and my previous comment 
is essentially moot.

If you can confirm setting the flag works implementation-wise, then 
all is good. If that's not known yet, we could check with Web Platform
 Working Group or WHATWG folks whether setting that flag in a 
top-level context is ok.

Also, looking at the spec, I would complete the note at the end of the
 "Creating a receiving browsing context" algorithm to refer to the 
_sandboxed modals flag_, e.g.:

"Given the operating context of the presentation display, some APIs 
will not work by design (for example, by requiring user input) or will
 be obsolete (for example, by attempting window management); the 
receiving user agent should be aware of this. Furthermore, any modal 
user interface will need to be handled carefully.  The _sandboxed 
modals flag_ is set on the receiving browsing context to prevent most 
of these operations."

It could also be worth referring to the _sandboxed top-level 
navigation browsing context flag_ from the [User interface 
guidelines](https://w3c.github.io/presentation-api/#user-interface-guidelines)
 sub-section of the Security and Privacy section.

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/414#issuecomment-283591125
 using your GitHub account

Received on Thursday, 2 March 2017 08:40:00 UTC