feature request: domain-specific css/javascript/cookies/userscript

[herrsimon]

Part of this feature request is (somewhat) related to #440

Can we have different sets of stylesheets/userscripts and js/cookie-settings for every domain? This is currently somewhat achievable via autocommands but not in a satisfactorial way. Let me explain a bit:

css/userscript: It would be very useful if we could specify different scripts.js and style.css files per domain. The most important use case here is ad-blocking, i.e. do element-hiding, which wyedadblock is not capable of. The wyedadblock author proposes to parse adblock files to a single, very large tylesheet file, but this not only slows down vimb but also produces lots of unwanted behaviour as one always has to apply the css-rules of all domains in the adblock-file.

js: Here we can only turn on js globally for every page, so that also scripts from third party sites are executed. It would be nice to have some sort of control over which pages are allowed to execute scripts.

cookies: here again, we can either accept cookies from no or all third party sites (cookie-accept=origin/always), but not only specific third party websites.

proposed solutions:

css/userscript: The obvious, but very time-consuming solution would be to program a full-fledged adblocker as a webextension (basically a clone of umatrix for Firefox/Chrome) which can parse adblock files and injects the css. Alternatively, the problem can largely be solved by simply adding properties to set stylesheet/userscript-files dynamically via a property (set stylesheet-file=$FILE, set user-scripts-file=$FILE). This would still not be able to reproduce

js/cookies: Here, a blacklist/whitelist-file (settable via a property, for example set scripts-whitelist=$FILE etc.) containing domains would be a good solution. These settings could coexist with the existing scripts-setting, so that for example if set scripts=on, then only scripts on pages not on scripts-blacklist would be executed (and in the same way, with set scripts=off, pages on the whitelist would still execute scripts). Global scripts activation/deactivation is retained by unsetting scripts-whitelist/scripts-blacklist. The same logic can be applied to cookies: origin ignores cookie-whitelist/cookie-blacklist, never still loads cookies for domains on cookie-whitelist and always does not load cookies for domains on cookie-blacklist.

For the javascript functionality, one could reuse yett in a userscript-file, provided the userscript-js is inserted at the top of the page.

[herrsimon]

as a followup regarding css/userscript: another elegant solution would be to add specific configuration files containing lines of the form $REGEX $STYLEFILE where vimb would apply $STYLEFILE for URIs matching $REGEX.

[fanglingsu]

@herrsimon Thank you for your suggestions. I've to think about this a little more. There where multiply request in the past for doing some URL-REGEX based changes. We have :autocmd in vimb that was initially thought to solve such URL based config changes. But the paradigm of the :autocmd borrowed from vim does not fit very well for web pages as in vimb with files or buffers.

If you go further with your idea, we could also make this more generic and allow to toggle all settings base on REGEX to the opened URL. Not sure how to replace this in a config file or by runtime setting. Maybe something similar to the :augroup like :reg[exgroup] {name} {PATTERN}.

:reg badpages .*facebook.com.*|.*google.com.*
:set scripts=off
:set style-sheet-file=...
:reg end

But this looks a little bit complicated for me. Maybe we should only add a single command that allows to store an ex-command to a regex. Something like :regex {name} {PATTERNS} {ex-cmd} and a command to remove such a named regex later. This would allow the user to :source a dedicated config file based on the opened URL.

But the main challenge of doing regex based setting changes is to roll them back if another URL is opened. E.g. if you enable scripts for a good page and follow a link to a bad one, the scripts are still enabled. So there must be a way to switch back to default settings or to undo the setting changes done only for the good page.

[imiric]

Hi, is there any update on this issue? Per-site JS/CSS would be great.

The autocommand syntax could work well for this, but currently there's no way to configure specific files, only to disable or enable support, which is not granular enough.