You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
There is no proper definition as to what the "default presentation request" represents.
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).
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.
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.
The spec only explicitly says that support for this feature in controlling user agents is optional in an editorial note.
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:
I added a definition for "default presentation request" in the "Common Idioms" section.
The text is now explicit that support for the default presentation request mechanism is optional.
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)
This update creates a definition of "default presentation request" in the
"Common Idioms" section, and reformulates the intended behavior in controlling
user agents that support this mechanism.
In particular, the update tries to make it clear that support for this feature
is optional, and moves the check on the sandboxed presentation browsing context
flag to a note since it will be done as part of the "start a presentation"
algorithm.
The reason will be displayed to describe this comment to others. Learn more.
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.
To avoid confusing sentences about Presentation attributes that we don't expect
to be present in controlling or receiving user agents, this update makes it
clear which category of user agents is to implement which partial interface
definition.
Also dropped "chrome" from sentences that used "browser chrome", not to
restrict the mechanism to interactions with the browser window.
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.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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).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 isOPTIONAL
, or phrase things with a conditionalMUST
, 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 theSHOULD
level? (note that comment only applies to the paragraph that starts with "If set by the controller", the use ofSHOULD
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: