Installation of userscripts in Opera in general cases and for secure pages (https)
For some userscripts it starts to matter how the user installs it in the Opera browser. If you make the installation without allowing access to some domains, the work will be inadequate, and this can easily happen when installing a cross-domain script, and even using the secure protocol (HTTPS). For example, for the HabrAjax user script , besides the main Habr site, access to the Google Plus buttons on plusone.google.com is used and script updates are checked on the domain userscripts.org . All this requires additional settings, which were described right in the user script (link in the settings " note for Opera "), but made quite briefly and with one illustration. Here we will look at the question more broadly so that Opera users and developers of user scripts for it have instructions at hand and fully understand the breadth of the question. At the same time, described the installation site user styles. For those who know all this, it will be useful to look at the paragraph of conclusions with 2 comments at the very bottom.
The first feature of the work of userscripts in Opera is that special BeforeScript events do not work for them, which work fine for ordinary scripts and provide cross-browser compatibility. Therefore, if we want to work with another domain in the frame, userscript should provide access to another domain, which means that the main site and the site located in the frame must be specified in the script settings for the sites - strictly in accordance with what is written in meta -directory script for other browsers.
The second peculiarity is that if sites work under the https: protocol, they need to set the permission for users to use scripts in this protocol - the general setting of the Opera, which will then often remind you of itself. If you do not want to do this, there is a way out in the design of user scripts as an addon. Now - more.
Users scripts in Opera can run a lot of users. Just look at the usage statistics of HabrAjax in browsers, which 26 people agreed to give, it is clear that 8 people installed the script on Opera (not excluding other browsers). By the way, if you used HabrAjax, please vote in this poll: " In which browser do you use HabrAjax ?". It will help to collect more statistics.
')
For reference, for those who have not yet installed users in the Opera, see the instructions below. It is not the easiest, but the whole focus of this article is that for protected pages with userscripts it is even more complicated. Not everyone also knows that there are not one but two ways to install scripts in Opera (not counting add-ons); in instructions - both are illustrated. Mobile Opera also has all the possibilities of working with userscripts and user styles, but the settings for resolving functions can be disabled in opera: config and you will need to verify them if something doesn't work (beyond the scope of the article).
1. You can install a user script (without addon mechanism, introduced in version 11) in Opera in 2 modes : for all sites at once, with the use of script meta-directives, or for a certain site on the same domain (and there can be many such sites) . User scripts accepted as the de facto standard in 2 main browsers (Firefox and Chrome) have meta directives - several commented lines, usually located at the beginning of the user script file. They contain URLs in which scripts operate, so the installation of work rules is determined by directives and requires a single click on the “Allow installation” button in these browsers. In the Opera, it was initially not so, but it was better than at the dawn of the introduction of user scripts, when Safari started scripts for all sites at once, and only the actions of the script itself could select the group of URLs in which it continued to work. Therefore, the first mode (for all sites) is a repetition of a primitive way of running scripts, but with improvements in terms of understanding directives.
The second way - to prescribe settings for sites - goes away from the modern way of setting up userscripts through directives. But they are left in the Opera due to the fact that the sites can be manually set a lot of limitations and features, including individual styles and scripts. These 2 methods somewhat conflict with each other: using the second one blocks the work of the first method (scripts from the shared folder are not launched, even if they have the necessary directives) for the selected site. This should be understood when prescribing individual settings, as it is not obvious. We will show this general information with illustrations.
1.a) Open the browser and its General Settings (Ctrl-F12 or from the menu, as shown).
Hereinafter we will show Opera 11.61 in WinXP OS with the theme of the (Shift-F12) Netbook Skin v.11.3 - for compactness:
1.b) Open the tab " Tools - General Settings - Advanced - Content - Configure Javascript " - we get into the settings of the 1st mode of user scripts. If you place the script in the Folder of user files specified in the settings, it will be executed in each browser window. If you write directives include , as usual for scripts, with the indication of sites, it will be filtered by directives in other sites. Scripts are rarely left without directives. Not always the script written for a specific site can work correctly everywhere (do nothing on all other sites), and the resources for the initial launch of the script in each window will be spent.
Features of userscripts: if there is a script with include directives in the shared scripts folder and there are more precise settings for sites for the same site (“Settings for sites ...” button), it is not executed. The script is not required to have the extension * .user.js, * .js is sufficient. Scripts are executed in alphabetical order of their file names, case insensitive (in Win at least).
1.c) Similar to scripts, there are settings for common styles: for all sites, for each window in " Tools - General Settings - Advanced - Content - Customize Styles ... ".
They can also have side effects on non-their sites, if we put the style for a specific site in a folder for all sites (the inscription on the screenshot is “ My Style Sheet ”). A similar primitive feature is in IE7-9 and Safari. Therefore, individual sites settings for scripts and styles are made for sites in Opera.
Individual settings of scripts and styles that are only available to Opera among the major browsers are also an outdated and outdated phenomenon against the background of addons that Opera supports (from the 11th version), because the work on the browser settings for the user is much more than when installing the addon .
1.d) Open " Tools - General Settings - Advanced - Content - Settings for Sites ... " to install scripts and styles for some sites. Since all other settings are set to normal, you need to pay attention to 3 places: the domain name, the path to the styles for the site, the path to the scripts for the site (to the scripts folder).
So, it turns out that if the site has at least one feature other than scripts, for example, custom styles, then the scripts are forced to write not in the common script folder with the effect of directives, but in Settings for sites. Then, if more than one site is mentioned in the directives, it is also necessary for them to set up the settings for the sites . If the script is in the common scripts folder, you can rely on user script directives - they will work.
The general description of 2 installation options for user scripts in Opera and their features has been completed. But there is another feature, after which it will be clear that the difficulties of the browser interfaces are just beginning.
2. What to do if there are URLs with a secure https protocol among the sites? Such sites Opera simply does not allow to work with userscripts. They do not work by default. Allow users to use scripts on such sites by installing a browser:
" opera: config # on% 20https " (write this in the address bar; will show the desired setting in the section "User Prefs")
- User JavaScript on HTTPS - Checked (select checkbox)
- " Save " (click the button below in this section)
- restart the Opera browser.
This installation will deliver a lot of unpleasant minutes in the future. On each site with HTTPS, it will ask the same question (when you first access the site after opening the browser or after changing the script): "And it doesn’t matter that the user script is not going to look into this domain. You open, say, GMail - the question will be (the first time). After restarting the Opera - again.
Uninstalling an intrusive parameter cannot be avoided even when running a script from a shared folder - and this permission is required in the settings.
The imperfection of the paranoid and illogical issue is unlikely to be corrected in the near future - the company has many more serious bugs that have been hanging for years. It would be logical to have more flexible settings (UserJS on https in the “Settings for sites”) and ask for permission only when the browser has a user script for working on this site. Therefore, in order to achieve perfection, you will have to abandon this method of https resolution and try to create an addon by script.
(In order for Opera to not feel lonely among the bugs of userscripts, in the next article we will examine Chrome's bug (2.5 years from the date of its execution) with access to the next frame and its solution.)
The transition from user scripts to add-ons is a different amount of developer fuss around codes and browser options. Cross-browser user scripts are a convenient way to design and publish. The developer does not need a special environment for compiling browser variants. Therefore, the developer is less dependent on the workplace. More precisely, independent. A text editor is enough to correct or add userscript.
It is also convenient for the user to work with one file. At least, Firefox and Chrome require 2 clicks to download and confirm the installation. In Safari, too, although NinjaKit doesn’t even support GreaseMonkey’s functions — Firefox’s user support environments that exist as a de facto standard. In Opera, if you don’t make settings for sites — there’s also a bit of a fuss — copy the file to the common scripts folder.
But, starting with “customization” (in a bad sense) across browsers, it gets worse for everyone. The user needs to know that there are different script hosting sites for different browsers. He needs to restart the browser in most cases. One convenience - the same 1-2 clicks for installation, not counting the restart.
It is even worse for the developer because the logic of customization goes beyond the limits of one language (JS) and spreads to the build script or to a set of its own manual build and publishing rules in different places. Therefore, whenever possible, it is necessary to strive for minimal confusion of technologies in customization across browsers. But since Opera can’t do a decent job with HTTPS scripts, you’ll have to look into the problems of building addons.
There is also a crazy idea - to create cross-browser add-ons that work everywhere with one code, distinguished by the letters of extensions. This is also very suitable for Safari, for which there is no full support for userscripts (problems, for example, in the implementation of cross-domain exchange). True, IE7-9 will also need a unique solution that goes back to user scripts, because the user scripts format for IE add-ons is a classic user script with a lot of limitations and, of course, a difference in JS logic.
That is the price of the decision to go to the addon instead of user scripts. If both parties - the developers and the user group - agree to the transition to the addon, in order to avoid problems with HTTPS, go to the instructions for creating the addon in Opera.
As a positive factor, we get more flexible and new features in add-ons, which are partially inaccessible in user scripts. For example, the moment of launching scripts is determined more flexibly, styles are set before the document is created, therefore the picture of the site does not “jump” in the first second after loading.
At this we allow ourselves to interrupt the allowed speeches, and the creation of the add-on is analyzed next time, in order to complete the theme of the features of creating user scripts for Opera.
The installation in the Opera of such a multifunctional script as HabrAjax , supplemented by user styles ( ZenComment ), containing work with several sites and protected pages (https), comes up against 2 features of the installation. Depending on the type of installation (in the general directory or in the site specific), if individual site settings are set, you need to remember to set up the same script settings for all sites mentioned in the include directives. Or put the script in a shared directory, but specify it in the individual settings. Otherwise there will be bewilderment - why do not the auxiliary functions work? Bug No, it will not be a bug, but insufficient settings. And if the script works with protected pages (and it has to work with them, if there is a cross-domain exchange), it is necessary to include the HTTPS permission for userscripts, which further hinders the “live in peace” on the Opera. Salvation - in addons, but about it - next time.
(The article is from the general pool of articles generated by working with user scripts for Habr.)
The first feature of the work of userscripts in Opera is that special BeforeScript events do not work for them, which work fine for ordinary scripts and provide cross-browser compatibility. Therefore, if we want to work with another domain in the frame, userscript should provide access to another domain, which means that the main site and the site located in the frame must be specified in the script settings for the sites - strictly in accordance with what is written in meta -directory script for other browsers.
The second peculiarity is that if sites work under the https: protocol, they need to set the permission for users to use scripts in this protocol - the general setting of the Opera, which will then often remind you of itself. If you do not want to do this, there is a way out in the design of user scripts as an addon. Now - more.
How to start a simple one-site user script in Opera?
Users scripts in Opera can run a lot of users. Just look at the usage statistics of HabrAjax in browsers, which 26 people agreed to give, it is clear that 8 people installed the script on Opera (not excluding other browsers). By the way, if you used HabrAjax, please vote in this poll: " In which browser do you use HabrAjax ?". It will help to collect more statistics.
')
For reference, for those who have not yet installed users in the Opera, see the instructions below. It is not the easiest, but the whole focus of this article is that for protected pages with userscripts it is even more complicated. Not everyone also knows that there are not one but two ways to install scripts in Opera (not counting add-ons); in instructions - both are illustrated. Mobile Opera also has all the possibilities of working with userscripts and user styles, but the settings for resolving functions can be disabled in opera: config and you will need to verify them if something doesn't work (beyond the scope of the article).
1. You can install a user script (without addon mechanism, introduced in version 11) in Opera in 2 modes : for all sites at once, with the use of script meta-directives, or for a certain site on the same domain (and there can be many such sites) . User scripts accepted as the de facto standard in 2 main browsers (Firefox and Chrome) have meta directives - several commented lines, usually located at the beginning of the user script file. They contain URLs in which scripts operate, so the installation of work rules is determined by directives and requires a single click on the “Allow installation” button in these browsers. In the Opera, it was initially not so, but it was better than at the dawn of the introduction of user scripts, when Safari started scripts for all sites at once, and only the actions of the script itself could select the group of URLs in which it continued to work. Therefore, the first mode (for all sites) is a repetition of a primitive way of running scripts, but with improvements in terms of understanding directives.
The second way - to prescribe settings for sites - goes away from the modern way of setting up userscripts through directives. But they are left in the Opera due to the fact that the sites can be manually set a lot of limitations and features, including individual styles and scripts. These 2 methods somewhat conflict with each other: using the second one blocks the work of the first method (scripts from the shared folder are not launched, even if they have the necessary directives) for the selected site. This should be understood when prescribing individual settings, as it is not obvious. We will show this general information with illustrations.
1.a) Open the browser and its General Settings (Ctrl-F12 or from the menu, as shown).
Hereinafter we will show Opera 11.61 in WinXP OS with the theme of the (Shift-F12) Netbook Skin v.11.3 - for compactness:
1.b) Open the tab " Tools - General Settings - Advanced - Content - Configure Javascript " - we get into the settings of the 1st mode of user scripts. If you place the script in the Folder of user files specified in the settings, it will be executed in each browser window. If you write directives include , as usual for scripts, with the indication of sites, it will be filtered by directives in other sites. Scripts are rarely left without directives. Not always the script written for a specific site can work correctly everywhere (do nothing on all other sites), and the resources for the initial launch of the script in each window will be spent.
Features of userscripts: if there is a script with include directives in the shared scripts folder and there are more precise settings for sites for the same site (“Settings for sites ...” button), it is not executed. The script is not required to have the extension * .user.js, * .js is sufficient. Scripts are executed in alphabetical order of their file names, case insensitive (in Win at least).
1.c) Similar to scripts, there are settings for common styles: for all sites, for each window in " Tools - General Settings - Advanced - Content - Customize Styles ... ".
They can also have side effects on non-their sites, if we put the style for a specific site in a folder for all sites (the inscription on the screenshot is “ My Style Sheet ”). A similar primitive feature is in IE7-9 and Safari. Therefore, individual sites settings for scripts and styles are made for sites in Opera.
Individual settings of scripts and styles that are only available to Opera among the major browsers are also an outdated and outdated phenomenon against the background of addons that Opera supports (from the 11th version), because the work on the browser settings for the user is much more than when installing the addon .
1.d) Open " Tools - General Settings - Advanced - Content - Settings for Sites ... " to install scripts and styles for some sites. Since all other settings are set to normal, you need to pay attention to 3 places: the domain name, the path to the styles for the site, the path to the scripts for the site (to the scripts folder).
So, it turns out that if the site has at least one feature other than scripts, for example, custom styles, then the scripts are forced to write not in the common script folder with the effect of directives, but in Settings for sites. Then, if more than one site is mentioned in the directives, it is also necessary for them to set up the settings for the sites . If the script is in the common scripts folder, you can rely on user script directives - they will work.
The general description of 2 installation options for user scripts in Opera and their features has been completed. But there is another feature, after which it will be clear that the difficulties of the browser interfaces are just beginning.
The work of userscripts on pages with a secure protocol HTTPS
2. What to do if there are URLs with a secure https protocol among the sites? Such sites Opera simply does not allow to work with userscripts. They do not work by default. Allow users to use scripts on such sites by installing a browser:
" opera: config # on% 20https " (write this in the address bar; will show the desired setting in the section "User Prefs")
- User JavaScript on HTTPS - Checked (select checkbox)
- " Save " (click the button below in this section)
- restart the Opera browser.
This installation will deliver a lot of unpleasant minutes in the future. On each site with HTTPS, it will ask the same question (when you first access the site after opening the browser or after changing the script): "And it doesn’t matter that the user script is not going to look into this domain. You open, say, GMail - the question will be (the first time). After restarting the Opera - again.
Uninstalling an intrusive parameter cannot be avoided even when running a script from a shared folder - and this permission is required in the settings.
The imperfection of the paranoid and illogical issue is unlikely to be corrected in the near future - the company has many more serious bugs that have been hanging for years. It would be logical to have more flexible settings (UserJS on https in the “Settings for sites”) and ask for permission only when the browser has a user script for working on this site. Therefore, in order to achieve perfection, you will have to abandon this method of https resolution and try to create an addon by script.
(In order for Opera to not feel lonely among the bugs of userscripts, in the next article we will examine Chrome's bug (2.5 years from the date of its execution) with access to the next frame and its solution.)
Creating an addon of the Opera and add-on issues in general
The transition from user scripts to add-ons is a different amount of developer fuss around codes and browser options. Cross-browser user scripts are a convenient way to design and publish. The developer does not need a special environment for compiling browser variants. Therefore, the developer is less dependent on the workplace. More precisely, independent. A text editor is enough to correct or add userscript.
It is also convenient for the user to work with one file. At least, Firefox and Chrome require 2 clicks to download and confirm the installation. In Safari, too, although NinjaKit doesn’t even support GreaseMonkey’s functions — Firefox’s user support environments that exist as a de facto standard. In Opera, if you don’t make settings for sites — there’s also a bit of a fuss — copy the file to the common scripts folder.
But, starting with “customization” (in a bad sense) across browsers, it gets worse for everyone. The user needs to know that there are different script hosting sites for different browsers. He needs to restart the browser in most cases. One convenience - the same 1-2 clicks for installation, not counting the restart.
It is even worse for the developer because the logic of customization goes beyond the limits of one language (JS) and spreads to the build script or to a set of its own manual build and publishing rules in different places. Therefore, whenever possible, it is necessary to strive for minimal confusion of technologies in customization across browsers. But since Opera can’t do a decent job with HTTPS scripts, you’ll have to look into the problems of building addons.
There is also a crazy idea - to create cross-browser add-ons that work everywhere with one code, distinguished by the letters of extensions. This is also very suitable for Safari, for which there is no full support for userscripts (problems, for example, in the implementation of cross-domain exchange). True, IE7-9 will also need a unique solution that goes back to user scripts, because the user scripts format for IE add-ons is a classic user script with a lot of limitations and, of course, a difference in JS logic.
That is the price of the decision to go to the addon instead of user scripts. If both parties - the developers and the user group - agree to the transition to the addon, in order to avoid problems with HTTPS, go to the instructions for creating the addon in Opera.
As a positive factor, we get more flexible and new features in add-ons, which are partially inaccessible in user scripts. For example, the moment of launching scripts is determined more flexibly, styles are set before the document is created, therefore the picture of the site does not “jump” in the first second after loading.
At this we allow ourselves to interrupt the allowed speeches, and the creation of the add-on is analyzed next time, in order to complete the theme of the features of creating user scripts for Opera.
Practical conclusions
The installation in the Opera of such a multifunctional script as HabrAjax , supplemented by user styles ( ZenComment ), containing work with several sites and protected pages (https), comes up against 2 features of the installation. Depending on the type of installation (in the general directory or in the site specific), if individual site settings are set, you need to remember to set up the same script settings for all sites mentioned in the include directives. Or put the script in a shared directory, but specify it in the individual settings. Otherwise there will be bewilderment - why do not the auxiliary functions work? Bug No, it will not be a bug, but insufficient settings. And if the script works with protected pages (and it has to work with them, if there is a cross-domain exchange), it is necessary to include the HTTPS permission for userscripts, which further hinders the “live in peace” on the Opera. Salvation - in addons, but about it - next time.
(The article is from the general pool of articles generated by working with user scripts for Habr.)
Source: https://habr.com/ru/post/140643/
All Articles