Firefox support

[equim]

Hi,

This is a really nice way to mostly reproduce uMatrix with mv3. It's also quite useful to debug the server side Content-Security-Policy.

I've started playing around with it in firefox.

Problems I've been able to solve:

• Manifest side_panel and sidePanel permission are not supported. Adding an action.default_popup works. Can also add a sidebar_action though it seems less discoverable.
• Manifest background.service_worker is background.scripts. Both can be present and are ignored if unsupported.
• Storage API requires a browser_specific_settings.gecko.id in manifest.
• The styling of the matrix with hidden advanced columns leaves an empty column. I guess firefox doesn't like the visibility:collapse. Can fix with display:none.
• The report button clicks don't work with the listener on the body element. Can just add listeners on each button.

I can make a PR to fix all these.

But there are more issues:

The webRequest.onHeadersReceived listener seems to get the headers after they have been changed by the declarativeNetRequest rules. That means we don't get the server suggested policy and we don't keep the directives that we don't manage in the UI. So far the only way around this I've seen is to use a blocking webRequest which maybe defeats the whole point of the extension?

There's also a rather alarming issue where adding or abandoning a session rule makes subsequent reloads of the tab completely bypass the rules set by the extension. Still trying to understand that.

Any thoughts on the above are welcome.

[equim]

The webRequest.onHeadersReceived listener seems to get the headers after they have been changed by the declarativeNetRequest rules. That means we don't get the server suggested policy and we don't keep the directives that we don't manage in the UI. So far the only way around this I've seen is to use a blocking webRequest which maybe defeats the whole point of the extension?

For this, changing all the declarativeNetRequest modifyHeader rules on Content-Security-Policy to append rather than set means we see both the original server policy and the one we append in the onHeadersReceived listener. It also means we restrict the policy further than the server one rather than replace (which can make it less restrictive). That seems like a good thing anyway but Chrome doesn't support the append on Content-Security-Policy header so we still have a difference in behaviour between browsers.

That leads me to questions on the current behaviour in Chrome:

1. we automatically "passthrough" the server policy for security headers that we don't expose in the UI, e.g. frame-ancestors, but this only happens in the onHeadersReceived listener which isn't blocking so doesn't apply to the initial page load. Is that right? Don't we want to apply these security directives on the initial page load?
2. should we (at least optionally) only make any rules applied in matrix³ more restrictive than the server policy?