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

Ability to select hostname in element picker when creating cosmetic filters #2035

Open
jjohns71 opened this issue Sep 28, 2016 · 11 comments
Open

Comments

@jjohns71
Copy link

jjohns71 commented Sep 28, 2016

Read first: https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.md

Describe the issue

When creating a filter with the element picker, I have noticed that sometimes it automatically adds 'www.' to the filter, and some times it doesn't. If ublock adds the 'www.' to your filter then your filter only applies on the 'www.site.com' domain and not the higher level 'site.com' domain without the 'www.'.

I was wondering if it is possible to just always drop the 'www.' from the filter creation, I don't see any value in adding it as your filter now won't work on 'https://site.com' but will only work when your browser is on 'https://www.site.com'. However if the filter never has the 'www.' and is only for 'site.com' it will work in both instances depicted above. This would be similar to how ublock doesn't include the 'http://' and 'https://' prefixes when creating a filter.

Steps for anyone to reproduce the issue

  1. Go to 'https://www.google.com' and create a filter with the element picker.
  2. Now go to 'https://encrypted.google.com' and observe that your filter created in step 1 doesn't work because your filter only applies to the domain 'www.google.com' and not the 'google.com' domains such as 'encrypted.google.com' or just 'google.com' without the 'www.'
  3. Google is just an example, it happens on more than just google.com, when uBlock Origin creates a filter with 'www.' in the address bar it restricts it to only that lower level 'www.' domain so I end up having to strip the 'www.' from each custom filter so it targets the higher level domain. Would be nice if the 'www.' was treated the same way that ublock treats the 'http://' and 'https://' prefix by not including them in the filter creation.

[Removed irrelevant information --gorhill]

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2016

I have noticed that sometimes it automatically adds 'www.' to the filter

uBO does not add www., it uses whatever hostname is used in the URL in the address bar.

@jjohns71
Copy link
Author

jjohns71 commented Sep 28, 2016

I guess my question, is it possible to change the filter creation methodology when using element picker so it always strips the www. from the hostname, similar to how it strips the http:// or https:// from the hostname so the filter doesn't only target the www.site.com domain and instead would work on both www.site.com AND site.com?

Edit: For example, a filter that uses site.com applies to both http://site.com AND https://site.com so why not keep the same level of functionality by removing www. as well as the http:// or https:// prefix.

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2016

Automatically stripping www. is not always a good idea, especially with large domain such google.com. One cosmetic filter good for mail.google.com is probably pointless for maps.google.com. However, I will experiment with methods for allowing the user to edit the hostname part in the UI of the element picker.

@jjohns71
Copy link
Author

jjohns71 commented Sep 28, 2016

Thanks @gorhill for looking into it! I do agree about not wanting to strip all prefixes from a domain such as your mail.google.com vs maps.google.com. Another simple example why you wouldn't want to strip all prefixes would be something like setting a filter on bbc.co.uk, if you stripped all prefixes, it would end up applying to co.uk which would obviously be undesirable behavior.

That being said I can't think of any scenario where stripping www. would be a detriment (i.e. is there any site that shows a different version of their site when you use www.site.com vs site.com? - There could be I suppose, but with all my custom filter creation I've never found one, and instead only found that I end up needing to strip the www. so the filter is more robust on a particular domain.

If you figure out a solution, the same "issue" also applies to the dynamic 'My rules' tab when setting a block via the logger. I'm not sure if fixing the element picker ends up being the same "fix" for dynamic rules though, so it could be more difficult/not worth implementing depending on code issues.

@gwarser
Copy link
Contributor

gwarser commented Sep 28, 2016

What happens if you strip www from www.google.com and then go to mail.google.com?

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2016

Yes, that's actually the point I was actually trying to (clumsily) make -- what is good for www.google.com is not necessarily good for all of Google's subdomains, which would happen when stripping www..

@jjohns71
Copy link
Author

jjohns71 commented Sep 28, 2016

@gwarser, from what I have seen, if there is a common element you are blocking that shows up on google.com then it would also strip it from mail.google.com, if your targeted filter is set to only mail.google.com it would not strip that div element on just google.com or www.google.com

If for some reason there was an advertisement or element you wanted to block that was persistent on both www.google.com and mail.google.com you would need two different filters if you didn't strip the www. from your filter for 'www.google.com' before setting it was my point.

I could see how it could be interpreted that it could potentially hamper sub domain performance if a element picker rule always ignored www. but could it be argued that exception rules should be used for specific sub domains where a breakage occurs vs. having to create the same filter for every sub domain you wanted to block the element on, unless you target the highest level domain only? e.g. google.com##.ab filter will block google.com#.ab & mail.google.com##.ab element but not maps.google.com#.ab element when an exception filter @@||maps.google.com#.ab is created.

@Atavic
Copy link

Atavic commented Oct 10, 2016

Another simple example why you wouldn't want to strip all prefixes would be something like setting a filter on bbc.co.uk, if you stripped all prefixes, it would end up applying to co.uk which would obviously be undesirable behavior.

bbc.co.uk is the domain name, while co.uk is a TLD. bbc isn't a mere prefix here.

@Kinryu
Copy link

Kinryu commented Nov 22, 2016

This could be useful for some websites. Content is sometimes hosted on sub domains like b12.website.com where the prefix changes depending on what your viewing. I think Photobucket did this at one point.

@ddraws
Copy link

ddraws commented Nov 24, 2016

It's not worth it imo.
because there's a good chance of site breakage and cosmetic filters contribute very little, if not none, to security and load time.

@ghost
Copy link

ghost commented Dec 14, 2016

hi, I am using as advanced user, suddenly I started seeing sub-domains for all the blocked domains. Do I need to block all the sub-domains when I block a domain globally? Is that changed recently? I never had this issue till yesterday.

Uploading 2.png…
Uploading 1.png…
my attachments not showing up here...

@gorhill gorhill changed the title 'www.site.com' vs 'site.com' element picker filter creation Ability to select hostname in element picker when creating cosmetic filters Feb 25, 2018
gorhill added a commit that referenced this issue Oct 14, 2020
This allows to bring in all the benefits of
syntax highlighting and enhanced editing
features in the element picker, like auto-
completion, etc.

This is also a necessary step to possibly solve
the following issue:

- #2035

Additionally, incrementally improved the behavior
of uBO's custom CodeMirror static filtering syntax
mode when double-clicking somewhere in a static
extended filter:

- on a class/id string will cause the whole
  class/id string to be   selected, including the
  prepending `.`/`#`.

- somewhere in a hostname/entity will cause all
  the labels from the cursor position to the
  right-most label to be selected (subject to
  change/fine-tune as per feedback of filter
  list maintainers).

Related feedback:
- uBlockOrigin/uBlock-issues#1134 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants