Confirm
796
edits
Changes
Add explainer for Web Compat go faster add-on
== Introduction ==
The WebCompat go faster add-on proposes to provide a site patching mechanism for Firefox users. A site patch is defined as an origin- or path-scoped block of JavaScript that runs in the context of a web page.
By using the go faster system add-ons infrastructure and delivery mechanism, we can add and remove top web property site patches via out of band updates (i.e., not tied to the release train cadence). The intention is to provide a means to fix urgent issues until outreach efforts are successful, or until platform bugs or regressions are shipping in release builds as fixed.
== Use Cases ==
* A top site has a bug that affects Firefox users that can be worked around by modifying navigator.userAgent:
** trailers.apple.com blocking Firefox users on OS X 10.11 and above, but videos work when sending a Chrome user agent. https://bugzilla.mozilla.org/show_bug.cgi?id=1262149
** YouTube stopped serving MSE/WebM to Firefox 43 users, due to a server side UA parsing bug. Worked around by hard coding 42 in UA string, for youtube.com (until they fixed): https://bugzilla.mozilla.org/show_bug.cgi?id=1233970
* Firefox ships a regression in release breaking top sites
* Hiding messages such as "Best seen in Chrome”, or unsupported browser banners or redirected pages in top sites. e.g., Bank of America on OSX, https://bugzilla.mozilla.org/show_bug.cgi?id=1280834
* Working around widely deployed libraries or frameworks that don't support Firefox, have bugs, or make bad assumptions about Gecko, e.g., BrightCove and Ooyola serving HLS over .m3u8 to Firefox for Android on Android 4 (which is not supported) or greater but mp4 to Android 3 (which is supported).
* Temporarily shim APIs that have been removed until top site is updated (e.g. showModalDialog).
* A top site relies on a (mostly) shimmable non-standard API, e.g., window.event
== Current solutions to use cases ==
* 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.
* Hard coding User Agent hacks in Navigator.cpp: https://bugzilla.mozilla.org/show_bug.cgi?id=1233970#c11
'''Pros''': Get’s the job done.
'''Cons''': Has to ride trains; Might require a dot release depending on the site and severity.
== Requirements ==
* 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.)
== TODO ==
1. Define a policy for Site Patching.
2. Determine what is and isn't possible today via XPCOM; file bugs where needed
3. Build a prototype for UA overrides
4. Develop infrastructure to validate if patches are still needed, or are still working (i.e., once a week)
The WebCompat go faster add-on proposes to provide a site patching mechanism for Firefox users. A site patch is defined as an origin- or path-scoped block of JavaScript that runs in the context of a web page.
By using the go faster system add-ons infrastructure and delivery mechanism, we can add and remove top web property site patches via out of band updates (i.e., not tied to the release train cadence). The intention is to provide a means to fix urgent issues until outreach efforts are successful, or until platform bugs or regressions are shipping in release builds as fixed.
== Use Cases ==
* A top site has a bug that affects Firefox users that can be worked around by modifying navigator.userAgent:
** trailers.apple.com blocking Firefox users on OS X 10.11 and above, but videos work when sending a Chrome user agent. https://bugzilla.mozilla.org/show_bug.cgi?id=1262149
** YouTube stopped serving MSE/WebM to Firefox 43 users, due to a server side UA parsing bug. Worked around by hard coding 42 in UA string, for youtube.com (until they fixed): https://bugzilla.mozilla.org/show_bug.cgi?id=1233970
* Firefox ships a regression in release breaking top sites
* Hiding messages such as "Best seen in Chrome”, or unsupported browser banners or redirected pages in top sites. e.g., Bank of America on OSX, https://bugzilla.mozilla.org/show_bug.cgi?id=1280834
* Working around widely deployed libraries or frameworks that don't support Firefox, have bugs, or make bad assumptions about Gecko, e.g., BrightCove and Ooyola serving HLS over .m3u8 to Firefox for Android on Android 4 (which is not supported) or greater but mp4 to Android 3 (which is supported).
* Temporarily shim APIs that have been removed until top site is updated (e.g. showModalDialog).
* A top site relies on a (mostly) shimmable non-standard API, e.g., window.event
== Current solutions to use cases ==
* 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.
* Hard coding User Agent hacks in Navigator.cpp: https://bugzilla.mozilla.org/show_bug.cgi?id=1233970#c11
'''Pros''': Get’s the job done.
'''Cons''': Has to ride trains; Might require a dot release depending on the site and severity.
== Requirements ==
* 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.)
== TODO ==
1. Define a policy for Site Patching.
2. Determine what is and isn't possible today via XPCOM; file bugs where needed
3. Build a prototype for UA overrides
4. Develop infrastructure to validate if patches are still needed, or are still working (i.e., once a week)
