templates/intros/events.html

<p>
An <code>Event</code> is an object
that allows you to be notified
when something interesting happens.
Here's an example of using the
<code>chrome.alarms.onAlarm</code> event
to be notified whenever an alarm has elapsed:
</p>

<pre>
chrome.alarms.onAlarm.<b>addListener(function(</b>alarm<b>) {</b>
  appendToLog('alarms.onAlarm --'
              + ' name: '          + alarm.name
              + ' scheduledTime: ' + alarm.scheduledTime);
<b>});</b>
</pre>

<p>
As the example shows,
you register for notification using <code>addListener()</code>.
The argument to <code>addListener()</code>
is always a function that you define to handle the event,
but the parameters to the function depend on
which event you're handling.
Checking the documentation for
$(ref:alarms.onAlarm),
you can see that the function has a single parameter:
an $(ref:alarms.Alarm) object
that has details about the elapsed alarm.
</p>

Example APIs using Events:
$(ref:alarms),
{{?is_apps}}
$(ref:app.runtime),
$(ref:app.window),
{{/is_apps}}
$(ref:i18n),
$(ref:identity),
$(ref:runtime).
Most <a href="api_index">chrome APIs</a> do.

{{^is_apps}}
<div class="doc-family extensions">
<h2 id="declarative">Declarative Event Handlers</h2>

<p>
The declarative event handlers provide a means to define rules consisting of
declarative conditions and actions. Conditions are evaluated in the browser
rather than the JavaScript engine which reduces roundtrip latencies and allows
for very high efficiency.
</p>

<p>Declarative event handlers are used for example in the <a
href="declarativeWebRequest">Declarative Web Request API</a> and <a
href="declarativeContent">Declarative Content API</a>. This page describes
the underlying concepts of all declarative event handlers.
</p>

<h3 id="rules">Rules</h3>

<p>The simplest possible rule consists of one or more conditions and one or more
actions:</p>
<pre>
var rule = {
  conditions: [ /* my conditions */ ],
  actions: [ /* my actions */ ]
};
</pre>

<p>If any of the conditions is fulfilled, all actions are executed.</p>

<p>In addition to conditions and actions you may give each rule an identifier,
which simplifies unregistering previously registered rules, and a priority to
define precedences among rules. Priorities are only considered if rules conflict
each other or need to be executed in a specific order. Actions are executed in
descending order of the priority of their rules.</p>

<pre>
var rule = {
  id: "my rule",  // optional, will be generated if not set.
  priority: 100,  // optional, defaults to 100.
  conditions: [ /* my conditions */ ],
  actions: [ /* my actions */ ]
};
</pre>

<h3 id="eventobjects">Event objects</h3>

<p>
<a href="events">Event objects</a> may support rules. These event objects
don't call a callback function when events happen but test whether any
registered rule has at least one fulfilled condition and execute the actions
associated with this rule. Event objects supporting the declarative API have
three relevant methods: $(ref:events.Event.addRules),
$(ref:events.Event.removeRules), and
$(ref:events.Event.getRules).
</p>

<h3 id="addingrules">Adding rules</h3>

<p>
To add rules call the <code>addRules()</code> function of the event object. It
takes an array of rule instances as its first parameter and a callback function
that is called on completion.
</p>

<pre>
var rule_list = [rule1, rule2, ...];
function addRules(rule_list, function callback(details) {...});
</pre>

<p>
If the rules were inserted successfully, the <code>details</code> parameter
contains an array of inserted rules appearing in the same order as in the passed
<code>rule_list</code> where the optional parameters <code>id</code> and
<code>priority</code> were filled with the generated values. If any rule is
invalid, e.g., because it contained an invalid condition or action, none of the
rules are added and the
  $(ref:runtime.lastError) variable is set when
the callback function is called. Each rule in <code>rule_list</code> must
contain a unique identifier that is not currently used by another rule or an
empty identifier.
</p>

<p class="note">
<strong>Note:</strong> Rules are persistent across browsing sessions. Therefore,
you should install rules during extension installation time using the
<code>$(ref:runtime.onInstalled)</code>
event. Note that this event is also triggered when an extension is updated.
Therefore, you should first clear previously installed rules and then register
new rules.
</p>

<h3 id="removingrules">Removing rules</h3>

<p>
To remove rules call the <code>removeRules()</code> function. It accepts an
optional array of rule identifiers as its first parameter and a callback
function as its second parameter.
</p>

<pre>
var rule_ids = ["id1", "id2", ...];
function removeRules(rule_ids, function callback() {...});
</pre>

