Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML filter exception doesn't work. #6

Closed
ghost opened this Issue Apr 19, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@ghost
Copy link

commented Apr 19, 2018

Prerequisites

  • I verified that this is not a filter issue
  • 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

This comment has been minimized.

Copy link
Member

commented Apr 19, 2018

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

This comment has been minimized.

Copy link
Author

commented Apr 20, 2018

@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

This comment has been minimized.

Copy link
Member

commented Apr 20, 2018

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

@gorhill gorhill reopened this Apr 20, 2018

@gorhill

This comment has been minimized.

Copy link
Member

commented Apr 20, 2018

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.

@uBlock-user uBlock-user added TODO and removed information needed labels Apr 20, 2018

@uBlock-user uBlock-user added bug fixed Firefox and removed TODO labels Oct 17, 2018

@gorhill gorhill changed the title HTML filter exception for google doesn't work. HTML filter exception doesn't work. Oct 18, 2018

@in4u

This comment has been minimized.

Copy link

commented Nov 16, 2018

@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

This comment has been minimized.

Copy link
Member

commented Nov 16, 2018

Fixed in beta

image

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

Yes

@in4u

This comment has been minimized.

Copy link

commented Nov 16, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 16, 2018

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

This comment has been minimized.

Copy link

commented Nov 16, 2018

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

@gorhill

This comment has been minimized.

Copy link
Member

commented Nov 16, 2018

@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

This comment has been minimized.

Copy link

commented Nov 16, 2018

@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

This comment has been minimized.

Copy link
Member

commented Nov 16, 2018

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

This comment has been minimized.

Copy link

commented Nov 16, 2018

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.

gorhill added a commit to gorhill/uBlock that referenced this issue Nov 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.