Userscript: Crossbrowser, Crossdomain

Development of the user script HabrAjax overcame its regular problems with cross-browser support for new functions and created a pleiad of articles (7 pieces that have not yet been published) on various issues related mainly to user scripts and their cross-domain access. All these articles are non-trivial, their topics are partially covered on the Internet, and some are not covered even in the descriptions of browser bugs (or the author does not know foreign language solutions). Articles will have to be laid out in an arbitrary order, because there is no reason to sort them in any way - each is related to the other only by subject. Now I will give announcements of articles, without links, in order to put together an idea of ​​what will be discussed in the future. The implementation is in HabrAjax, but there is quite a lot of application code, not a very good example to demonstrate. Therefore, for each article there will be codes with more adapted examples, as far as possible.

Fixed idea cross-browser compatibility

Developers for users who want to ensure maximum ease of installation, to work with user scripts (or addons), it was easy to get the file and install with one click; it is even better that all cross-browser differences are taken into account within a single common file. Addons (non-cross-browser) do just that - the user just needs to say “Install” - and then he gets what he wants without much difficulty. This is why add-ons are so popular, although to generate them from a common user script, you have to write a rather complex linker.

For userscripts, you often have to write browser-dependent codes, both to overcome differences in the layout, and to take into account the features of the installation. Nevertheless, the idea to make it easier calls to make a user script that automatically takes into account the difference in the features of the installation. The first thing you have to face is the features of the browser-based installation of scripts and their understanding of metadata. A lot of worries add cross-domain interaction. When working with userscripts in different browsers, a couple of browser bugs appear during cross-site data exchange.

Requirements for the exchange of data, we will not at all as limited as usual. Usually (for the Opera) they think that we can write a function in a script on another domain, and the whole task is to execute it in an embedded script. Often we can not change the data on another domain, and get them - our task. Data needs to be retrieved:
1) arbitrary text files, which are allowed to be framed with a JS script and transmitted as a JS file (to be packaged in user scripts);
2) generally arbitrary text data from another file without the possibility of framing something;
3) any JSON hashes - in another domain.
')
The first case arises when you need to read the user script metadata in the script itself or, if you wish, write CSS styles without encoding to JS strings. There is no crossdomain yet, but the task is not entirely trivial if we want to get a single cross-browser view (in general, it cannot be solved - Firefox lacks functions, and the type “xml” introduced in GreaseMonkey is syntactically incompatible with the JS language - in other words, an alien type cannot be done cross-browser). We get the semi-permissions — the cross-browser view for the case of metadata and Scriptish instead of GreaseMonkey, or the need to slightly tweak the file by 2 characters for the Firefox browser beyond the JS capabilities — then not only metadata is read, but also arbitrary data in the * .user.js file. This, of course, is bad, but these are the realities of user scripts compatibility. The problem and possible solutions are described in detail in the article " Reading multi-line data in JS ". It goes beyond user scripts, but it is in them, in user scripts, that has a real chance of a solution.

Note that these unsolvable problems arise when we are trying to pack the data and script into a single script file (user script or simple script). If you use 2 files, there is no problem anymore, because the data from the 2nd file can be read as text or HTML (in HTML comments you can keep almost arbitrary text), and in the first one you can only keep scripts. However, a single-file solution is a good way to work with the user: he is provided with one file, which you just need to “install”. True, we forget a few about such trifles that only Chrome can install a user script natively; for Firefox, you need the GreaseMonkey add-on or Scriptish; for Opera , you need to set the settings for the site in the browser settings (this means that if the new computer is new, it’s about taking care of things and not just “installing the file”). Her addon, similar to GreaseMonkey, is in a very primitive state - you need to copy the scripts in the addon's input field, the metadata is not taken into account, so we don’t mention it. Finally, Safari also requires an addon (NinjaKit) and copying the body of the user script file to the addon editor. That is, single-file + cross-browser compatibility is already very tight.

The second and third cases of data exchange are solved by the implementation of user scripts in the domain of another domain inaccessible to the developer. Here, the solution is complicated by bugs in 2 browsers out of 4. In the articles " Hromium's walk through the cross-domain exchange in user scripts ", " Cross-domain data exchange in user scripts in Opera, " it is shown that they can be overcome.

Addon instead of user script for Opera

We warned them that we would not stop at nothing, if only the user was good? Warned. And what did they do? A lot of settings without the possibility of automation. Now we have the moral right to hit the winds - invent an add-on generation algorithm for the Opera, replacing user scripts. Because it is possible to automate the creation of the add-on, but the creation of the built-in Opera user - no. We will receive the desired solution in the form of a single “Install” button and even a place on the Opera website. How to do it - in the article " Addon for Opera from userscript ".

