- From: Marcos Cáceres <notifications@github.com>
- Date: Wed, 19 Oct 2016 01:39:46 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Message-ID: <w3c/manifest/pull/506/review/4825010@github.com>
marcoscaceres commented on this pull request. > + <code>BeforeInstallPromptEvent</code> + </h3> + <pre class="idl"> +enum AppBannerPromptOutcome { + "accepted", + "dismissed" +}; + +[Constructor(DOMString typeArg, optional BeforeInstallPromptEventInit eventInit)] +interface BeforeInstallPromptEvent : Event { + readonly attribute Promise<AppBannerPromptOutcome> userChoice; + Promise<void> prompt(); +}; + +dictionary BeforeInstallPromptEventInit : EventInit { + AppBannerPromptOutcome userChoice; > But if we must let the client supply a userChoice here, why is it an AppBannerPromptOutcome and not a Promise<AppBannerPromptOutcome>? The way it is now, the client has to pass the user's actual choice (accepted or dismissed) to the constructor of the event, before the simulated prompt is even shown, and the promise gets immediately resolved during construction. Shouldn't this constructor take a promise that can be resolved at a later time? If someone is synthetically constructing BIP Events, they probably know what they are doing - so I would prefer just to keep it as simple as possible: i.e., they provide the value "userChoice" that it resolves. If they provide no value, the promise never resolves. If it comes up as an issue, we can set a default value. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/pull/506
Received on Wednesday, 19 October 2016 08:40:22 UTC