This repository has been archived by the owner on Jul 29, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6
Replace inlined content with copied content #101
Labels
enhancement
New feature or request
Comments
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
jonathanmayer
added a commit
that referenced
this issue
Jun 7, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We made a decision some time ago to inline WebScience content scripts, HTML, and other asset dependencies. The upside was that developers using the library wouldn't have to deal with managing WebScience files, which could be tedious and introduce both subtle versioning issues and difficult to debug dependency issues. As we've implemented the inlining approach, we've encountered a number of downsides, including requiring special Content Security Policy permissions, inability to narrowly scope CSP permissions for worker scripts, compatibility challenges for Chromium browsers, future-proofing risks for WebExtensions manifest v3, and difficulty reviewing bundled extensions. While we were starting to reconsider this decision, it became apparent that Mozilla AMO review would have hesitancy (at best) about the CSP permissions required for the inlining approach to work. So, we need to make a change.
The best (or least-bad) approach seems to be a Rollup plugin that handles WebScience file management for extension developers. This alternative approach will minimize burden and risk for developers, with the drawbacks that using WebScience would depend on using Rollup and we'd need to maintain a special Rollup plugin (since there doesn't appear to be a sufficient existing plugin).
The text was updated successfully, but these errors were encountered: