Opened 6 years ago

Last modified 19 months ago

#242 closed defect

Element hiding filters can be overridden by the element's style attribute — at Version 27

Reported by: mapx Assignee:
Priority: P3 Milestone: Adblock-Plus-3.0.3-for-Chrome-Opera-Firefox
Module: Platform Keywords: externaldependency, circumvention
Cc: saroyanm, sebastian, fanboy, arthur, scuturic, Lain_13, mjethani, hfiguiere, hayato, kochi, SMed79, BrentM, weissmar Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

https://codereview.adblockplus.org/29564767/

Description (last modified by sebastian)

How to reproduce

  • Search for something on Bing (also see #4425)
  • Visit any article on The Telegraph (also see #4171)
  • Search for something on torrentz.eu (no longer reproducible, website seems to be broken)
  • Visit any web page that uses style="dislay: block !important" (or alike) to avoid element hiding

Observed behaviour

If a web page sets the display CSS property of an element using an !important rule applied via the element's style attribute, it takes precedence over element hiding filters applied by Adblock Plus, potentially preventing ads from being hidden.

That is because element hiding in Adblock Plus for Chrome (as well as on Safari and Microsoft Edge, but unlike on Firefox) is implemented using an author stylesheet, i.e. a regular <style> element which is injected into the (shadow) DOM.

Expected behaviour

Element hiding filters should take precedence over any styles applied by the web page, including those applied using the style attribute. Adblock Plus for Firefox currently achieves that by utilizing user stlesheets. This mechanism, however, is currently not supported by Chrome, see Chrome bug 632009.

Change History (27)

comment:1 Changed 6 years ago by mapx

another example:
go to http://www.drakulastream.eu/tennis-live-streaming-video.html
choose a match (flash, not unibet where you must have an account), a window opens with the top bar:
"Update your OnlineHD for Chrome in order to watch this video online"

in firefox the bar is hidden, but not in chrome

comment:2 Changed 6 years ago by mapx

  • Description modified (diff)

comment:3 Changed 6 years ago by mapx

  • Description modified (diff)

comment:4 Changed 6 years ago by trev

This isn't something we can fix as long as we are using regular <style> tags for element hiding. We should check whether chrome.tabs.insertCSS does things better by now and inserts a real user stylesheet. But even if it does we'll still have to file a Chromium issue - InjectDetails should allow specifying a frame ID rather than "all frames" only.

Last edited 6 years ago by trev (previous) (diff)

comment:5 Changed 6 years ago by trev

  • Cc trev added

comment:6 Changed 6 years ago by philll

  • Keywords externaldependency added
  • Priority changed from P2 to P3
  • Ready set

comment:7 Changed 6 years ago by trev

Just checked, chrome.tabs.insertCSS will inject a proper user stylesheet. However, !important keyword is ignored for user stylesheets (https://code.google.com/p/chromium/issues/detail?id=120428). The issue has been incorrectly resolved, it seems that we need to file a new one.

I couldn't find an existing issue on frameId support in chrome.tabs.insertCSS, we need to file that one as well.

comment:8 Changed 6 years ago by mapx

the chromium devs are not very open to such approach:
https://code.google.com/p/chromium/issues/detail?id=347016

comment:9 Changed 6 years ago by trev

That issue is irrelevant here - it's explicitly about user stylesheet files that users put into their profiles manually, not about extensions which stay supported.

comment:10 Changed 6 years ago by mapx

  • Description modified (diff)

comment:11 Changed 5 years ago by Spam404

I was directed here by "mapx" on the Adblock Plus forum. Here is what I posted on the forum -

"I was recommended to this forum to report this issue as a bug on the following thread - http://forums.lanik.us/viewtopic.php?f=62&t=16614

It may be best to read the thread first to get an idea of what I was trying to get filtered and how the bug was initially discovered.

In a nutshell I am trying to filter the following element on this page - http://astucespourlesjeuxmobiles.blogspot.co.uk/

[img]http://i.gyazo.com/2bb37909542eab5f4c0f1b04e0327535.png[/img]

I am trying to do this by using a social filter list by EasyList.

The problem is that the element is being hidden on Firefox but not Google Chrome."

comment:12 Changed 5 years ago by arthur

@Spam404
According to the screenshot in the EasyList forum you are using AdBlock which is a different extension.

However, I can reproduce your issue in Adblock Plus 1.7.4 as well. It seems to be fixed in the development build: https://adblockplus.org/en/development-builds

@mapx
This doesn't seem to be the same issue as the one reported by you. I don't see any "display: block !important;" in the source and it is still happening in the dev build.

comment:13 Changed 5 years ago by mapx

@arthur
here: http://forums.lanik.us/viewtopic.php?p=56583&sid=74642d8293634c3571fe813f20974add#p56583
I can see a lot of (9) !important keywords and as trev said: "!important keyword is ignored for user stylesheets"

Another thing:
first you said: "It seems to be fixed in the development build"
then: "it is still happening in the dev build"

It's true, the dev build seems to work well with the filter:

astucespourlesjeuxmobiles.blogspot.co.uk##.share-controls.delay

comment:14 Changed 5 years ago by arthur

@mapx
You're right. There are some "display: block !important;" in the source. I only checked this element:

<div class="share-controls delay" data-defer="true" data-delay="1000">

When I said "it is still happening in the dev build", I was referring to the original issue reported by you on 1 April.

comment:15 Changed 5 years ago by saroyanm

  • Cc manvel@… added
  • Platform set to Unknown

comment:16 Changed 5 years ago by philll

  • Platform changed from Unknown to Firefox

comment:17 Changed 5 years ago by philll

  • Platform changed from Firefox to Chrome
  • Summary changed from chrome: hiding filters do not work to chrome: hiding filters do not work at http://torrentz.eu/search?f=cow

comment:18 Changed 5 years ago by sebastian

Also see #1253

comment:19 Changed 5 years ago by sebastian

  • Cc saroyanm sebastian added; manvel@… removed

I filed a Chrome issue: https://crbug.com/426337

But even if they don't add a frame option that allows us to inject user stylesheets into a specific frame, we could still use the current version of chrome.tabs.injectCSS() to inject CSS into the top level frame, while keep using content scripts to inject <style> elements into subframes.

Last edited 5 years ago by sebastian (previous) (diff)

comment:20 Changed 5 years ago by sebastian

I filed another Chrome bug, to let user stylesheets override author stylesheets with !important directive: https://crbug.com/427527

comment:21 Changed 5 years ago by sebastian

  • Resolution set to invalid
  • Status changed from new to closed

Apparently Blink doesn't support user stylesheets. Stylesheets injected with chrome.tabs.injectCSS() are merely author stylesheets, and therefore aren't supposed to override other author stylesheets with !important priority. So the solution suggested above isn't an option.

Last edited 5 years ago by sebastian (previous) (diff)

comment:22 Changed 3 years ago by fhd

  • Tester set to Unknown

Dave filed https://bugs.chromium.org/p/chromium/issues/detail?id=632009# earlier this year, that should fix this, how I see it. But so far the Chromium people have ignored it. If lots of people star it, that might help a little.

comment:24 Changed 3 years ago by mapx

  • Cc fanboy added

comment:25 Changed 3 years ago by arthur

  • Cc arthur added

comment:26 Changed 3 years ago by scuturic

  • Cc scuturic added

comment:27 Changed 3 years ago by sebastian

  • Description modified (diff)
  • Ready unset
  • Resolution incomplete deleted
  • Sensitive set
  • Status changed from closed to reopened
  • Summary changed from chrome: hiding filters do not work at http://torrentz.eu/search?f=cow to Element hiding filters can be overridden by the element's style attribute

Since this circumvention method is becoming popular again, I reopened this issue and updated the description. Also I made the issue confidential, surprisingly this wasn't done back then, despite this providing an exploitable circumvention technique.

Currently, our plan is to see what's going to happen with Chrome bug 632009, in which we requested chrome.tabs.insertCSS() to use user stylesheets, so that we can migrate to that API, instead of injecting an author stylesheet, which will be even less effective once shadow DOM v0 gets removed from Chrome. Then again, due to the upcoming deprecation of shadow DOM v0, the Chromium team seem to consider prioritizing that issue now (also see #4713).

Alternatively, we could (theoretically) emulate element hiding filters, partially reimplementing CSS ourselves, so that we can operate on the nodes to be hidden rather than using a stylesheet. That is essentially what uBlock is doing. But this approach is a bit controversial, as the implementation tends to be quite complex and might potentially have a negative performance effect in particular on large pages and pages that change a lot dynamically. On the other hand it could also help reducing the memory usage, like it does in uBlock. But then again, we'd still mess with the DOM, in a merely slightly harder to circumvent way. Not to mention, that as more as we mess with the actual page content (e.g. through the DOM) as higher the legal risk we are facing. So this might only be a last resort, if at all.

Note: See TracTickets for help on using tickets.