Adblock Plus and (a little) more
Hit counts for element hiding revisited · 2006-11-21 17:48 by Wladimir Palant
I was finally able to come up with a working (yet not exactly simple) scheme to implement hit counts for element hiding. It can also be used to show hidden elements in the sidebar and maybe even make element hiding rules respect whitelisting. There are two disadvantages however:
- This will certainly slow down things. If I implement this I will also need to implement a switch in the preferences to disable hit counts for element hiding. On the bright side, the slowdown should only occur if there really are hits, so it probably isn’t so bad.
- The solution relies on XBL so that it is subject to bug 236839. It won’t work for people who disable JavaScript (either via global settings or on per-site basis with NoScript).
The second issue is certainly the more important one, it will cause lots of confusion amongst people using Adblock Plus together with NoScript (and those should be a lot). What do you think, is it still worth doing?
Comment [9]
Commenting is closed for this article.
steve · 2006-11-21 18:40 · #
you could make a warning message, when adblock plus detects noscript/deactivated javascript. but i also think, that this will cause more confusion than benefit. i mean, is it really necessary to generate so much new problems, just because of some statistics?
it would be better when someone would fix the bug; this would not only solve your problems, but it would also help many other extensions.
Reply from Wladimir Palant:
Please do not use other people’s email addresses! If you have a problem with being notified when I answer to your comment - you can use Mailinator or any other black hole.
This isn’t just for statistics, element hiding being virtually invisible in the user interface makes problems with it very hard to investigate, especially for unexperienced users. That’s the main reason why EasyElement isn’t one of the recommended subscriptions for example.
As to fixing the bug: unfortunately it isn’t that easy, there are lots of security implications here that have to be investigated properly.
rick752 · 2006-11-22 01:36 · #
That’s a tough one.
Being able to track element-hides vs a performance hit.
I don’t know if a trade off like that would be desirable. It seems if you have to put a toggle in ABP to disable that function simply because of how slow it would become, I would say don’t bother. Remember, Wladimir, most of the changes you have been making to the program as of late were for efficiency and speed … I wouldn’t want to see you do something to ABP that would jeopardize that. It’s one of ABP’s best selling points (besides the fact that it also works real well :-)
Besides … most adjustments seem to come from the regular ad filters and not so much the element ones. The element strings are much more site-specific and seem less prone to problems.
On the other hand, it would be nice to be able to verify ‘dead’ strings without going thru the site coding.
Reply from Wladimir Palant:
As noted above, I am little concerned about the performance hit – it should be linear in the number of hidden elements and since the number of hidden elements is never particularly high it is unlikely that we will see any notable delays. This has to be properly tested of course. I should also check the memory usage which could be more of a problem. I am counting on Gecko’s implementation being sane enough that memory is only allocated once instead of using a considerable amount of memory for every filter.
The JavaScript issue is more of a concern for me. The interaction between NoScript and hit counts isn’t obvious in this case and I don’t see how warnings or anything similar are going to help here. NoScript users will see an inconsistent user interface with little chances of finding out what is going wrong.
Btw, not all element hiding filters are site specific and I actually had quite a few bug reports because of general element hiding filters (don’t remember any issues with your EasyList but there were some with other filter lists). These are really tricky ones since you really can’t point the user to http://adblockplus.org/en/tips?tip=effective_filter. I actually asked Malte Kraus to offer a version of his list with site specific element hiding only, that’s the one I recommend now.
chewey · 2006-11-22 02:59 · #
Tricky.
If it depends on JS being activated, I think it should at least not be on by default.
Being able to make element hiding rules respect whitelisting rules would be great, this is the most common element hiding rule problem users contact me about.
(The second BTW being people reporting my element hiding rules doing nothing, because ‘they have no hits’ – what could be trivially “fixed” by adding something like ‘not applicable’ in the hit counter row for those)
Of course, a hit counter for element hiding rules would be great to detect rules that don’t do anything anymore (e.g. because of changes in some site’s code), but it doesn’t seem to be worth all the tradeoffs to me. After all, hit counters are sort of an additional gimmick – sometimes a very useful one, agreed, but a gimmick nonetheless.
If it really has that big an impact on performance and even conflicts with other popular extensions (or settings) – i.e. JS being off – I don’t think it should be added as a default feature at the moment.
However, in case this conflict can be resolved (e.g. by getting bug 236839 fixed), I’d vote for it. Showing everything filtered and hidden in the sidebar and making all the rules respect whitelisting would be a big improvement. If the loss of performance stays reasonable, this would greatly enhance ABP’s behavioural consistency, especially for less experienced users.
alta88 · 2006-11-22 21:21 · #
Agreed, very tricky question.. Short answer would be unfortunately no, and this coming from someone who is big into stats, visual info re state of an app, verbose logs, but I’m thinking of the average user and absolute confusion until the XBL bug is solved.
The question leads to a bigger issue of how to usefully handle elements in ABP. We all know the next step in the ad war will move to elements; imo this is the primary area of focus for ABP in the near term. WP, you know I think ABP is the best engineered extension by far, so please indulge some ‘long answer’ comments ;)
1. I don’t use ABP for elements (other than rick’s premade list), but rather Stylish. It’s just easier, familiar css, sorta rebelled against yet another syntax, it had Apply first, etc. There’s no tool to get the element path, just manual DOMi (webdeveloper has something very close but not quite), xpath has issues as WP has mentioned before. I want to use ABP, the function belongs there, but it’s not comfortable. So when testing recently, blinking elements in ABP did nothing – cause I had them blocked in Sylish.
2. Agree with chewey – there can’t be inconsistency in the user experience between ad urls/filters/regexps and elements. Certainly elements should show an N/A for hit count if it isn’t determinable. Should have whitelisting for both. If it looks like an ad, smells like an ad, then ABP has to handle it – user doesn’t care how it got on the page technically.
3. Although it’s not ready for general release, I would like to see this implemented under the covers as a power tweak. It would be reason to move elements into ABP out of Stylish. Yhoo has been rather hard and must be very finely tuned with combination of url and elements; hit counts will help a lot. I’d disagree that hit counts are a gimmick..
4. As a NoScript user, I have it set to always block JS and use whitelists and (mostly) session exceptions. The handful of sites I’ve taken the time to element block carefully are whitelisted, so the JS issue would be moot.
5. False positives are creeping in again and will be a harder problem with elements. I’d bring up again the idea of having an optional visual placeholder (I’d use a 1×1px dot image) to replace the item blocked. Icon menuitem to toggle on/off.
Thanks and congrats on #1.
Reply from Wladimir Palant:
Placeholders should be possible for most blocked items but not for elements – CSS can only hide, not replace by something else.
alta88 · 2006-11-23 02:56 · #
don’t think ‘replace’, think ‘override’. using only css, one can turn any element into a 1px red dot ;D
pitdicker · 2006-11-23 08:12 · #
It would be great if a tighter integration of element hiding is possible. Including it in the hit counts, showing it in the sidebar, whitelisting… Wy ‘miss’ those features for just a few milliseconds? Although being fast sure is a good thing, it should not be the main target of an extension. Also adding this will Adblock Plus look more consistent. Maybe that’s wort an extra option. And about NoScript: Adblock Plus won’t be the first extension breaking up with NoScript. Personally I don’t even use Noscript as Adblock Plus already block everything I would use Noscript for.
So, please include it:)
eupator · 2006-11-23 19:03 · #
You can always put something like ‘Hidden elements are not displayed (learn why)’ at the bottom of the sidebar, and turn it off when javascript is on.
> If you have a problem with being notified when I
> answer to your comment – you can use Mailinator
> or any other black hole.
Don’t you think it is a bit silly to require an email for posting a comment and to recommend your readers to bypass this requirement?
Alec · 2006-11-24 21:33 · #
If you don’t want this feature usable by anyone who doesn’t know what he’s doing, make it only be enabled through about:config. That way, whoever finds it will know that he can expect problems with JS and performance. Whoever doesn’t know about it probably doesn’t need it :)
IceDogg · 2006-11-24 23:25 · #
What Alec said is what I was about to suggest. Make it a HIDDEN option (and off by default) so that only the people that are experienced can find and use it and therefor would understand about the javascript issue. It’s mostly going to be filterset makers that really care about these options anyway, correct? Even those like me that make a few of their own for private or unpopular sites. Another thought I had was could this part be made into another extension? so of an add on extension. I’m no developer so please forgive me if this is a stupid suggestion. Or if it would be more work then it’s worth. I have no idea about either.
Having said that I sure would like to have the functions of both the white listing and the hit counts.
That reminds me. If this is a hidden option will that mean the white listing would only work if that option is on? or could those two parts be separated? Just thought of that.
Reply from Wladimir Palant:
No, this feature would actually benefit the less experienced users most – they are the ones who suffer from element hiding not being visible anywhere and from it ignoring whitelisting. And it wouldn’t make any sense to disable hit counts while keeping whitelisting for element hiding.