Added reply field to blink NotificationEvent (not yet piped through)

third_party/WebKit/Source/modules/notifications/NotificationEvent.idl

Index: third_party/WebKit/Source/modules/notifications/NotificationEvent.idl
diff --git a/third_party/WebKit/Source/modules/notifications/NotificationEvent.idl b/third_party/WebKit/Source/modules/notifications/NotificationEvent.idl
index 1e102df2948f9d834d2980524746a2a67860d797..ccb94161a8ac184422714165ffeade172108931d 100644
--- a/third_party/WebKit/Source/modules/notifications/NotificationEvent.idl
+++ b/third_party/WebKit/Source/modules/notifications/NotificationEvent.idl
@@ -11,4 +11,5 @@
 ] interface NotificationEvent : ExtendableEvent {
     [ImplementedAs=getNotification] readonly attribute Notification notification;
     readonly attribute DOMString action;
+    readonly attribute DOMString reply;

[Peter Beverloo, 2016/09/30 11:10:22]

If we were to land this as-is, then the following feature check would pass
regardless of whether inline replies are enabled:

    NotificationEvent.prototype.hasOwnProperty('reply')

That breaks feature detection, and will confuse developers. Instead, we should
guard this behind the following annotation:

    [RuntimeEnabled=NotificationInlineReplies]

That means that the attribute will only be exposed if the
NotificationInlineReplies feature is enabled, which is, in turn, guarded by the
--enable-experimental-web-platform-features command line flag.

Because this changes the Web Exposed API surface, even if it's not in stable,
you'll also need to update another file:

   
LayoutTests/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt

That file lists all the interfaces, as well as their methods and attributes,
that are exposed by Blink.

(I'd strongly recommend that you just run try jobs immediately after uploading a
CL, or a new version of a CL. They're great at identifying these things :-))

 };