CloudServices/Notifications/Push/API: Difference between revisions

CloudServices/Notifications/Push/API (view source)

1,027 bytes added , 4 February 2012

no edit summary

Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti

4,925

edits

@@ Line 20: / Line 20: @@
       attribute Function onsuccess;
       attribute Function onerror;
- };
 <tt>requestRemotePermission()</tt> asks the user if they'd like to allow this site
@@ Line 99: / Line 98: @@
 The format of the payload is still TBD; it's a toss-up between
 JSON blobs and form-urlencoded parameters.
+<i><pre>
+(No feedback mechanism is listed, so I'm putting it here; feel free to point me elsewhere :-)
+-- Is the "body" plain text or HTML, or something else?
+-- Are clients forced to support actionURL (the notification system currently used in Ubuntu, for example, specifically removed support for clicking on a notification to take an action)?
+-- What are the rules, if any, about cookie-sending and Referer and Origin when the actionURL is accessed?
+-- Are there maximum lengths for any of the fields?
+-- What about icons of multiple sizes?
+-- Does iconURL lead to a privacy issue because the site can see if the user has read the notification? Can we allow, or require, inline icons?
+-- Are there rules or guidelines to avoid accidentally clashing replaceIDs, such as a "org.mozilla.notification-somerandomstring" convention?
+-- How can we mitigate the problem of one (authorized) site spoofing notifications that look like those from another site? Will the in-browser UI show the origin of the notification?
+Gerv</pre></i>
 HTTP Status Codes: