27
edits
Changes
→Extension
* '''TabbedBrowserWatcher''': There is no single technique you can use to receive all relevant page or navigation-related notifications. Additionally, different kinds of notifications give you different kinds of information, often leaving you with insufficient information with which to work (e.g., you know there's a new request, but you have no way of knowing which DOMWindow or even browser is responsible for it).<br><br>For this reason each controller has-a <code>TabbedBrowserWatcher</code> that adds a level of indirection to the whole mess. The tabwatcher flattens all the load/unload- and tab-related events in a browser window by attaching to the tabbedbrowser, browsers, documents, and frames and sending sane notifications to the controller about what's happening. It also provides utilities for locating Documents that have a particular URL loaded, the browser that has a particular Document loaded, and the like.
* '''ListManager''': There is a single <code>ListManager</code> responsible for downloading and updating white and black lists when enhanced protection is disabled. The actual deserialization (from the updater server's response) is handled by a set of ''wire format'' utilitiesdb update XPCOM service, as is serialization (from an updated table to local disk). The lists are stored in the user's profile directory, and are updated roughly hourlyevery 30 minutes.
* '''TRTables''': Since white and blacklists can be expressed in many different ways (lookup tables by domain, lookup tables by URL, etc), we have a simple abstraction that knows how to look URLs up in tables of these various kinds. For each type of white/blacklist (map), we have a TRTable that knows how to look items up in a list of that type. A TRTable is-a Map with a specialized findexists() method that knows the semantics of the name/value pairs it stores. These tables are serializable/deserializable by the wire format utilitiesstored in a mozStorage database.
==== Execution Context ====
For these reasons, the extension runs in its own context. This is achieved by having a bootstrap loader that is a self-registering XPCOM component. This component uses the subscript loader to load application js files into its context. Only small amounts of "glue" code exist in the browser window context, and these pieces of glue essentially just call into the application context to do the heavy lifting.
==== Server Backoff ====
Providing the data on the server for updates and lookups requires a fair amount of resources. To help maintain a high quality of service, it may be necessary for the update and lookup servers to ask the client to make less frequent requests. To handle this, the client watches for HTTP timeouts or errors from the server and if too many errors occur, it increases in the time between requests. If remote lookups start to fail, we fall back on using the tables provided during update requests.
Update requests happen every 30 minutes by default. However, if the client receives an error during update, it tries again in a minute. If it receives three errors in a row, it waits for 60 minutes before trying again. If it then receives another error, it waits for 180 minutes, if it receives another error, it waits 360 minutes. It will continue to check once every 360 minutes until the server responds with a success message.
A lookup request happens on page load if the user has opted into remote checking. If a lookup request fails, we automatically fall back on a local table. If there are 3 lookup failures in a 10 minute period, we wait 10 minutes before trying again. Each successive lookup failure increases the wait by (2*last wait + 10 minutes). The maximum wait before trying again is 360 minutes.
In both the update requests and lookup requests, once the server starts to send successful HTTP replies, the error stats are reset.
=== The Server Side ===
