... 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).
Chrome has getManifest(), Safari doesn't have anything, Firefox has an
asynchronous API...
So, instead of using extension APIs, store the common informations
(extension name, version, homepage url) in a file (vapi-appinfo.js), which
can be included when it's needed (its data will be available at vAPI.app.____).
The file's content is updated each time the extension is being built, so
it shouldn't be modified manually.
- Add script injection to vAPI, plus a raw implementation for Safari
(element-picker.js requires it)
- Tweak element picker to work with Safari
- Revert a change from previous commit: element-picker.js' background
message handler (since actually it can have its own messaging channel)
- Don't send "undefined" reponses from background to content
- Include latest changes from gorhill/uBlock/master
- Append the pickerRoot container to document.documentElement instead
of document.body ("body > div" type CSS selectors are more common, so
they could overwrite the extension's styling with higher probability)
- Request localized strings from the background script instead of using
the i18n API in content scripts
- Fuse element-picker.js' message handling into contentscript-end.js', since
only one messaging channel can live at a time in a content script
.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.
