"setting presentation.defaultRequest will have no effect" note is ambiguous #359

Activity

1. markafoltz commented on Oct 14, 2016

   

   markafoltz

   on Oct 14, 2016

   Contributor

   More actions

   The intent is that the attribute setting algorithm [1] completes, but there is no attribute-specific behavior for defaultRequest in the controlling user agent (step 9).

   Since the spec does not override the attribute setting algorithm, the meaning seems clear enough to me, but the text could be explicit that the attribute is set.

   [1] https://www.w3.org/TR/WebIDL/#dfn-attribute-setter
2. markafoltz commented on Oct 17, 2016

   

   markafoltz

   on Oct 17, 2016

   Contributor

   More actions

   There's another issue with starting a default presentation. The spec says that the controlling user agent should run the steps to start a presentation (starting at step 2). However, it's not clear that the user agent should construct a Promise as part of those steps (as there's nowhere to return it.) Maybe we can adjust the language or construct a new algorithm that omits the Promise related steps.
3. louaybassbouss commented on Nov 5, 2016

   

   louaybassbouss

   on Nov 5, 2016

   Contributor

   More actions

   I am now thinking about the current behaviour of defaultRequest. In current spec the controlling page get notified (using onconnectionavailable) only if the user selects a display in the dialog. Do we need to inform the page that the selection dialog is open? in this case we need to change the spec as following:

   navigator.presentation.defaultRequest = new PresentationRequest(presUrls);
   navigator.presentation.defaultRequest.onstart = function(evt) {
       // here the page knows that a dialog is open
       evt.promise.then(setConnection).catch(...)
   };
   

   in this case we don't need to constrict a new algorithm for default request. What do you think?
4. markafoltz commented on Nov 8, 2016

   

   markafoltz

   on Nov 8, 2016

   Contributor

   More actions

   The current spec doesn't assume there's a dialog (permission can be granted other ways) so we'd have to craft an algorithm that fires a dummy event in those cases to deliver a Promise that resolves immediately. In my opinion it adds extra complexity to the API, which can be avoided by adjusting other parts of the spec.

   I think a simpler fix is to just break the start a presentation algorithm into two parts (at step 13) and make step 19 optional (i.e. pass an optional Promise to the second half of the algorithm). When the user agents wants to start a presentation from a defaultRequest, it would pass D with no Promise to step 13.
5. markafoltz commented on Nov 23, 2016

   

   markafoltz

   on Nov 23, 2016

   Contributor

   More actions

   PR #369 updates the specs along the lines of my previous comment.

   @louaybassbouss Would you like to continue discussion of a new event for display selection? I can file a separate issue for that.
6. markafoltz commented on Nov 28, 2016

   

   markafoltz

   on Nov 28, 2016

   Contributor

   More actions

   Assuming the PR addressed the original issue, closing this.
7. markafoltz

   closed this as completedon Nov 28, 2016