DOM/WebIDL Review Checklist: Difference between revisions

DOM/WebIDL Review Checklist (view source)

Revision as of 13:08, 26 September 2014

1,354 bytes added , 26 September 2014

Added Ehsan's checklist items

Bzbarsky

308

edits

@@ Line 1: / Line 1: @@
 A review checklist for DOM Peers while doing WebIDL reviews. Not yet complete.
-* If the API has [Exposed=SomethingOtherThanWindow]:
+* If the API has <code>[Exposed=SomethingOtherThanWindow]</code>:
 ** Audit the API implementation to make sure it doesn't assume the existence of a Window or a Document
 ** Require basic test coverage for each of the contexts in which the API is exposed.
+* Use of <code>[CheckPermissions]</code> and <code>[AvailableIn]</code> should be preferred to doing permission checks or checks for privileged or certified apps in the implementation.
+* If an API is only intended for privileged or certified apps, it should use <code>[AvailableIn]</code>, even if it is also controlled by a permission (in which case it requires a <code>[CheckPermissions]</code> in addition to <code>[AvailableIn]</code>).
+* Please take extra care reviewing things that are hidden behind <code>[Pref]</code>s.  If an API only has a <code>[Pref]</code> annotation, and it's supposed to be something only available to a subset of Firefox OS apps, they are probably doing things wrong, because <code>[Pref]</code> only gives us platform level granularity.  IOW, when they turn on the pref on b2g, the API will end up being exposed to all content there, which is usually not what we want.  Currently the only legitimate use case for only using <code>[Pref] without either <code>[CheckPermissions]</code> or <code>[AvailableIn]</code> is for APIs that are supposed to be exposed to all Web content but we're not turning them on yet for spec or implementation stability reasons.
+* Consider whether APIs are acceptable for prerendering.  See https://wiki.mozilla.org/Gecko:Prerendering/API_Review_Guidelines for more information.