Change add/remove event listener behavior for service workers

This changes addEventListener() and removeEventListener() to not throw even
after the very first evalution of the service worker script. Instead, this
specifies user agents have to show a console warning that the asynchronously
added listener's event type will not affect service worker's behavior with the
functional event stored during the first evaluation.

This change referneces the funcional event concept defined in Service Workers
spec, and confines the EventTarge object of the specified behavior to
ServiceWorkerGlobalScope object instead of all the platform object in the global
object.

Related SW issue: w3c/ServiceWorker#1004.
Related SW PR: w3c/ServiceWorker#1322.
Fixes whatwg#371.

dom.bs

@@ -1062,15 +1062,18 @@ and an <a>event listener</a> <var>listener</var>, run these steps:
 
 <ol>
  <li>
-  <p>If <var>eventTarget</var>'s <a>relevant global object</a> is a {{ServiceWorkerGlobalScope}}
-  object and its associated <a>service worker</a>'s <a for="service worker">script resource</a>'s
-  <a for="script resource">has ever been evaluated flag</a> is set, then <a>throw</a> a
-  <code>TypeError</code>.
-  [[!SERVICE-WORKERS]]
-
-  <p class="note no-backref">To optimize storing the event types allowed for the service worker and
-  to avoid non-deterministic changes to the event listeners, invocation of the method is allowed
-  only during the very first evaluation of the service worker script.
+  <p>If <var>listener</var> observes a <a>functional event</a>, <var>eventTarget</var> is a
+  {{ServiceWorkerGlobalScope}} object, and its associated <a>service worker</a>'s <a for="service
+  worker">script resource</a>'s <a for="script resource">has ever been evaluated flag</a> is set,
+  then the user agent must show a message on a developer console that the user agent stores the event
+  <a for="event listener">type</a> of the <a>functional event</a> for the <a>service worker</a> only
+  during the very first evalution of the <a>service worker</a> script, and the asynchronously added
+  <a>functional event</a> will not start the <a>service worker</a>. [[!SERVICE-WORKERS]]
+
+  <p class="note no-backref">To optimize storing the event types allowed for the <a>service
+  worker</a>, Service Workers specification does not store the asynchronously added event <a
+  for="event listener">type</a>. The <a>event listener</a> will still be added under this condition,
+  but the implmentations have to inform developers about this behavior.
 
  <li><p>If <var>listener</var>'s <a for="event listener">callback</a> is null, then return.
 
@@ -1118,11 +1121,13 @@ and an <a>event listener</a> <var>listener</var>, set <var>listener</var>'s
 method, when invoked, must run these steps:
 
 <ol>
- <li><p>If the <a>context object</a>'s <a>relevant global object</a> is a
- {{ServiceWorkerGlobalScope}} object and its associated <a>service worker</a>'s
- <a for="service worker">script resource</a>'s
- <a for="script resource">has ever been evaluated flag</a> is set, then <a>throw</a> a
- <code>TypeError</code>. [[!SERVICE-WORKERS]]
+ <li><p>If <var>type</var> is one of the <a>functional events</a>'s <a for="event
+ listener">type</a>, the <a>context object</a> is a {{ServiceWorkerGlobalScope}} object, and its
+ associated <a>service worker</a>'s <a for="service worker">script resource</a>'s <a for="script
+ resource">has ever been evaluated flag</a> is set, then the user agent must show a message on a
+ developer console that the user agent will still start the <a>service worker</a> for the
+ <a>functional event</a> that has been stored during the very first evalution of the <a>service
+ worker</a> script and is asynchronously removed. [[!SERVICE-WORKERS]]
 
  <li><p>Let <var>capture</var> be the result of <a>flattening</a> <var>options</var>.