<p>
If <code>rule_ids</code> is an array of identifiers, all rules having
identifiers listed in the array are removed. If <code>rule_ids</code> lists an
identifier, that is unknown, this identifier is silently ignored. If
<code>rule_ids</code> is <code>undefined</code>, all registered rules of this
extension are removed. The <code>callback()</code> function is called when the
rules were removed.
</p>

<h3 id="retrievingrules">Retrieving rules</h3>

<p>
To retrieve a list of currently registered rules, call the
<code>getRules()</code> function. It accepts an optional array of rule
identifiers with the same semantics as <code>removeRules</code> and a callback
function.
</p>

<pre>
var rule_ids = ["id1", "id2", ...];
function getRules(rule_ids, function callback(details) {...});
</pre>

<p>
The <code>details</code> parameter passed to the <code>callback()</code> function
refers to an array of rules including filled optional parameters.
</p>

<h3 id="performance">Performance</h3>

<p>
To achieve maximum performance, you should keep the following guidelines in
mind:
<ul>
  <li><p>Register and unregister rules in bulk. After each
  registration or unregistration, Chrome needs to update internal data
  structures. This update is an expensive operation.</p>
  <p>Instead of</p>
  <pre>
var rule1 = {...};
var rule2 = {...};
chrome.declarativeWebRequest.onRequest.addRules([rule1]);
chrome.declarativeWebRequest.onRequest.addRules([rule2]);</pre>
  <p>prefer to write</p>
  <pre>
var rule1 = {...};
var rule2 = {...};
chrome.declarativeWebRequest.onRequest.addRules([rule1, rule2]);</pre>
  <li>Prefer substring matching over matching using regular expressions in a
  $(ref:events.UrlFilter).  Substring based matching is extremely fast.
  <p>Instead of</p>
  <pre>
var match = new chrome.declarativeWebRequest.RequestMatcher({
    url: {urlMatches: "example.com/[^?]*foo" } });</pre>
  <p>prefer to write</p>
  <pre>
var match = new chrome.declarativeWebRequest.RequestMatcher({
    url: {hostSuffix: "example.com", pathContains: "foo"} });</pre>
  <li>If you have many rules that all share the same actions, you may merge
  the rules into one because rules trigger their actions as soon as a single
  condition is fulfilled. This speeds up the matching and reduces memory
  consumption for duplicate action sets.
  <p>Instead of</p>
  <pre>
var condition1 = new chrome.declarativeWebRequest.RequestMatcher({
    url: { hostSuffix: 'example.com' } });
var condition2 = new chrome.declarativeWebRequest.RequestMatcher({
    url: { hostSuffix: 'foobar.com' } });
var rule1 = { conditions: [condition1],
              actions: [new chrome.declarativeWebRequest.CancelRequest()]};
var rule2 = { conditions: [condition2],
              actions: [new chrome.declarativeWebRequest.CancelRequest()]};
chrome.declarativeWebRequest.onRequest.addRules([rule1, rule2]);</pre>
  <p>prefer to write</p>
  <pre>
var rule = { conditions: [condition1, condition2],
             actions: [new chrome.declarativeWebRequest.CancelRequest()]};
chrome.declarativeWebRequest.onRequest.addRules([rule]);</pre>
</ul>
</p>
</div>
{{/is_apps}}

{{^is_apps}}
<div class="doc-family extensions">
<h2 id="filtered">Filtered events</h2>

<p>Filtered events are a mechanism that allows listeners to specify a subset of
events that they are interested in. A listener that makes use of a filter won't
be invoked for events that don't pass the filter, which makes the listening
code more declarative and efficient - an <a href="event_pages">event
  page</a> page need not be woken up to handle events it doesn't care
about.</p>

<p>Filtered events are intended to allow a transition from manual filtering
code like this:</p>

<pre>
chrome.webNavigation.onCommitted.addListener(function(e) {
  if (hasHostSuffix(e.url, 'google.com') ||
      hasHostSuffix(e.url, 'google.com.au')) {
    // ...
  }
});
</pre>

<p>into this:</p>

<pre>
chrome.webNavigation.onCommitted.addListener(function(e) {
  // ...
}, {url: [{hostSuffix: 'google.com'},
          {hostSuffix: 'google.com.au'}]});
</pre>

<p>Events support specific filters that are meaningful to that event. The list
of filters that an event supports will be listed in the documentation for that
event in the "filters" section.</p>

<p>When matching URLs (as in the example above), event filters support the same
URL matching capabilities as expressible with a
  $(ref:events.UrlFilter), except for scheme and port
matching.</p>

</div>
{{/is_apps}}