Compatibility/System Addon/Initial Planning

ARCHIVED

This page has been archived and its contents may be out of date.

Prior Art

Opera Presto: http://www.opera.com/docs/browserjs/
Opera Blink: https://github.com/operasoftware/browserjs/blob/master/OPRdesktop/browserjs-28.0.js (a less powerful version of browser.js)
Vivaldi is said to have something similar (citation needed)

Firefox for Android has a dynamic User Agent string override mechanism (see ua-update.json: https://dxr.mozilla.org/mozilla-central/source/mobile/android/app/ua-update.json.in).

Pros: simple; out of band CDN updates

Cons: only on Fennec, applies to all requests for a given domain, i.e., no conditional spoofing. simple regex tweaks only.

Modifying User Agent with UserAgentOverrides.jsm and SiteSpecificUserAgent.js: https://bugzilla.mozilla.org/show_bug.cgi?id=1127448

Pros: works.

Cons: has to ride trains. might require a dot release depending on the site and severity.

Pros: Get’s the job done.

Cons: Has to ride trains; Might require a dot release depending on the site and severity.

Ability for developers to see that a site patch is enabled, with short explanation and link to bug (likely via developer console).
Ability to temporarily disable site patch for developers to test fixes.
Ability to modify page CSS
Ability to mutate page DOM
Ability to modify script (inline, external) source before execution
Ability to hook into page load lifecycle events (script execution, CSS parsing, event handlers, etc). See http://www.opera.com/docs/userjs/specs/#evlistener
Ability for a site patch to target a specific URI rather than entire origin.
Ability to define setters and getters for page variables and methods (question for Hallvord: scope?)
Injected JS should not have chrome privileges
Injected JS should have full access to page
Site patches should not run if modified by user.
Possibly access/modify HTTP headers? (Unclear how useful this is, Karl is supposed to suggest a use case here.)