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

[tidoust]

See related discussion between @schien and @tomoyukilabs on Web Platform Tests repository: web-platform-tests/wpt#3844

In particular, @schien notes that:

However, in the second note it says "setting presentation.defaultRequest" should take no effect. I take this sentence as "assigning value to defaultRequest will be no-op", which means presentation.defaultRequest will still be null after the assignment. That's my interpretation.

To which @tomoyukilabs replies:

I'm afraid that the spec might look ambiguous. I regard it as "Although the defaultRequest property can be set to any instance of PresentationRequest or null, browsers which do not support defaultRequest will never refer to its value unless a script accesses it directly".

I would read the spec as @tomoyukilabs. Regardless of who is correct, it seems a good idea to clarify the expected behavior!

[markafoltz]

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

[markafoltz]

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.

[louaybassbouss]

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?

[markafoltz]

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.

[markafoltz]

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.

[markafoltz]

Assuming the PR addressed the original issue, closing this.