HTML filter exception doesn't work.

[ghost]

Prerequisites

• I verified that this is not a filter issue
  • Filter issues MUST be reported at filter issue tracker, NOT here.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
• I tried to reproduce the issue when...
  • uBlock Origin is the only extension
  • uBlock Origin with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uBlock Origin
• I checked the documentation to understand that the issue I report is not a normal behavior

Description

google.*,~www.google.com##^* exception doesn't work for any subdomain too.

A specific URL where the issue occurs

www.google.com

Steps to Reproduce

1. Add a filter google.*,~www.google.com##^*

Expected behavior:

Working exceptions.

Actual behavior:

Not working exceptions.

Your environment

• uBlock Origin version: 1.16
• Browser Name and version: Firefox 59.0,2
• Operating System and version: Windows 10 1709

[gorhill]

HTML exception filters are still a TODO: https://github.com/gorhill/uBlock/blob/ec29c9a127342f6d250c41572017329c45aca0e5/src/js/html-filtering.js#L236.

For me to be motivated to address this I will need actual cases that benefit all users. Your filter is an unrealistic use case.

[ghost]

@gorhill OK then. It's just that exceptions are working with mozilla.org, not quite right though, i need to refresh one time to access it.

[uBlock-user]

Closing this until actual use case(s) are brought up as per gorhill's request.

[gorhill]

It can be kept opened, as it is definitely a TODO, I even wrote it in the code. It's just not a priority to fix for now.

[in4u]

@gorhill I was going to post new issue but a quick search turned this up showing it as fixed. Is the syntax for HTML filter exceptions same as that for cosmetic ones, like #@#? I tried but it's not working for me.

[gwarser]

Fixed in beta

Is the syntax for HTML filter exceptions same as that for cosmetic ones, like #@#?

Yes

[in4u]

Ah, alright. Thanks @gwarser for pointing that out! I have one more question. Going by the wiki, HTML filters sound conceptually awesome. But what's the catch? How do they compare against regular cosmetic filters in terms of speed, performance and efficiency? Is there any reason to prefer non-HTML filters over HTML ones if the browser supports them?

[uBlock-user]

How do they compare against regular cosmetic filters in terms of speed, performance and efficiency?

It relies on Response data API which is only available in Firefox 57+ atm.

Is there any reason to prefer non-HTML filters over HTML ones if the browser supports them?

Eliminates any possible race condition occuring on any website.

[in4u]

Yes @uBlock-user, that's why my question was only for the case when browser supports both.

[gorhill]

@in4u HTML filtering acts strictly on the response data -- stuff is removed before the browser parses the response data. This means that anything that is added dynamically to the DOM after the browser parses the response data can't be directly filtered by HTML filtering. Cosmetic filters acts directly on the DOM, present and future, and cosmetic filtering merely applies style properties to the DOM, it never removes stuff from the DOM. So what HTML filtering and cosmetic filtering do is very different.

[in4u]

@gorhill Does the removal cause any performance hit or delay or some other problem except breaking things? If I have a list of cosmetic rules which don't break anything (and have the exact same blocking result) by converting them into HTML filters, which should I prefer - HTML or non-HTML filters?

[gorhill]

Frankly, only profiling would provide an evidence-based answer to this (or at least to the one scenario your are profiling). My intuition for the specific case you bring is that cosmetic filtering would be better -- but as said, it's my intuition, profiling could prove me wrong.

[in4u]

Hmmm... okay thanks @gorhill, for the time being I'll stick to non-HTML filters as per your recommendation for my use case. But please do update the wiki as and when new information / profiling result is available.

[uBlock-user]

In Nightly, entire page load hangs up for few minutes due to www.google.com##^*

[gorhill]

It's just the browser which seems to be waiting for more data after it receives a response with just <DOCTYPE html>, as would be expected when removing all elements. google.*,~www.google.com##^body preserves the head tag and this way the browser is not fooled into waiting forever.

Regarding the issue filed here, as per comment in code, I never implemented negated domain names (what was fixed above was exception filters #@#^):

https://github.com/gorhill/uBlock/blob/cdc566cc32268d7669f6b3fb4f8be95912f777e2/src/js/html-filtering.js#L337-L339