Drop permissionState()'s argument?

[annevk]

I don't understand why it has one. It was added in #131 but the method steps were not adjusted to account for it. @beverloo @mvano what gives?

[beverloo]

The motivation was that a user agent might have granted permission for user visible push messages, but not for invisible ones. This was mirrored in the push permission descriptor for permissions.query() for the same reason.

I believe that Chrome OS might've had a case in which this is relevant, other Chrome platforms only consider user visible permission requests & queries. Firefox never supported this according to MDN, so compatibility will be complicated anyway.

[annevk]

I see, but any conforming implementation is required to ignore the argument (except for IDL purposes) as things stand today specification-wise.

But it's clear Chromium is doing something else:

  // The `userVisibleOnly` flag on |options| must be set, as it's intended to be
  // a contract with the developer that they will show a notification upon
  // receiving a push message. Permission is denied without this setting.
  //
  // TODO(peter): Would it be better to resolve DENIED rather than rejecting?
  if (!options->hasUserVisibleOnly() || !options->userVisibleOnly()) {
    resolver->Reject(MakeGarbageCollected<DOMException>(
        DOMExceptionCode::kNotSupportedError, kUserVisibleOnlyRequired));
    return promise;
  }