Loading…
iobit forum doesn't like uBlock #430
2 participants
I don't see anything wrong from here. What is your selection of filter lists?
Oh, might it be a host rule that doesn't appear on the statistics page?
I have all multipurpose hosts files selected and the site still display fine.
A custom filter interferes?
Clearing my custom filter rules doesn't help on my profile.
And... right... out of the box settings/filters don't seem to break the site...
Invastigating further...
Ahh.. well.. I found the culprint list!
Its the:
Block-EU-Cookie-Shit-List
But it's odd that there are no rule/s that are blocking the site from working properly from this list on the statistics page..
Leaving enabled on this list, uBlock doesn't account anything blocked on the site, but the site is broken until whitelisting the domain.
I also don't see anything changing in the console between the 2 runs (with and without the offending list)...
Any clues?
Any clues?
DOM elements hidden by cosmetic filters are not counted in the badge -- they are not really blocked, merely hidden. Net filters and cosmetic filters are completely unrelated beasts.
See this discussion.
I have an idea in mind but not a counter, rather another small tool icon in the popup which would be present if and only if at least one DOM element has been affected by one injected CSS rule. Clicking the icon would cause all the elements hidden by uBlock to toggle between visible/collapsed. So in your case, toggling the icon would have made you realize the page was broken due to cosmetic filtering.
uBlock can inject CSS rules before the document fully downloads, and as a consequence these rules could be applied by the browser to an unknown number of future DOM elements, without uBlock being notified about this. There need to be a pull model instead, where uBlock find out on demand only, not à priori. This way overhead is avoided unless you open the popup, and kept to a minimum for when you open it (only one collapsed element need to be found).
Right, so I see that there is some funky thing going on with the HTML tag.
They gave it A LOT of sub classes and I think they count on that one of the filters will render the site unusable (by declaring display:none on it or removing it from the page) so that the user will disable the ad block program one is using.. sneaky indeed...
Declaring
display: initial !important
on the HTML tag fixes the breakage of course...
I think they count on that one of the filters will render the site unusable
Nah, looks like it's just a coincidence. The CSS rule which gives problem is .cookies. So a counter rule for that site would be forums.iobit.com#@#.cookies [corrected]
Can you elaborate what the @ sign represents in the rule?
why
@@forums.iobit.com##html
didn't work for me?
Or perhaps:
@@forum.iobit.com##html[class*=cookie]
## and #@# indicates cosmetic block filter and cosmetic exception filter respectively.
What you tried parsed as cosmetic block filter which applies when on a web page which hostname is @@forums.iobit.com.
So @@ only works on net filters, and for cosmetic filter exceptions I have to use the #@# signature?
Yes.
I see, thanks!
Case closed :)
http://forums.iobit.com/
The iobit forum is as bright as the sun because of uBlock.
Disabling uBlock for this site (clicking on the big power button), makes the site work.
Disabling the experimental features and/or disabling the "Hide placeholders of blocked elements" has no effect whatsoever.
I don't see any rule that can affect the proper loading of this site on the statistics list.
P.S: µBlock v0.8.2.1-rc.1