Clarify the default presentation request mechanism?

[tidoust]

I find the section that defines and specifies the behavior of the default presentation request somewhat unclear in 6.2.1 Controlling user agent. More precisely:

1. There is no proper definition as to what the "default presentation request" represents.
2. I am unclear whether the initial value for the attribute is always null. I think it is, but the spec only specifies behavior when the attribute is "set by the controller". Can the attribute be set by the controlling user agent? I suppose not (at least that does not seem to make sense).
3. The text explicitly covers the case when the sandboxed presentation browsing context flag is set, but since that check is part of the "start a presentation" algorithm that gets called to initiate the presentation, this should not be needed.
4. Similarly, stricto senso, the "start a presentation" algorithm won't be allowed to show a popup in that case, so calling it should fail right away, which is obviously not the intended behavior.
5. The spec only explicitly says that support for this feature in controlling user agents is optional in an editorial note.
6. I do not understand the use of SHOULD in the second paragraph. I suppose it's meant to convey the fact that controlling user agents may not support that feature, but it seems better to be explicit that the feature is OPTIONAL, or phrase things with a conditional MUST, as in "if [feature supported], the controlling user agent MUST [behavior]". Or is there a good reason not to follow these statements, which would indeed justify the SHOULD level? (note that comment only applies to the paragraph that starts with "If set by the controller", the use of SHOULD for user gestures looks good).

I propose a rewrite in this pull request. Note that this is not meant to introduce any change of behavior, but rather to clarify the intent and behavior of the default presentation request mechanism. Main proposed changes:

1. I added a definition for "default presentation request" in the "Common Idioms" section.
2. The text is now explicit that support for the default presentation request mechanism is optional.
3. The text is now clear that step 1. of the "start a presentation" algorithm is to be skipped, and that other security checks apply (I kept the sandboxing flag as an example in a note)

[markafoltz]

This implies that the defaultRequest can be set in a receiving browsing context. The spec doesn't have a concrete notion of how a receiving browsing context could be used to initiate its own presentation (the "daisy chaining case") but I don't think we should exclude it.

[markafoltz]

This is an improvement, thanks @tidoust. I had a couple of minor comments but overall LGTM.

[tidoust]

I dropped "chrome" from "browser chrome" as suggested. Feel free to improve that part if needed, I don't think there's a spec that defines what that encompasses precisely. For instance, I see HTML5 talks about browser interface elements while other specs use "browser chrome" as we do (e.g. Media Capture and Streams).

To avoid possible ambiguities regarding the defaultRequest attribute in a receiving user agent and the receiver attribute in a controlling user agent, I propose to simply say which class of user agents it to implement which partial interface of Presentation and to drop the sentences that refer to the other class altogether. That is what I did in my latest commit.

This seems clearer to me and also better from an IDL perspective. The IDL tests that we have typically filter out the partial interface definition that does not apply to the class of user agent being tested. In other words, the IDL tests that check controlling user agents do not contain the receiver definition and the IDL test that check receiving user agents do not contain the defaultRequest.