Allow the embedder to disable the Notification constructor.

Allow the embedder to disable the Notification constructor.

On desktop platforms, we're shipping both "page" (non-persistent)
notifications and Service Worker-based Notifications. On Android,
we're only shipping Service Worker-based Notifications. Allow the
embedder to enforce this decision.

Non-persistent notifications have their event handler on the JavaScript
object constructed by "new Notifications()". We cannot reliably support
these notifications on Android, and they will lead to a bad user
experience because pages can be killed in the background at any time.

The specification is moving towards non-persistent notifications to be
true temporary ones, auto-dismissing themselves after a few seconds.
This has not been decided upon yet, however.

In the following GitHub issue on the Notification specification, Anne
agrees that it's fine to ship one, and not the other.

https://github.com/whatwg/notifications/issues/26

Android has never shipped this, and the Service Workers-based Notification
intent scopes to the ServiceWorkerRegistration.showNotification() function.
This patch does not impact functionality on desktop. We implement the
restriction by throwing a type error upon constructor invocation.

Note that the Notification object still has to be exposed on the global, for
the "permission" property and the "requestPermission" function to be usable.

This is part of a two-sided patch:
    [1] This patch.
    [2] https://codereview.chromium.org/920153002

BUG=441828
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=190152

[Peter Beverloo, 2015-02-12 21:39:50]

peter@chromium.org changed reviewers:
+ mkwst@chromium.org

[Peter Beverloo, 2015-02-12 21:39:51]

+mkwst

What do you think?

Given the very low usage of Web Notifications (UMA on the constructor shows that
0.0004% of page loads used it), and the fact that Android hasn't shipped it yet,
this is the right time to pull it out.

[Mike West, 2015-02-13 04:51:43]

Intent to Remove?

This LGTM, once you've gotten the API owners to sign off on it.

[Peter Beverloo, 2015-02-13 14:27:08]

On 2015/02/13 04:51:43, Mike West wrote:
> Intent to Remove?
> 
> This LGTM, once you've gotten the API owners to sign off on it.

I have clarified the description to put more emphasis on the fact that this does
not change what we're currently shipping. I will send a PSA to blink-dev as
well.

[Peter Beverloo, 2015-02-13 14:40:27]

On 2015/02/13 14:27:08, Peter Beverloo wrote:
> I have clarified the description to put more emphasis on the fact that this
does
> not change what we're currently shipping. I will send a PSA to blink-dev as
> well.

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BygptYClroM

[Peter Beverloo, 2015-02-13 15:32:50]

On 2015/02/13 14:40:27, Peter Beverloo wrote:
> On 2015/02/13 14:27:08, Peter Beverloo wrote:
> > I have clarified the description to put more emphasis on the fact that this
> does
> > not change what we're currently shipping. I will send a PSA to blink-dev as
> > well.
> 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BygptYClroM

Per Mike's comment on the other CL (https://codereview.chromium.org/920153002/),
I'll land this now and gate landing that patch on not getting any concerns on
the PSA thread. Thanks for the review! :-).

[Peter Beverloo, 2015-02-13 15:32:54]

The CQ bit was checked by peter@chromium.org

[commit-bot: I haz the power, 2015-02-13 15:33:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/901843006/1

[commit-bot: I haz the power, 2015-02-13 15:36:52]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=190152