Since publication as Candidate Recommendation on01 June 2017, the Working Group updated the steps to construct aPresentationRequest to ignore a URL with an unsupported scheme, placed further restrictions on how receiving browsing contexts are allowed to navigate themselves, and dropped the definition of theBinaryType enum in favor of the one defined in the HTML specification. Other interfaces defined in this document did not change other than to adjust to WebIDL updates. Various clarifications and editorial updates were also made. See thelist of changes for details.
No feature has been identified as beingat risk.
The Second Screen Working Group will refine thetest suite for the Presentation API during the Candidate Recommendation period and update thepreliminary implementation report. For this specification to advance to Proposed Recommendation, two independent, interoperable implementations of each feature must be demonstrated, as detailed in theCandidate Recommendation exit criteria section.
Publication as an Editor's Draft does not imply endorsement byW3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The Presentation API aims to makepresentation displays such as projectors, attached monitors, and network-connected TVs available to the Web. It takes into account displays that are attached using wired (HDMI, DVI, or similar) and wireless technologies (Miracast, Chromecast, DLNA, AirPlay, or similar).
Devices with limited screen size lack the ability to show Web content to a larger audience: a group of colleagues in a conference room, or friends and family at home, for example. Web content shown on a largerpresentation display has greater perceived quality, legibility, and impact.
At its core, the Presentation API enables acontroller page to show apresentation page on apresentation display and exchange messages with it. How the presentation page is transmitted to the display and how messages are exchanged between it and the controller page are left to the implementation; this allows the use of a wide variety of display technologies.
For example, if thepresentation display is connected by HDMI or Miracast, which only allow audio and video to be transmitted, the user agent (UA) hosting thecontroller will also render thepresentation. It then uses the operating system to send the resulting graphical and audio output to the presentation display. We refer to this situation as the1-UA mode implementation of the Presentation API. The only requirements are that the user agent is able to send graphics and audio from rendering the presentation to the presentation display, and exchange messages internally between the controller and presentation pages.
If thepresentation display is able to render HTML natively and communicate with thecontroller via a network, the user agent hosting the controller does not need to render thepresentation. Instead, the user agent acts as a proxy that requests the presentation display to load and render the presentation page itself. Message exchange is done over a network connection between the user agent and the presentation display. We refer to this situation as the2-UA mode implementation of the Presentation API.
The Presentation API is intended to be used with user agents that attach topresentation displays in1-UA mode,2-UA mode, and possibly other means not listed above. To improve interoperability between user agents and presentation displays, standardization of network communication between browsers and displays is being considered in theSecond Screen Community Group.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key wordsMAY,MUST,MUST NOT,OPTIONAL,SHOULD, andSHOULD NOT in this document are to be interpreted as described inBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and terminate these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
3.1 Conformance classes
This specification describes the conformance criteria for two classes ofuser agents.
The termreload a document refers to steps run when thereload() method gets called in [HTML].
The termlocal storage area refers to the storage areas exposed by thelocalStorage attribute, and the termsession storage area refers to the storage areas exposed by thesessionStorage attribute in [HTML].
This specification references terms exported by other specifications, seeB.2Terms defined by reference. It also references the following internal concepts from other specifications:
This section shows example codes that highlight the usage of main features of the Presentation API. In these examples,controller.html implements the controller andpresentation.html implements the presentation. Both pages are served from the domainhttps://example.org (https://example.org/controller.html andhttps://example.org/presentation.html). These examples assume that the controlling page is managing one presentation at a time. Please refer to the comments in the code examples for further details.
5.1 Monitoring availability of presentation displays
This code renders a button that is visible when there is at least one compatiblepresentation display that can presenthttps://example.com/presentation.htmlorhttps://example.net/alternate.html.
Monitoring of display availability is done by first creating aPresentationRequest with the URLs you want to present, then callinggetAvailability to obtain aPresentationAvailability object whosechange event will fire when presentation availability changes state.
<!-- controller.html --><buttonid="presentBtn"style="display: none;">Present</button><script>// The Present button is visible if at least one presentation display is availablevar presentBtn =document.getElementById("presentBtn");// It is also possible to use relative presentation URL e.g. "presentation.html"var presUrls = ["https://example.com/presentation.html","https://example.net/alternate.html"];// show or hide present button depending on display availabilityvar handleAvailabilityChange =function(available) { presentBtn.style.display = available ?"inline" :"none"; };// Promise is resolved as soon as the presentation display availability is// known.var request =newPresentationRequest(presUrls); request.getAvailability().then(function(availability) {// availability.value may be kept up-to-date by the controlling UA as long// as the availability object is alive. It is advised for the Web developers// to discard the object as soon as it's not needed.handleAvailabilityChange(availability.value); availability.onchange =function() {handleAvailabilityChange(this.value); }; }).catch(function() {// Availability monitoring is not supported by the platform, so discovery of// presentation displays will happen only after request.start() is called.// Pretend the devices are available for simplicity; or, one could implement// a third state for the button.handleAvailabilityChange(true); });</script>
5.2 Starting a new presentation
When the user clickspresentBtn, this code requests presentation of one of the URLs in thePresentationRequest. Whenstart is called, the browser typically shows a dialog that allows the user to select one of the compatible displays that are available. The first URL in thePresentationRequest that is compatible with the chosen display will be presented on that display.
Thestart method resolves with aPresentationConnection object that is used to track the state of the presentation, and exchange messages with the presentation page once it's loaded on the display.
<!-- controller.html --><script> presentBtn.onclick =function () {// Start new presentation. request.start()// The connection to the presentation will be passed to setConnection on// success. .then(setConnection);// Otherwise, the user canceled the selection dialog or no screens were// found. };</script>
5.3 Reconnecting to an existing presentation
The presentation continues to run even after the original page that started the presentation closes itsPresentationConnection, navigates, or is closed. Another page can use theid on thePresentationConnection to reconnect to an existing presentation and resume control of it. This is only guaranteed to work from the same browser that started the presentation.
<!-- controller.html --><buttonid="reconnectBtn"style="display: none;">Reconnect</button><script>var reconnect =function () {// read presId from localStorage if existsvar presId =localStorage["presId"];// presId is mandatory when reconnecting to a presentation.if (!!presId) { request.reconnect(presId)// The new connection to the presentation will be passed to// setConnection on success. .then(setConnection);// No connection found for presUrl and presId, or an error occurred. } };// On navigation of the controller, reconnect automatically.document.addEventListener("DOMContentLoaded", reconnect);// Or allow manual reconnection.const reconnectBtn =document.querySelector("#reconnectBtn"); reconnectBtn.onclick = reconnect;</script>
5.4 Starting a presentation by the controlling user agent
Some browsers have a way for users to start a presentation without interacting directly with the controlling page. Controlling pages can opt into this behavior by setting thedefaultRequest property onnavigator.presentation, and listening for aconnectionavailable event that is fired when a presentation is started this way. ThePresentationConnection passed with the event behaves the same as if the page had calledstart.
<!-- controller.html --><!-- Setting presentation.defaultRequest allows the page to specify the PresentationRequest to use when the controlling UA initiates a presentation. --><script> navigator.presentation.defaultRequest =newPresentationRequest(presUrls); navigator.presentation.defaultRequest.onconnectionavailable =function(evt) {setConnection(evt.connection); };</script>
5.5 Monitoring the connection state and exchanging data
Once a presentation has started, the returnedPresentationConnection is used to monitor its state and exchange messages with it. Typically the user will be given the choice to disconnect from or terminate the presentation from the controlling page.
Since the the controlling page may connect to and disconnect from multiple presentations during its lifetime, it's helpful to keep track of the currentPresentationConnection and its state. Messages can only be sent and received on connections in aconnected state.
<!-- controller.html --><buttonid="disconnectBtn"style="display: none;">Disconnect</button><buttonid="stopBtn"style="display: none;">Stop</button><script>let connection;// The Disconnect and Stop buttons are visible if there is a connected presentationconst stopBtn =document.querySelector("#stopBtn");const disconnectBtn =document.querySelector("#disconnectBtn"); stopBtn.onclick =_ => { connection && connection.terminate(); }; disconnectBtn.onclick =_ => { connection && connection.close(); };functionsetConnection(newConnection) {// Disconnect from existing presentation, if not attempting to reconnectif (connection && connection != newConnection && connection.state !='closed') { connection.onclose =undefined; connection.close(); }// Set the new connection and save the presentation ID connection = newConnection;localStorage["presId"] = connection.id;functionshowConnectedUI() {// Allow the user to disconnect from or terminate the presentation stopBtn.style.display ="inline"; disconnectBtn.style.display ="inline"; reconnectBtn.style.display ="none"; }functionshowDisconnectedUI() { disconnectBtn.style.display ="none"; stopBtn.style.display ="none"; reconnectBtn.style.display =localStorage["presId"] ?"inline" :"none"; }// Monitor the connection state connection.onconnect =_ => {showConnectedUI();// Register message handler connection.onmessage =message => {console.log(`Received message:${message.data}`); };// Send initial message to presentation page connection.send("Say hello"); }; connection.onclose =_ => { connection =null;showDisconnectedUI(); }; connection.onterminate =_ => {// Remove presId from localStorage if existsdeletelocalStorage["presId"]; connection =null;showDisconnectedUI(); }; };</script>
5.6 Listening for incoming presentation connections
This code runs on the presented page (https://example.org/presentation.html). Presentations may be connected to from multiple controlling pages, so it's important that the presented page listen for incoming connections on theconnectionList object.
5.8 Creating a second presentation from the same controlling page
It's possible for a controlling page to start and control two independent presentations on two different presentation displays. This code shows how a second presentation can be added to the first one in the examples above.
<!-- controller.html --><!-- The same controlling page can create and manage multiple presentations, by calling start() multiple times. --><buttonid="secondPresentBtn"style="display: none;">Present Again</button><script>var secondPresentBtn =document.getElementById("secondPresentBtn");var secondPresUrl ="https://example.com/second-presentation.html";var secondRequest =newPresentationRequest(secondPresUrl);// For simplicity, the logic to handle screen availability for secondRequest// and update the status of secondPresentBtn is omitted. secondPresentBtn.onclick =function () {// Start new presentation, likely on a different screen than the original// request. secondRequest.start().then(setSecondConnection); };functionsetSecondConnection(newConnection) {// Logic to handle messages to/from second-presentation.html. };</script>
6. API
6.1 Common idioms
Apresentation display refers to a graphical and/or audio output device available to the user agent via an implementation specific connection technology.
Apresentation connection is an object relating acontrolling browsing context to itsreceiving browsing context and enables two-way-messaging between them. Eachpresentation connection has apresentation connection state, a uniquepresentation identifier to distinguish it from otherpresentations, and apresentation URL that is aURL used to create or reconnect to thepresentation. Avalid presentation identifier consists of alphanumeric ASCII characters only and is at least 16 characters long.
Somepresentation displays may only be able to display a subset of Web content because of functional, security or hardware limitations. Examples are set-top boxes, smart TVs, or networked speakers capable of rendering only audio. We say that such a display is anavailable presentation display for apresentation URL if thecontrolling user agent can reasonably guarantee that presentation of the URL on that display will succeed.
In acontrolling browsing context, thedefault presentation request, which is initially set tonull, represents the request to use when the user wishes to initiate apresentation connection from the browser chrome.
Thetask source for the tasks mentioned in this specification is thepresentation task source.
Thecontrolling user agentSHOULD initiate presentation using thedefault presentation request only when the user has expressed an intention to do so via a user gesture, for example by clicking a button in the browser chrome.
The details of implementing the permission request and display selection are left to the user agent; for example it may show the user a dialog and allow the user to select an available display (granting permission), or cancel the selection (denying permission). Implementers are encouraged to show the user whether an available display is currently in use, to facilitate presentations that can make use of multiple displays.
Note
Receiving user agents are encouraged to advertise a user friendly name for the presentation display, e.g. "Living Room TV", to assist the user in selecting the intended display. Implementers of receiving user agents are also encouraged to advertise the locale and intended text direction of the user friendly name. Implementers of controlling user agents are encouraged to render a user friendly name using its locale and text direction when they are known.
6.3.3 Starting a presentation from a default presentation request
When the user expresses an intent to start presentation of a document on a presentation display using the browser chrome (via a dedicated button, user gesture, or other signal), that user agentMUST run the following steps tostart a presentation from a default presentation request. If nodefault presentation request is set on the document, these stepsMUST not be run.
Input
W, the document on which the user has expressed an intent to start presentation
If the next step fails, abort all remaining steps andclose the presentation connectionS witherror ascloseReason, and a human readable message describing the failure ascloseMessage.
ThepresentationUrl should name a resource accessible to the local or a remote user agent. This specification defines behavior forpresentationUrl using thehttp orhttps schemes; behavior for other schemes is not defined by this specification.
6.3.5 Reconnecting to a presentation
When thereconnect method is called, theuser agentMUST run the following steps to reconnect to a presentation:
The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by objects implementing thePresentationRequest interface:
The monitoring algorithm must be run at least one more time after the previous step to pick up the tuple that was added to theset of presentation availability objects.
The mechanism used to monitorpresentation displays availability and determine the compatibility of apresentation display with a given URL is left to the user agent.
Thestate attribute represents thepresentation connection's current state. It can take one of the values ofPresentationConnectionState depending on the connection state:
connected means that thepresentation connection is established and communication is possible.
closed means that thepresentation connection has been closed, or could not be opened. It may be re-opened through a call toreconnect. No communication is possible.
Aconnected state does not mean that sending or receiving messages will succeed, as the communication channel may be abruptly closed at any time. Applications that wish to detect such situations as soon as possible should implement their own keep-alive mechanism.
ThebinaryType attribute can take one of the values ofBinaryType. When aPresentationConnection object is created, itsbinaryType attributeMUST be set to the string "arraybuffer". On getting, itMUST return the last value it was set to. On setting, the user agentMUST set the attribute to the new value.
Note
ThebinaryType attribute allows authors to control how binary data is exposed to scripts. By setting the attribute to "blob", binary data is returned inBlob form; by setting it to "arraybuffer", it is returned inArrayBuffer form. The attribute defaults to "arraybuffer". This attribute has no effect on data sent in a string form.
If the connection cannot be completed,close the presentation connectionS witherror ascloseReason, and a human readable message describing the failure ascloseMessage.
Note
The mechanism that is used to present on the remote display and connect thecontrolling browsing context with the presented document is an implementation choice of the user agent. The connection must provide a two-way messaging abstraction capable of carryingDOMString and binary payloads in a reliable and in-order fashion as described in theSend a Message andReceive a Message steps below.
No specific transport for the connection between thecontrolling browsing context and thereceiving browsing context is mandated, except that for multiple calls tosend it has to be ensured that messages are delivered to the other end reliably and in sequence. The transport should function equivalently to anRTCDataChannel in reliable mode.
Letpresentation message data be the payload data to be transmitted between two browsing contexts. Letpresentation message type be the type of that data, one oftext orbinary.
If the previous step encounters an unrecoverable error, then abruptlyclose the presentation connectionpresentationConnection witherror ascloseReason, and acloseMessage describing the error encountered.
Note
To assist applications in recovery from an error sending a message through apresentation connection, the user agent should include details of which attempt failed incloseMessage, along with a human readable string explaining the failure reason. Example renditions ofcloseMessage:
Unable to send text message (network_error): "hello" forDOMString messages, where"hello" is the first 256 characters of the failed message.
When sending a user-visible string via apresentation connection, the page author should take care to ensure that locale information is also propagated so that the destination user agent can know how to best render the string. Seethe examples for one solution.
If thestate property ofpresentationConnection is notconnected, abort these steps.
Letevent be the result ofcreating an event using theMessageEvent interface, with the event typemessage, which does not bubble and is not cancelable.
Initialize theevent's data attribute as follows:
IfmessageType istext, then initializeevent'sdata attribute tomessageData with typeDOMString.
IfmessageType isbinary, andbinaryType attribute is set to "blob", then initializeevent'sdata attribute to a newBlob object withmessageData as its raw data.
IfmessageType isbinary, andbinaryType attribute is set to "arraybuffer", then initializeevent'sdata attribute to a newArrayBuffer object whose contents aremessageData.
If theuser agent encounters an unrecoverable error whilereceiving a message throughpresentationConnection, itMUST abruptlyclose the presentation connectionpresentationConnection witherror ascloseReason. ItSHOULD use a human readable description of the error encountered ascloseMessage.
wentaway means that the browser closed the connection, for example, because the browsing context that owned the connection navigated or was discarded.
When thereason attribute iserror, the user agentSHOULD set themessage attribute to a human readable description of how the communication channel encountered an error.
Start to signal to thedestination browsing context the intention to close the correspondingPresentationConnection, passing thecloseReason to that context. The user agent does not need to wait for acknowledgement that the correspondingPresentationConnection was actually closed before proceeding to the next step.
Fire an event namedclose, that uses thePresentationConnectionCloseEvent interface, with thereason attribute initialized tocloseReason and themessage attribute initialized tocloseMessage, atpresentationConnection. The event must not bubble and must not be cancelable.
6.5.6 Terminating a presentation in a controlling browsing context
When acontrolling user agent is toterminate a presentation in a controlling browsing context usingconnection, itMUST run the following steps:
This could happen by an explicit user action, or as a policy of the user agent. For example, thereceiving user agent could be configured to terminate presentations whosePresentationConnection objects are all closed for 30 minutes.
When areceiving user agent is toterminate a presentation in a receiving browsing context, itMUST run the following steps:
LetP be the presentation to be terminated, letallControllers be theset of presentation controllers that were created forP, andconnectedControllers an empty list.
For eachconnection inallControllers, run the following steps:
For eachconnection inconnectedControllers, send a termination confirmation forP using an implementation specific mechanism to thecontrolling user agent that owns thedestination browsing context forconnection.
The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by objects implementing thePresentationConnection interface:
This algorithm is intended to create a well defined environment to allow interoperable behavior for1-UA and2-UA presentations, and to minimize the amount of state remaining on apresentation display used for a2-UA presentation.
Given the operating context of thepresentation display, some Web APIs will not work by design (for example, by requiring user input) or will be obsolete (for example, by attempting window management); thereceiving user agent should be aware of this. Furthermore, any modal user interface will need to be handled carefully. Thesandboxed modals flag is set on thereceiving browsing context to prevent most of these operations.
The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by objects implementing thePresentationConnectionList interface:
Event handler
Event handler event type
onconnectionavailable
connectionavailable
7. Security and privacy considerations
This section is non-normative.
7.1 Personally identifiable information
Thechange event fired on thePresentationAvailability object reveals one bit of information about the presence or absence of apresentation display, often discovered through the browser's local area network. This could be used in conjunction with other information for fingerprinting the user. However, this information is also dependent on the user's local network context, so the risk is minimized.
Apresentation is allowed to be accessed across origins; thepresentation URL andpresentation identifier used to create the presentation are the only information needed to reconnect to a presentation from any origin in the controlling user agent. In other words, a presentation is not tied to a particular opening origin.
This design allows controlling contexts from different origins to connect to a shared presentation resource. The security of the presentation identifier prevents arbitrary origins from connecting to an existing presentation.
This specification makes no guarantee as to the identity of any party connecting to a presentation. Once connected, the presentation may wish to further verify the identity of the connecting party through application-specific means. For example, the presentation could challenge the controller to provide a token viasend that the presentation uses to verify identity and authorization.
Display of the origin requesting presentation will help the user understand what content is making the request, especially when the request is initiated from achild navigable. For example, embedded content may try to convince the user to click to trigger a request to start an unwanted presentation.
When a userstarts a presentation, the user will begin with exclusive control of the presentation. However, the Presentation API allows additional devices (likely belonging to distinct users) to connect and thereby control the presentation as well. When a second device connects to a presentation, it is recommended that all connectedcontrolling user agents notify their users via the browser chrome that the original user has lost exclusive access, and there are now multiple controllers for the presentation.
The presentation API abstracts away what "local" means for displays, meaning that it exposes network-accessible displays as though they were directly attached to the user's device. The Presentation API requires user permission for a page to access any display to mitigate issues that could arise, such as showing unwanted content on a display viewable by others.
7.5 Temporary identifiers and browser state
Thepresentation URL andpresentation identifier can be used to connect to a presentation from another browsing context. They can be intercepted if an attacker can inject content into the controlling page.
7.6 Private browsing mode and clearing of browsing data
The content displayed on the presentation is different from the controller. In particular, if the user is logged in in both contexts, then logs out of thecontrolling browsing context, they will not be automatically logged out from thereceiving browsing context. Applications that use authentication should pay extra care when communicating between devices.
The set of presentations known to the user agent should be cleared when the user requests to "clear browsing data."
Thanks to Addison Phillips, Anne Van Kesteren, Anssi Kostiainen, Anton Vayvod, Chris Needham, Christine Runnegar, Daniel Davis, Domenic Denicola, Erik Wilde, François Daoust, 闵洪波 (Hongbo Min), Hongki CHA, Hubert Sablonnière, Hyojin Song, Hyun June Kim, Jean-Claude Dufourd, Joanmarie Diggs, Jonas Sicking, Louay Bassbouss, Mark Watson, Martin Dürst, Matt Hammond, Mike West, Mounir Lamouri, Nick Doty, Oleg Beletski, Philip Jägenstedt, Richard Ishida, Shih-Chiang Chien, Takeshi Kanai, Tobie Langel, Tomoyuki Shimizu, Travis Leithead, and Wayne Carr for help with editing, reviews and feedback to this draft.
AirPlay,HDMI,Chromecast,DLNA andMiracast are registered trademarks of Apple Inc., HDMI Licensing LLC., Google Inc., the Digital Living Network Alliance, and the Wi-Fi Alliance, respectively. They are only cited as background information and their use is not required to implement the specification.
D. Candidate Recommendation exit criteria
For this specification to be advanced to Proposed Recommendation, there must be, for each of the conformance classes it defines (controlling user agent andreceiving user agent), at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. Additionally, implementations of thecontrolling user agent conformance class must include at least one implementation of the1-UA mode, and one implementation of the2-UA mode.2-UA mode implementations may only support non http/https presentation URLs. Implementations of thereceiving user agent conformance class may not include implementations of the2-UA mode.
The API was recently restricted to secure contexts. Deprecation of the API in non secure contexts in early implementations takes time. The group may request transition to Proposed Recommendation with implementations that still expose the API in non secure contexts, provided there exists a timeline to restrict these implementations in the future.
For the purposes of these criteria, we define the following terms:
Independent
Each implementation must be developed by a different party, and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.
Interoperable
Passing the respective test case(s) in the official test suite.
Implementation
A user agent which:
implements one of the conformance classes of the specification.
is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or "nightly build"). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability.
is not experimental (i.e. a version specifically designed to pass the test suite and not intended for normal usage going forward).
E. Change log
This section is non-normative.
This section lists changes made to the spec since it was first published as Candidate Recommendation in July 2016, with links to related issues on the group's issue tracker.
E.1 Changes since 01 June 2017
Added a note about receiving browsing contexts starting presentations (#487)
Removed the definition of the BinaryType enum (#473)
Updated WebIDL to use constructor operations (#469)
Clarified how receiving browsing contexts are allowed to navigate (#461)
Updated termination algorithm to also discard the receiving browsing context and allow termination in a connecting state (#421,#423)
Dropped sandboxing section, now integrated in HTML (#437 in the Web Platform Working Group issue tracker)
Relaxed exit criteria to match known implementations plans (#406)
The sandboxed top-level navigation browsing context flag and the sandboxed modals flag are now set on the receiving browsing context to prevent top-level navigation and the ability to spawn new browsing contexts (#414)
Moved sandboxing flag checks to PresentationRequest constructor (#379,#398)
Updated normative references to target stable specifications (#295,#396)
Made display selection algorithm reject in ancestor and descendant browsing context (#394)
Renamed PresentationConnectionClosedReason to PresentationConnectionCloseReason (#393)