Ublock: [Enhancement] Seamless element hiding (Chrome)

[narcolepticinsomniac]

Parse and enforce cosmetic filters. Enabling this feature increases uBlock₀'s memory footprint.

Selecting this option still results in cosmetic filters being applied late in the page load, resulting in flickering which tends to be pretty drastic shifts in page layouts.

I assume this is the trade-off you're willing to make to avoid the overhead of injecting the stylesheet as a straight up userscript which is understandable, but I don't think this trade-off is necessary since there's already a better method of applying stylesheets more efficiently.

For the better part of the last year, the Stylish extension has been improved to apply stylesheets virtually seamlessly, arguably faster and less glitchy than a userscript and without the major memory drain.

Hopefully this method could be incorporated in Ublock:
https://github.com/JasonBarnabe/stylish-chrome/blob/master/apply.js

[gorhill]

What Stylish does and what uBO does are completely different. The challenge with ABP filter lists, somethign which Stylish does not have to deal with, is the injection of 14,000+ CSS rules in every page and frames -- 20,000+ CSS rules if using Fanboy Social, etc. I know how to inject styles early in the page, uBO does this for specific cosmetic filters, the challenge are the generic ones.

[narcolepticinsomniac]

Fanboy's Ultimate has almost 26,000 generic filters. I've been experimenting to see if it's possible to inject all of them early in the page without it being a straight up userscript, thus eliminating the glitching of non-cached generic filters. I spent way more time and effort on this than I originally anticipated, so I hope you'll give it a shot.

The main problem with applying filters in a stylesheet is that Chrome will only parse so many selectors before it bails on the whole process, including the rendering of the actual page. If you enter a brick wall of selectors in the Stylish Editor, you can actually see the point where Chrome gives up since the Codemirror colors stop functioning around the same number of characters consistently (roughly 500 selectors).

Breaking down the list into more digestible pieces is the next logical step, but even then you'd be left with one enormous stylesheet. I didn't have a lot of faith in that working well, so I skipped it in favor of a method I thought might actually work.

Stylish is set up to have multiple styles within a style using @-moz-doc, so I figured breaking the list into a bunch of "substyles" that are simultaneously injected might do the trick, and upon initial testing, it does seem to work very well.

I extracted all generic filters from Fanboy's Ultimate List and divided them into substyles of one style.They'd probably have fit into 50, but I was eyeballing it, so it wound up being 53.

To test, disable everything but Fanboy's Ultimate List with "Parse and enforce cosmetic filters" enabled.

A few test url's:
(header ads)
http://www.wonderhowto.com/
http://www.theguardian.com/us
(social garbage)
http://www.ebaumsworld.com/pictures/view/84892280/
http://www.worldstarhiphop.com/videos/

Filters are late to be applied when not cached with "Parse and enforce cosmetic filters" enabled.

Install Stylish. Copy the style I made, go to manage/write a new style/select import/paste/select overwrite/name & save.

The import feature is relatively new and was never intended for, and probably never tested with, a style this big. It saves correctly but the browser needed a restart for it to take effect.

Disable Parse and enforce cosmetic filters, wipe history/cache, and revisit the test sites. No more glitches.

The social filters are at the bottom, so the whole list seems to be working.

I haven't seen any noticeable speed issues (besides faster element hiding) and the memory consumption seems pretty low.
Fanboy Ultimate Cosmetic Filters.txt
Let me know what you think.

[gorhill]

To me your test cases are pretty much non-issue: it happens once, the first time you visit the site, after this, all generic cosmetic filters seen before on that site are injected early in the page load. The styles you made are FF-specific, uBO's code is not FF-specific.

Look, my approach is, if I have an idea, I go ahead and create a prototype, and if it works, I keep working on it. I do not implement others' idea of a prototype/experiment. I still have ideas of things to try with uBO to improve efficiency and all -- including for cosmetic filtering, so I am busy enough with my own stuff. If you have ideas, just fork and go ahead, code is GPL.

[narcolepticinsomniac]

Yeah, Stylish converts the @-moz-doc so it works in Chrome. It's just an easier way to install it.

As someone who keeps their browser history/cache cleared (via extension), filters being applied late happens every "first time" you visit a site which is pretty annoying and a real shame because uBO is so much better than any alternative in every other aspect.

I'm semi-decent with CSS but not much beyond that, so I don't foresee any forking in my forking future.

It seems like it could be a serious upgrade without much of a downside, but if you don't consider it to be an issue worth fixing, I won't waste my time trying to convince you. It was worth a shot.