The same, by the way, for Safari. There is a NinjaKit - an addon closer to the capabilities of GreaseMonkey, but for some reason you need to manually copy the text of the script into it, and it cannot fully support the cross-domain request GM_XMLHTTPRequest. All this is somehow frivolous; It is not known whether this will be supported. It’s also easier to hit add-ons by solving a problem with user scripts at the same time, normally resolved in Firefox and nowhere else solved (not counting add-ons): the icon metadata directive is supported, and the icons in the list of scripts work only in Firefox. It requires a small quest to get the title of developer in the eyes of the supreme holder of all the rules, so everything is described in the article " Addon for Safari from userscript ".

Crossbrowser addons

Since we with Opera and Safari are thrown into the need to write our own add-ons, which are very different in code from user scripts (not in the sense that it is difficult to build, but a strong difference in bytes), another crazy idea appears: after all, all add-ons of all browsers are built according to general principles - zip-archive, distinguished by its extension and a number of files with very similar functions. And if we do not make a common cross-browser archive, in which it is enough just to rewrite the extension? If there are no conflicts in the file names, then the case is feasible - 4 ornate tracks will merge into one again, and the implementation will endure a single archive, including redundant browser-dependent settings. The archive builder is again simplified, consisting in a manual operation to rename the extension.

Get into someone else's garden with your userscripts

Cross domain metadata queries are half bad. It is simply solved in 2 browsers, it is difficult - in the Opera. But the decision in the Opera will seem easy if you get acquainted with a complete misfortune - providing cross-domain data exchange from third-party site frames. Reading metadata will be just a special case and children's fun using the same exchange technique for the Opera (unfortunately, they apparently have some kind of bug in user scripts with BeforeScript does not always work). How “complete trouble” is resolved - described in the article “ Hromium’s walk through the cross-domain exchange in user scripts ”, and how to use the solution to get tasty fruits from someone’s vegetable garden whose owners don’t rush to share them via API - in the article “ Compact size of Google Plus buttons ". And in fact, why spend 70 pixels horizontally, to suffer from the lack of data on the number of "likes", when most often 24 pixels are enough for 1-2-3 digits of the number of "likes"? Why do we need “talking” "+1" buttons to design our pages? Yuzerskript solves all these problems - it's up to the user to install it. The phantom of the Opera rises again and is terrified by a ton of instructions on settings - hurray, it’s not for nothing that we learned how to package scripts in addons in previous articles.

This is the most spectacular addition of user scripts made in the latest version is worth illustrating. Google+ buttons are unusually compact thanks to userscript.
(Fig. 1) ( on I-photos , imageshack )

Articles are generally ready; test cases were not worked out, except for the HabrAjax script itself, on the basis of which all these problems surfaced. Therefore, they will be published in the next week or two as they become aware of the readiness of all supporting materials. For example, I want to describe the Chromium bug bypass (there are 2.5 years; some consider it “security features”) to attach the most compact and clean user script, ready for use.

And what about HabrAjax and where to look for the implementation of crossdomain?

In short, in version 0.81 he purchased the following features:
* Direct links to personal pages to get to them not in 2-3 clicks, but in one.

(fig.2)

* Check script updates - periodically, no more than once a day (the period is configured) checks the script. It does not bother if the version is minor. (cross domain technologies)

(pic.3)

* showing features from metadata - suggests that there is a new one in it, as well as a new one on the server during validation. (cross domain technologies)

(fig.4)

* a stylish icon in the metadata (finally can turn) (there it is, at the top right).
* these frames around checkboxes are reminiscent of the last modified features.
* customizable max. the height of the drawings in the forced category (by default 120 with ZenComment). The annotation height (maximum) is twice as large.
* write a letter, highlighting a quote or the name of the author - no need to copy them manually (included setting "quote-corrector").
* Preview button in the mail .
* compact Google Plus buttons (cross domain technologies)
* Minor changes in ZenComment styles - their version (2.16) is also embedded in HabrAjax. It is convenient to use it together with scripts, but everything is done so that styles and scripts are independent. The required (as much as the minimum required) styles are written in scripts and occupy a lot (250) lines.

Yes, and about the script - to those who already use it - please participate in the survey - " In which browser do you use the HabrAjax script? " (Multiple choice of options is possible). It will help to see a picture of what browsers and OS the script is running on. If there are 2 different computers - write 2 votes in the survey (from different places). The add-on for Firefox is also important - it turned out that Scriptish is a more flexible addon, because it allows you to write cross-browser multi-line text of metadata directives (this will be covered in the article " Reading multi-line data in JS ").

UPD 18:30: Corrected obsessive bug with incorrect links around the username. Checked in Opera, Fx, Chrome. (The opera turned out to be the worst susceptible to reading the DOM, it gave out bugs of user non-prescription.) Update, please, who managed to download. At the same time, the work on reading metadata and showing what has been done in the new version will be visible (If you click the " Check for Updates" link.
UPD2: However, many Chrome users begin to show a poll.