You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 29, 2024. It is now read-only.
content scripts could message-pass with the background script/serviceworker to determine if they should run
a list of allowed domains could be inlined into the content scripts
Since WebScience is built by the caller, I think both of these are pretty easy to do. The trade-offs are that (1) involves more messaging and runtime overhead, and (2) will cause content scripts to be larger on average, but no messaging would be required and the content scripts could run totally standalone.
(1) is probably the most flexible, and it might end up mattering if there are several content scripts that filter on a very large set of match patterns.
The text was updated successfully, but these errors were encountered:
Firefox supports dynamically loading content scripts, but until Chrome ships an equivalent API we don't have a way to restrict content scripts to only run on certain domains (specified as match patterns).
In PR #281 we attempted to write a roll-up plugin to generate entries , but Chrome cannot handle the ~4k sample of domains from the Beyond the Paywall study that I tested.
A few approaches come to mind:
Since WebScience is built by the caller, I think both of these are pretty easy to do. The trade-offs are that (1) involves more messaging and runtime overhead, and (2) will cause content scripts to be larger on average, but no messaging would be required and the content scripts could run totally standalone.
(1) is probably the most flexible, and it might end up mattering if there are several content scripts that filter on a very large set of match patterns.
The text was updated successfully, but these errors were encountered: