Initializing the extension with AddonManager takes too long (at least for
this extension).
When starting the browser, tabs loaded before the extension could, and
because of that, blocking didn't work.
It works better, if it's initialized when the window's DOM is ready.
Pass the extension data (name and version) as the fragment of the URL
for the background script, so vAPI.app can be filled without using XHR
to read the manifest files.
The purpose of this API is basically to satisfy AMO reviewers in the
future, since the use of innerHTML with variables (i.e., not plain text) will
be rejected without any questions.
Since this is not a problem for browsers other than Firefox, they will
use simple innerHTML assignment, however safe-parsing could be implemented
for them too.
Test a[href^="abp:"], since the protocol probably not used for anything
else, also "a", because ABP checks only anchors, and these links are made
only for ABP.
Also, the event target is not always the link, so at least some parents
should be tested as well.
The purpose of this API is basically to satisfy AMO reviewers in the
future, since the use of innerHTML with variables (i.e., not plain text) will
be rejected without any questions.
Since this is not a problem for browsers other than Firefox, they will
use simple innerHTML assignment, however safe-parsing could be implemented
for them too.
vAPI.sessionId - random ID generated every time when a page loads.
Having the dialog in an iframe lowers the chance of interference with the
styling of the page, also avoids using innerHTML (AMO complaint).
Now both nsIContentPolicy and on-http-* observers are used for net request
monitoring.
Reasons:
- In many cases, nsIContentPolicy.shouldLoad is invoked twice for the same
resource, because of the speculative parsing.
- nsIContentPolicy.shouldLoad don't have information about the channel,
so it can't redirect the request, nor change its headers, however
on-http-opening-request can.
Also, local mirroring and inline-script blocking has been implemented.