Non-standard
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Obsolete since Gecko 48 (Firefox 48 / Thunderbird 48 / SeaMonkey 2.45)
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.
Service Workers based on SocialAPI are deprecated, and were removed in Firefox 48. You can use Service Workers or Shared Workers to accomplish some of the same capabilities.
This Service worker is part of Mozilla's Social API. If you are looking for information on the new W3C ServiceWorker proposal for caching, http response control , etc., go to the ServiceWorker landing page instead.
A Service Worker inherits all the limitations and behaviors available to HTML5 Shared Workers. It can create XMLHttpRequests, use WebSockets, receive messages from windows and the browser, use IndexedDB, and post messages to other windows.
The Worker can use the ononline
, onoffline
, and navigator.online
methods and properties that are available to all Workers to obtain notification of the browser's online/offline status.
In addition to the standard methods, Service Workers have access to additional functionality, all of which is implemented using messages sent and received by worker "message ports". As message ports are inherently asynchronous, any message that requires a response will involve two messages - one for the request and one for the response. Not all messages require a response - this is part of the message specification. Messages that don't require a response are analogous to an unsolicited 'event'. If a message does require a response, then the response must always be sent on the same port as the request and in general, the 'topic' of the response will be the topic of the request with "-response" appended.
Service workers are expected to provide a function at global scope, named onconnect
. The browser will invoke onconnect
at startup time, passing in an event. The worker should access the ports
property of this event to extract a stable communication port back to the browser, and persist it for the life of the worker, like this:
var apiPort;
var ports = [];
onconnect = function(e) {
var port = e.ports[0];
ports.push(port);
port.onmessage = function (msgEvent)
{
var msg = msgEvent.data;
if (msg.topic == "social.port-closing") {
if (port == apiPort) {
apiPort.close();
apiPort = null;
}
return;
}
if (msg.topic == "social.initialize") {
apiPort = port;
initializeAmbientNotifications();
}
}
}
// send a message to all provider content
function broadcast(topic, data) {
for (var i = 0; i < ports.length; i++) {
ports[i].postMessage({topic: topic, data: data});
}
}
Every message has a data element with 2 fields; 'topic' and 'data'. The topic identifies which method or event is being used, and the data specifies additional data unique to the topic. All standardized methods and events have topics that begin with "social." - this means services are free to use topics without this prefix as a private implementation detail (for example, to communicate between some content from the service and the service's worker).
For a message with topic topic
and arguments (arg1:val1, arg2:val2), construct an object like:
{ topic: topic, data: { arg1: val1, arg2: val2 } }
social.initialize
Sent by the browser during startup. When a worker's JavaScript has been successfully loaded and evaluated, the browser will send a message with this topic. When the worker receives the social.initalize event
, it should send both the social.user-profile
and, if Page Marks are supported [as of Fx23], the social.page-mark-config
message.
social.port-closing
Sent by the browser during worker shutdown, when a MessagePort to the worker is about to be closed. This will be the last message the worker receives on the port.
social.reload-worker
Sent by the worker to request the browser to reload the worker.
social.cookies-get
Sent by the worker to request the browser to respond with a list of same-origin cookies for the provider. The browser will respond with a social.cookies-get-response
message.
social.request-chat
Sent by the worker to request the browser to open a new floating chat panel with the specified url. Chat windows opened by the worker will be opened in a minimized mode.
Arguments:
url
String, required. The url to the chat page to open in the window.
social.user-profile
Sent by the worker to set the properties for the provider icon and user profile data used for the toolbar button. If the user's portrait and userName are absent, the button UI will indicate a logged out state. When indicating logged out state, status icons set via social.ambient-notification
will be removed. A service that does not handle user login should send this message with values appropriate to the website, such as the site icon, home url, and brand name.
Arguments:
iconURL
String, required. If supplied, specifies the URL to a 16x16 pixel image used for the status icon. The iconURL can be a data url with encoded image to avoid additional http requests (e.g., "data:image/png;base64,...data...").
portrait
String, optional. If supplied, specifies the URL to a 48x48 pixel image of the user. The portrait can be a data url with encoded image to avoid additional http requests.
userName
String, optional. Account name displayed with the portrait in the provider menu.
displayName
String, required. Real name of the user used for display purposes in various UI elements.
profileURL
String, required. URL to the logged in user's profile page. This will be opened in a normal browser tab when the username is clicked on.
social.ambient-notification
Sent by the worker to update or create an ambient notification icon. One is sent for each icon. A user must be logged in to show status icons, and you must call social.user-profile
prior to calling social.ambient-notification
to set status icons.
Arguments:
label
String, optional. An label for the icon tooltip, which otherwise defaults to the name given in the manifest.
iconURL
String, optional. If supplied, specifies the URL to a 16x16 pixel image used for the status icon. The iconURL can be a data url with encoded image to avoid additional http requests (e.g., "data:image/png;base64,...data...").
counter
Number, optional. Specifies a number that will be overlaid over the icon, typically used to convey an
unread
concept.
contentPanel
String, optional. Specifies the URL of content that will be displayed in the popup panel for the icon.
social.notification-create
Sent by the worker to create and display a notification object. This requests that the browser notify the user of an immediately-relevant change in state. See /en/DOM/navigator.mozNotification for more detail. When the user clicks on the notification, the social.notification-action
message is sent to the worker. The title of the notification will always be the name of the provider.
NOTE: We want to augment the mozNotification object defined in the docs with an additional "type" field. Details TBD. NOTE: No way of allowing duration and no way exposed to "cancel" a notification (assumption is they are very short-lived). Is this OK?
Arguments:
id
String: An ID for the notification. This ID will not be displayed but will be passed back via a
social.notification-action
event if the user clicks on the notification.
type
String: The Type string should be consistent for each type of notification. This may be used by some notification systems to provide user-level filtering of notifications. A provider may choose any string for the type, but should keep the type strings consistent and descriptive for each type of action. For example, chat notifications should always have the same type string. Suggested/example notifications include:
icon
String/null. The URL of an image to be placed in the notification. While this can be any valid URL, implementers are strongly encouraged to use a data URL to minimize latency.
body
String: The body of the notification message. This body will be rendered as a hyperlink and may be clicked. HTML markup is not supported.
action
String: An action to perform when the user clicks on the notification. If no action is provided, the notification is not clickable. Currently the only actions supported are link, callback, and openServiceWindow. If the action is defined, actionArgs should also be defined.
actionArgs
Object: An object with arguments for actions (above). Supported actions and their actionArgs are:
social.notification-action
Sent to the worker as a response to a "callback" notification, after the user has clicked on the notification.
Arguments: None
id
String: the ID of the notification that was clicked.
action
String: The action sent in
social.notification-create
.
actionArgs
Object: The actionArgs sent in
social.notification-create
.
Available starting Firefox 24
You may fetch and set your manifest data. This allows you to check if the manifest for your provider in Firefox is up to date, and allows you to update the manifest if necessary. When you update your manifest, any content loaded from your provider will be reloaded automatically. It is recommended you use the version attribute on the manifest to track versioning of your provider.
social.manifest-get
Sent by the worker to request the installed manifest data from Firefox. This message can be sent at any time. Firefox will respond with a social.manifest message containing the manifest data.
Arguments: None
social.manifest-set
Sent by the worker to update the installed manifest data in Firefox. This message can be sent at any time. Firefox will reload the provider after saving the new manifest.
Arguments:
data
JSON Object. The manifest data.