diff --git a/permission-element.bs b/permission-element.bs index 2cc5013..ff63d7e 100644 --- a/permission-element.bs +++ b/permission-element.bs @@ -118,8 +118,8 @@ time providing implementations with a better signal of user intent.
-onresolve: Event -ondismiss: Event +onpromptaction: Event +onpromptdismiss: Event onvalidationstatuschange: Event@@ -208,6 +208,18 @@ The <{permission}> element has the following internal slots: {{DOMRectReadOnly}} that stores the most recently seen intersection, i.e. the position of the <{permission}> relative to the [=viewport=]. +* \[[LastNotifiedValidState]] + is a [=boolean=] that stores the most recently notified state of + {{HTMLPermissionElement/isValid}}. + +* \[[LastNotifiedInvalidReason]] + is a [=string=] that stores the most recently notified state of + {{HTMLPermissionElement/invalidReason}}. + {{[[LastNotifiedValidState]]}} and {{[[LastNotifiedInvalidReason]]}} are + used to determine whether an + {{HTMLPermissionElement/onvalidationstatuschange}} event needs to be + dispatches. + ## <{permission}>-supporting state at the [=/navigable=] ## {#permission-element-external-state} In order to support the <{permission}> element, the [=/navigable=] maintains @@ -464,6 +476,9 @@ The {{HTMLPermissionElement}} constructor steps are: 1. Initialize the internal {{[[Types]]}} slot to null. 1. Initialize the internal {{[[BlockerList]]}} to «[]». +1. Initialize the internal {{[[LastNotifiedValidState]]}} with false. +1. Initialize the internal {{[[LastNotifiedInvalidReason]]}} with the empty + string. @@ -488,6 +503,7 @@ The {{HTMLPermissionElement}} [=insertion steps=] are: [=this=] is a [=fenced navigable=], then [=add a permanent blocker=] with {{PermissionElementBlockerReason/illegal_subframe}}. +1. [=Maybe dispatch onvalidstatechange=] on [=this=]. @@ -496,6 +512,7 @@ The {{HTMLPermissionElement}} [=removing steps=] are: 1. [=list/Remove=] [=this=] from [=node navigable=]'s {{[[PermissionElements]]}}. 1. [=Recheck type permissibility=] for [=this=]'s [=node navigable=]. +1. [=Maybe dispatch onvalidstatechange=] on [=this=]. @@ -521,10 +538,23 @@ A <{permission}> |element|'s [=EventTarget/activation behavior=] given |event| i 1. If |element|'s {{[[Types]]}} [=list/is empty=], then return. 1. If |event|.{{Event/isTrusted}} is false, then return. 1. If |element|.{{HTMLPermissionElement/isValid}} is false, then return. -1. [=Request permission to use=] the [=powerful features=] named in |element|'s - {{[[Types]]}}. +1. [=Request permission to use=] the [=powerful features=] named in + |element|'s {{[[Types]]}}. +1. If the previous step was cancelled or dismissed by the user, then + [=dispatch onpromptdismiss=] on [=this=] and return. + + Issue: The [[PERMISSIONS]] spec assumes that [=request permission to use=] + will always succeed. That is, it assumes that the user will always make a + choice and that the algorithm will always deliver a `grant`/`deny` + answer corresponding to that choice. But you can't force a user to do that. + Some [=user agents=] may have different UI affordances for an explicit + denial (e.g. a "deny" button) on one hand, and cancelling or dismissing the + request dialog (e.g. an "X" button in the top right corner). Here, we + distinguish between these two actions, despite no clear hook for this + in the underlying specification. + +1. [=Dispatch onpromptaction=] on [=this=]. -Issue: What about event handlers?