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.
- Remove duplicate platform specific (from src/) and other unnecessary
files
- Fix and update vapi-*.js files for Safari
- Add tools/make-safari.sh
- Move js/vapi-appinfo.js to meta/ (so, every vendor specific file will be
at the same location)
Adds possibility to build extension files (Chrome and Safari) from
command line.
To run from the project directory:
python tools/build.py [meta]
If the optional `meta` argument is set, then only the manifest and
language files are uptated.
Without that everything is being built (extension files too) into the
`dist/build/version_number` folder.
For Chrome there will be two files, a crx, and a .zip file which
includes the key.pem private key (so this must not be shared,
it's just a bit help for publishing it to the Chrome Web Store).
Beside the extension files, update-files are generated too (for self
hosting - Safari needs it).
Safari's extension API doesn't provide a way to intercept requests
initiated by plugins, so those cases need special care (or at least the
popular sites).
This commit adds a new JS file (sitepatch-safari.js), which will store the
patches (if it's possible to create one) for specific sites.
As an example, this commit includes a technique for removing in-video ads
from YouTube videos.
... for the sake of portability.
When including vapi-common.js in an HTML file, then the body element there
will have a "dir" attribute filled with the current locale's direction
(ltr or rtl).
The following languages are considered right-to-left: ar, he, fa, ps, ur.
Everything else is left-to-right.
After the "dir" attribute is set, we can decide in CSS which elements
should have different styling for rtl languages (e.g., body[dir=rtl] #id).
Benefits:
- Cross browser solution (however only for relatively new browsers)
- Doesn't need extra permission in Chrome
If the browser doesn't suppor the download attribute, then a new tab will
be opened with the exported data.
Other changes:
- Start the download only if the data is not empty (previously the
download started anyway)
- Reorder code in vapi-client.js for Safari, so unnecessary code doesn't
run on extension pages
By default, Safari doesn't resize the popup to its content, but it's
possible to set the size pragmatically.
The popup will be resized every time when a change happens in the DOM tree.
.jshintrc's otion-set is a personal choice, merely a suggestion.
Beside that, it includes some common globals for specific browsers, so
there's no need to set the globals in every .js file.
In order to force strict coding, "use strict" directive was added into
every .js file.
Deathamns