[gorhill]

because uBO is so much better than any alternative

If uBO was injecting all the generic CSS rules unconditionally it would stop being "so much better": this holds back the page every time it loads, and causes significant memory overhead every time for web pages (because this is injected in every page _and_ frames).

[narcolepticinsomniac]

I was referring to all the advance features. The ease of blocking/unblocking specifically/globally is brilliant, the element picker is much better, plus all the other optional tweaks and toggles.

Honestly, if there was an option to inject global rules as a userscript to avoid flickering at the cost of higher memory and a slight hit to speed, I'd check that box in a heartbeat. On most modern computers the extra resources used are hardly noticeable. That's not to say that a better method wouldn't be preferable, which is why I started playing around with it to begin with.

Judging by the memory Stylish is using applying the stylesheet, this method is incredibly more efficient. The only issue would be if speed took a real hit, which it hasn't seem to. The testing I did was not extensive so either could be worse than I figure.

None of that really matters though, because your take on it seems to be that it's a non-issue, therefore it doesn't need to be fixed. When you said the challenge was injecting 20,000+ filters in every page, I figured that meant you were open to a more efficient method than a userscript, but it seems that what you meant is that you believe there is no way of doing this efficiently enough to be worthwhile since the issue it resolves seems unimportant to you.

"I do not implement others' idea of a prototype/experiment" seems pretty close minded for open source, but that's your prerogative.

[CrisBRM]

@narcolepticinsomniac If you enjoy bloat and want to apply cosmetic filters that way, disable cosmetic filtering globally and install adblock plus.
uBlock was literally created because abp did this.

[gorhill]

"I do not implement others' idea of a prototype/experiment" seems pretty close minded for open source, but that's your prerogative.

_"The Cathedral and the Bazaar"_:

Every good work of software starts by scratching a developer's personal itch.

You are asking me to scratch your personal itch. I don't do this, I use my own free time to scratch my own itches, not those which are not mine. Having ideas is easy, validating with working prototype is where the hard work is -- do not use me to prototype _your_ ideas.

[narcolepticinsomniac]

I hear you. It's not as if I had the idea and immediately began snapping my fingers expecting you to implement it. I made the original suggestion, and when you quickly shot it down, I figured I hadn't done a good enough job explaining it because I hadn't even thought it all the way through. It was just a concept that if you formatted a stylesheet correctly, generic filters could be injected in every page using far less resources than a userscript.

I figured if I could come up with a working example using FBU list (the biggest), then you could see for yourself that not only does it work, it's incredibly efficient comparatively. It took me quite a lot longer than I'd like to admit to extract the filters and come up with a working stylesheet. I've learned basic CSS on my own as a hobby, but I don't have any actual coding skills beyond that. To continue your analogy, I scratched every itch I was capable of reaching.

What never occurred to me, is that you don't view this as a flaw that needs to be fixed. I never thought of this as something that only bothered me, and I still assume the majority users find this at least mildly annoying.

When you said the challenge was injecting 20,000+ filters in every page, I took that to mean that the challenge was finding a way to do so without a massive overhead like ABP, but it seems you're already resolved to the fact that there is no satisfactory method of injecting such a stylesheet to justify any additional overhead, regardless of efficiency.

I never intended to be argumentative, and I still don't, so I hope that's not how this is coming across. I did think I was offering a solution and providing a working example to the best of my abilities.

[elypter]

reminds me that i had a very similar discussion. unfortunately i cant fork either.

[gorhill]

unfortunately i cant fork either.

Why?

It's just the usual, _"I know exactly how to make uBO so much better, but unfortunately I can't prove it because... reasons"_. Talk is cheap, that is exactly why there is _"DO NOT: ... Submit revolutionary ideas"_ in CONTRIBUTING. It's not for me to go through writing code to make the case that someone else's idea is wrong.

[elypter]

its not that people are demanding this from you. you would instead say "i have a lot of ideas on my own that i want to implement first. if one day i cant think of anything better or anyone joins this project then it might get done but its low priority" people wouldnt be so pissed. everyone understands that you dont have infinite free time and its normal to do your own things first. and people dont think in the categories "your ideas" vs "my ideas". they just want to make the software better.

[gorhill]

The issue in OP is:

there's already a better method of applying stylesheets more efficiently

Injecting 17,000+ CSS selectors in every page and frames is the problem. If the proposed solution still requires to inject these 17,000 CSS selectors, then it solves nothing (there are other bad consequences aside memory and CPU usage for doing this).