Re: [whatwg] Notifications: making requestPermission() return a promise
On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola dome...@domenicdenicola.com wrote: So we should make a choice, as to whether we want developers to assume they will always get permission (in which case it should reject upon permission not being granted), or whether we want developers to ask the API whether they were granted permission (in which case it should give back a boolean fulfillment value or similar). How can they assume permission is always granted? It's up the user. It's a request from the developer and the user can say no. What's unclear about the name? Yeah, you misunderstood the question. It's about whether permission failure should reject the promise or accept it with a boolean. Domenic did not ask a question. I asked a question since it's unclear to me why a developer could reasonably assume they will always get permission. -- https://annevankesteren.nl/
Re: [whatwg] Notifications: making requestPermission() return a promise
On Oct 7, 2014 11:32 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola dome...@domenicdenicola.com wrote: So we should make a choice, as to whether we want developers to assume they will always get permission (in which case it should reject upon permission not being granted), or whether we want developers to ask the API whether they were granted permission (in which case it should give back a boolean fulfillment value or similar). How can they assume permission is always granted? It's up the user. It's a request from the developer and the user can say no. What's unclear about the name? Yeah, you misunderstood the question. It's about whether permission failure should reject the promise or accept it with a boolean. Domenic did not ask a question. I asked a question since it's unclear to me why a developer could reasonably assume they will always get permission. You're missing context or something. The question is whether it's not natural to assume that *if the promise fulfills*, that means they got permission. This allows them to do things like using Promise.all() to join multiple permission requests together and get a nice combined promise that fulfills when everything succeeds, or write a nice straight success path that assumes permission, and then handle any errors, including denied permission, at the end, rather than interleaving error-handling logic into the middle of your code. ~TJ
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The question is whether it's not natural to assume that *if the promise fulfills*, that means they got permission. This allows them to do things like using Promise.all() to join multiple permission requests together and get a nice combined promise that fulfills when everything succeeds, or write a nice straight success path that assumes permission, and then handle any errors, including denied permission, at the end, rather than interleaving error-handling logic into the middle of your code. Okay, given that question I agree it's natural to assume that this happens when it resolves. However, a user declining permission is not exceptional behavior and therefore should not cause an exception. In synchronous code you would not want to write try/catch here. -- https://annevankesteren.nl/
Re: [whatwg] Web API for Health Sensors
On Wed, Oct 8, 2014 at 9:40 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Indeed, a Web Bluetooth API would be a great start! Also, we are writing standards here, so standardizing the communication of the data between the devices and UAs would be useful. Both would probably fall within the work of a device API group like http://www.w3.org/2009/dap/ , where media capture was standardized. Absolutely. This seems to tie in pretty well with the Generic Sensor API discussion planned at this year's TPAC[1]. --tobie --- [1]: https://www.w3.org/wiki/TPAC2014/SessionIdeas#Generic_Sensor_API
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
get a nice combined promise that fulfills when everything succeeds,
This is as simple as:
Promise.all(permissionRequests).then(function(results) {
if (results.every(x = x === granted)) // …
});
But I don't think it's the right approach to handling permissions in
general. Developers should handle granted permissions as progressive
enhancements, not balk when they don't get all the permissions they
required. Using exceptions for denied permissions sends a completely wrong
message imho, especially when it's combined with Promise.all.
--tobie
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:06 PM, Jonas Sicking jo...@sicking.cc wrote: I think we should define that non-persistent notifications disappear after a timeout. And define that on mobile platforms with notification centers, that these notifications are *not* added there, but rather is just displayed on screen for a short period of time. Done: https://notifications.spec.whatwg.org/#lifetime-and-ui-integration I also think that we should define that for persistent notifications, that these *are* added to mobile notification centers. Done (same link). I also think that we should define that clicking a non-permanent should as default action focus the window which created the notification. We should also define that during the click event the browser is encouraged to allow calls to window.focus() to, work. Even in UAs which have restrictive policies about when window.focus() is honored. Done: https://notifications.spec.whatwg.org/#activating-a-notification -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote: I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. I started to remove the close event and then I noticed we also use it when a notification gets replaced by a newer one. Do we care about that? -- https://annevankesteren.nl/
Re: [whatwg] getting rid of anonymizing redirects
Understood and thanks for the explanation. Does this have implications for resource hints? Do we want the ability to specify ³noreferrer² for prerendered pages? Currently noreferrer only applies to the a tag. Thanks, Peter From: Ilya Grigorik igrigo...@gmail.com Date: Tuesday, October 7, 2014 at 6:13 PM To: Peter Lepeska bizzbys...@gmail.com Cc: Chris Bentzel cbent...@google.com, WHAT Working Group wha...@whatwg.org, public-web-p...@w3.org Subject: Re: [whatwg] getting rid of anonymizing redirects On Tue, Oct 7, 2014 at 8:28 AM, Peter Lepeska bizzbys...@gmail.com wrote: Looks like this is already supported: https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer. Just need to educate web developers to you use it. It's a bit more complicated. The redirector use case has many dimensions: a) site wants to anonymize the referrer (and do so reliably across all UAs) b) site wants to log the navigation for analytics (sync XHR = bad, a ping has limited support, Beacon is FF/Chrome only) c) site wants to log native-app visits and add attribution to their native app - e.g. G+ app clicks are shown as plus.google.com http://plus.google.com in referrer logs. In theory, (a) and (b) are addressed by new APIs. In practice, due to old UAs + implementation differences, redirector is *way* easier - don't have to perform UA detects, etc. (c) is a whole different story.. and the reason many teams like the redirector route is that it allows them to reuse the same path for web and native. To be clear, I'm not endorsing the pattern.. I'd love get rid of it. That said, just want to relay the feedback I've received in the past. - we need referrer logic implemented consistently. - we need Beacon available in all browsers. Also, preconnect support can also help speed things up for redirector case: http://w3c.github.io/resource-hints/#anonymizing-redirect-preconnect ig
Re: [whatwg] getting rid of anonymizing redirects
Great thanks Boris! On 10/7/14, 11:49 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/7/14, 11:39 AM, Glenn Maynard wrote: Firefox has had a ticket open for this for about half a decade It's fixed and the fix is shipping in Firefox 33 in a week. -Boris
Re: [whatwg] getting rid of anonymizing redirects
On Wed, Oct 8, 2014 at 11:36 AM, Peter Lepeska bizzbys...@gmail.com wrote: Does this have implications for resource hints? Do we want the ability to specify “noreferrer” for prerendered pages? Currently noreferrer only applies to the a tag. My understanding is that you set a global policy, which would apply to all requests: https://w3c.github.io/webappsec/specs/content-security-policy/#directive-referrer e.g. Content-Security-Policy: referrer no-referrer; (or equivalent meta element) ig
Re: [whatwg] getting rid of anonymizing redirects
Okay. I assumed more granular control would be needed but if not then this works great. Thanks, Peter From: Ilya Grigorik igrigo...@gmail.com Date: Wednesday, October 8, 2014 at 11:43 AM To: Peter Lepeska bizzbys...@gmail.com Cc: Chris Bentzel cbent...@google.com, WHAT Working Group wha...@whatwg.org, public-web-p...@w3.org Subject: Re: [whatwg] getting rid of anonymizing redirects On Wed, Oct 8, 2014 at 11:36 AM, Peter Lepeska bizzbys...@gmail.com wrote: Does this have implications for resource hints? Do we want the ability to specify ³noreferrer² for prerendered pages? Currently noreferrer only applies to the a tag. My understanding is that you set a global policy, which would apply to all requests: https://w3c.github.io/webappsec/specs/content-security-policy/#directive-ref errer e.g. Content-Security-Policy: referrer no-referrer; (or equivalent meta element) ig
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 1:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The question is whether it's not natural to assume that *if the promise fulfills*, that means they got permission. This allows them to do things like using Promise.all() to join multiple permission requests together and get a nice combined promise that fulfills when everything succeeds, or write a nice straight success path that assumes permission, and then handle any errors, including denied permission, at the end, rather than interleaving error-handling logic into the middle of your code. Okay, given that question I agree it's natural to assume that this happens when it resolves. However, a user declining permission is not exceptional behavior and therefore should not cause an exception. In synchronous code you would not want to write try/catch here. An error or failure event *is* an asynchronous exception. It's a completely different code path from the success event that you can handle separately, while writing code for the success path that assumes you got the things you needed. Do you think that every single instance of error events we've used in the past was a mistake, and we should have instead just had a complete event that both success and failure used? For example, should img.onload fire when the image fails to load? This is *exactly* analogous to a permission request succeeding or failing, as far as I can tell, but for the equivalent image situation, I believe you're okay with a failed load rejecting the .ready promise (or whatever we're planning to name it). There are certainly cases where only actual exceptions would cause rejection - Domenic's example of a userAllowsNotifications() function is clearly going to fulfill with a boolean, and only reject if you fuck something up. But requesting a permission is an operation that can fail, and failure is exceptional, and we've reflected this precise distinction in tons of past APIs via an error event. Why was every single past API that used this pattern mistaken? Again, if this means that the current design for await becomes less convenient, *we can fix await to work better*. It's not set in stone, it's not developed yet. This is a thing we can change. But let's not twist our necks around and force promise APIs into an unnatural and inconvenient shape just because a naive translation to sync code produces errors and people find try/catch annoying or distasteful. ~TJ
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
get a nice combined promise that fulfills when everything succeeds,
This is as simple as:
Promise.all(permissionRequests).then(function(results) {
if (results.every(x = x === granted)) // …
});
But I don't think it's the right approach to handling permissions in
general. Developers should handle granted permissions as progressive
enhancements, not balk when they don't get all the permissions they
required. Using exceptions for denied permissions sends a completely wrong
message imho, especially when it's combined with Promise.all.
I don't think moral arguments really have a place here. Whatever
mitigation code that authors write to handle failed permissions can go
in the reject handler exactly as easily as in the fulfill handler.
That we believe authors should handle permission failures
intelligently doesn't, itself, mean that we should make the success
path less convenient.
~TJ
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together
and
get a nice combined promise that fulfills when everything succeeds,
This is as simple as:
Promise.all(permissionRequests).then(function(results) {
if (results.every(x = x === granted)) // …
});
But I don't think it's the right approach to handling permissions in
general. Developers should handle granted permissions as progressive
enhancements, not balk when they don't get all the permissions they
required. Using exceptions for denied permissions sends a completely
wrong
message imho, especially when it's combined with Promise.all.
I don't think moral arguments really have a place here. Whatever
mitigation code that authors write to handle failed permissions can go
in the reject handler exactly as easily as in the fulfill handler.
That we believe authors should handle permission failures
intelligently doesn't, itself, mean that we should make the success
path less convenient.
I don't see how your definition of success is less of a moral argument than
mine, but I'm happy to be enlightened.
--tobie
Re: [whatwg] Notifications: making requestPermission() return a promise
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Again, if this means that the current design for await becomes less
convenient, *we can fix await to work better*. It's not set in stone, it's
not developed yet. This is a thing we can change.
To be clear, this will not be happening. Await is designed very much to play
well with promise semantics and to carry over the return value/thrown exception
parallel even more directly than promises already do. As I said earlier, if
you'd prefer some kind of Option type, perhaps with its own dedicated syntax,
that's something you can try proposing. But await and promises are tied to
exception semantics, have been since day 1, and are in all other languages
which have similar constructs. Nobody on TC39 is planning to depart from that
path, especially since async functions with these semantics have been proposed,
in one form or another, since the early days of ES Harmony.
But let's not twist our necks around and force promise APIs into an unnatural
and inconvenient shape just because a naive translation to sync code produces
errors and people find try/catch annoying or distasteful.
I disagree with your characterization of unnatural and inconvenient, of
course. An `if` statement is the most natural thing in the world.
What I find interesting here is the claim that people find try/catch annoying
or distasteful. Why should they? It's the proper, syntactic way to handle
errors---none of this error event business, or error-first callbacks, or even
promise rejection callbacks. That's how exceptional, stack-unwinding errors
that are meant to immediately halt execution should be contained and handled.
The question, again, is very simple. Is being denied permission an exceptional
error that developers want to bubble to the outermost `catch (e) { ... }`
block, or outermost `.catch(e = { ... })` handler? Or will they always want to
deal with both paths of the result immediately? Tobie's argument about treating
permissions as progressive enhancement is a good argument for the latter, IMO.
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola dome...@domenicdenicola.com wrote: What I find interesting here is the claim that people find try/catch annoying or distasteful. I don't think you should need try/catch for a common failure case. That is all. So yes, agreed with Tobie et al. -- https://annevankesteren.nl/
Re: [whatwg] Notifications: making requestPermission() return a promise
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren I don't think you should need try/catch for a common failure case. Ah, this is the crux of our minor-disagreement, I think. IMO using try/catch for a common failure case is fine, *as long as you want that failure to bubble up the call stack*. E.g., if you want to handle it at a higher level along with other failures, or if you want to ignore the possibility of failure except in how errors get sent to `window.onerror`. Now, I think we're likely in *agreement* that you don't actually want to do this for requestPermission---you should handle it as soon as possible. But our reasoning is different, and now I understand why.
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola dome...@domenicdenicola.com wrote: What I find interesting here is the claim that people find try/catch annoying or distasteful. I don't think you should need try/catch for a common failure case. That is all. So yes, agreed with Tobie et al. You keep arguing from the future rejections become errors position. You keep ignoring the past turns out we like using async errors for 'soft failures' of this kind, and have done it lots of times, and nobody seems to complain argument. Do you dislike img.onerror firing when the image doesn't load? (And same for all the other resource-loading elements.) Do you dislike geolocator.getCurrentPosition calling the failure callback when the user refuses permission? Do you dislike IDB firing error events on several types of failure, ranging from exceptional to mundane? If there are any of these you do *not* dislike, why? And why doesn't the logic from those apply to this situation? On Wed, Oct 8, 2014 at 9:18 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Ah, this is the crux of our minor-disagreement, I think. IMO using try/catch for a common failure case is fine, *as long as you want that failure to bubble up the call stack*. E.g., if you want to handle it at a higher level along with other failures, or if you want to ignore the possibility of failure except in how errors get sent to `window.onerror`. Now, I think we're likely in *agreement* that you don't actually want to do this for requestPermission---you should handle it as soon as possible. But our reasoning is different, and now I understand why. The problem here is that try/catch *is* distasteful, while promise rejection isn't, and it's all ergonomics. * try/catch produces rightward drift, promise reject handlers do not * errors bubble up indefinitely until they're caught, breaking all of your code. Rejections bubble down a single promise chain, and can be ignored if you're done with a chain without anything bad happening. (And some Promise algebra functions like .race() can swallow a rejection without rejecting the chain, if another one fulfilled first, so you don't even have to think about the rejection.) * We've been taught not to use exceptions for control flow, but we have the Promise algebra to help us do control flow based on promises fulfilling/rejecting (and more mature Promise libraries tend to grow more algebra over time). Errors suck, but they're the way we do rejections syncly. I hate that we're compromising on the built-in ergonomics of Promises in order to avoid triggering the worse ergonomics of errors in the future. :( ~TJ
Re: [whatwg] Notifications and service workers
On Wed, Oct 8, 2014 at 7:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote: I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. I started to remove the close event and then I noticed we also use it when a notification gets replaced by a newer one. Do we care about that? Interesting. Though if we don't need an event for .close() being called, I suspect we won't need one for a notification being replace. It seems somewhat rare that either of these things would provide significant use to the app if the notification is going away soon anyway. Also, BroadcastChannel was created to allow people to handle these types of things themselves if needed. So we're not leaving people without a workaround if for some reason there is a use case here. / Jonas
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: You keep ignoring the past turns out we like using async errors for 'soft failures' of this kind, and have done it lots of times, and nobody seems to complain argument. A user saying no to notifications is not an error. You ask the user to make a decision, the user decides. Either way is a success. An error would be invoking the method in the wrong way. Do you dislike img.onerror firing when the image doesn't load? (And same for all the other resource-loading elements.) That makes sense. Network errors are rather exceptional. Note that it does not error for a 404 (unless it can't decode the response, which again, is rather exceptional). Do you dislike geolocator.getCurrentPosition calling the failure callback when the user refuses permission? I would expect that to be done differently today, yes. -- https://annevankesteren.nl/
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: You keep ignoring the past turns out we like using async errors for 'soft failures' of this kind, and have done it lots of times, and nobody seems to complain argument. A user saying no to notifications is not an error. You ask the user to make a decision, the user decides. Either way is a success. An error would be invoking the method in the wrong way. This is 100% arguable, and based solely on the *precise* manner in which you are assigning semantics to the name. If we named the method getNotifier(), and it requested permission as a side-effect, would you call failure to get the notifier due to refusing permission an exceptional situation? Do you dislike img.onerror firing when the image doesn't load? (And same for all the other resource-loading elements.) That makes sense. Network errors are rather exceptional. Note that it does not error for a 404 (unless it can't decode the response, which again, is rather exceptional). Do you dislike geolocator.getCurrentPosition calling the failure callback when the user refuses permission? I would expect that to be done differently today, yes. Why? getCurrentPosition is asking for the current permission. If you fail to get the current position, why would you call that a success? What would you even pass to the success callback? A neutered position object? A position object with default values, plus an extra field saying lol no this isn't real? ~TJ
Re: [whatwg] Notifications: making requestPermission() return a promise
On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote: On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola dome...@domenicdenicola.com wrote: What I find interesting here is the claim that people find try/catch annoying or distasteful. I don't think you should need try/catch for a common failure case. That is all. So yes, agreed with Tobie et al. You keep arguing from the future rejections become errors position. You keep ignoring the past turns out we like using async errors for 'soft failures' of this kind, and have done it lots of times, and nobody seems to complain argument. Do you dislike img.onerror firing when the image doesn't load? (And same for all the other resource-loading elements.) Do you dislike geolocator.getCurrentPosition calling the failure callback when the user refuses permission? Do you dislike IDB firing error events on several types of failure, ranging from exceptional to mundane? If there are any of these you do *not* dislike, why? And why doesn't the logic from those apply to this situation? On Wed, Oct 8, 2014 at 9:18 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Ah, this is the crux of our minor-disagreement, I think. IMO using try/catch for a common failure case is fine, *as long as you want that failure to bubble up the call stack*. E.g., if you want to handle it at a higher level along with other failures, or if you want to ignore the possibility of failure except in how errors get sent to `window.onerror`. Now, I think we're likely in *agreement* that you don't actually want to do this for requestPermission---you should handle it as soon as possible. But our reasoning is different, and now I understand why. The problem here is that try/catch *is* distasteful, while promise rejection isn't, and it's all ergonomics. * try/catch produces rightward drift, promise reject handlers do not * errors bubble up indefinitely until they're caught, breaking all of your code. (off topic to Notifications) That is a main point of exceptions. If your code is horribly broken, like wrong params passed to some method, execution should stop asap. The fact that Promise returning functions don't throw immediately is a crazy setup since one may just ignore and not notice at all the rather bad error in the program logic. Rejections bubble down a single promise chain, and can be ignored if you're done with a chain without anything bad happening. (And some Promise algebra functions like .race() can swallow a rejection without rejecting the chain, if another one fulfilled first, so you don't even have to think about the rejection.) * We've been taught not to use exceptions for control flow, but we have the Promise algebra to help us do control flow based on promises fulfilling/rejecting (and more mature Promise libraries tend to grow more algebra over time). Errors suck, but they're the way we do rejections syncly. I hate that we're compromising on the built-in ergonomics of Promises in order to avoid triggering the worse ergonomics of errors in the future. :( ~TJ
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch
annoying or distasteful.
I don't think you should need try/catch for a common failure case.
That is all. So yes, agreed with Tobie et al.
Another thing to keep in mind here is that it's pretty easy to convert
between either of these behaviors. It's just a matter of either doing
requestPermission().then((r) = { if (!r) throw Error(...) })
requestPermission().then(() = true, () = false)
Or, using the await syntax
async function() {
if (!await requestPermission())
throw Error(...);
}
async function() {
hasPermission = true;
try {
await requestPermission();
}
catch {
hasPermission = false;
}
}
So I think a more important question here is what behavior would an
author expect. I think one of the points Dominic tried to make earlier
is that the name is important for setting that expectation and help
authors understand how the function behaves. Sadly the name that we're
stuck with doesn't really provide much guidance either way.
But I think to some extent it's indicating that we're bikeshedding here.
/ Jonas
Re: [whatwg] Notifications: making requestPermission() return a promise
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody seems to complain argument.
A user saying no to notifications is not an error. You ask the user to
make a decision, the user decides. Either way is a success. An error
would be invoking the method in the wrong way.
This is more of a coding pattern thing than an expectation thing.
For example in gecko we often implement security checks by calling
functions that throw exceptions if the security check failed. Mainly
because this means less typing. So rather than writing:
function implDOMThingy(x, y, z) {
if (!callerCanAccess(x))
throw Error(...);
if (!isSameOrigin(x,y))
throw Error(...);
... do stuff here ...
}
we write
function implDOMThingy(x, y, z) {
assertCanAccess(x);
assertSameOrigin(x,y);
... do stuff here ...
}
So assertCanAccess/assertSameOrigin throws exceptions if a given
security check doesn't pass. Not because the security function was
called the wrong way or otherwise had an error, but because it makes
callsites easier to write.
However the experience that I personally have with this pattern is
that it requires that the throwing function takes care of everything
that needs to happen when an exception is thrown. For us that meant
things like log errors to the developer console. So this is more
appropriate in places when the throwing function provides a complete
package of functionality.
This also means that the functions are less reusable. Since they don't
just do one thing.
But it is quite awesome when you have such a resuable package that you
can use in several callsites. Definitely makes the code less
cluttered.
But I think that's an indication that we should not do that here. I
would for example expect that authors want to put up some UI to the
user indicating that the reason some feature isn't working is because
the user has denied access.
/ Jonas
