@match with *. prefixing hostname should match hosts without subdomains

[vassudanagunta]

For example, the following script works for Google search results but not for DuckDuckGo's because Google results are returned on www.google.com while DDG's are on duckduckgo.com.

/* ==UserStyle==
@name        red visited search results
@description turn visited search results red
@match       *://*.duckduckgo.com/*
@match       *://*.google.com/*
==/UserStyle== */
:visited {
    color: red !important;
}

The workaround is to change the match pattern to @match *://duckduckgo.com/*, but:

1. This contravenes the rules for match patterns (as required by Userscripts):

   If the host is *.hostname, then it matches the specified host or any of its subdomains.

2. Makes the script dependent on Duckduckgo not adding a subdomain in the future.

System Information:

macOS version: 11.2.1
Userscripts version: 3.0.2
Safari version: 14.0.3

[vassudanagunta]

I'd like to say, thank you for this wonderful Safari extension!

[quoid]

@vassudanagunta

If I wanted to match a domain and any of that domain's subdomains, this is the pattern I would use:

@match       *://*duckduckgo.com/*
@match       *://*google.com/*

Note the lack of a . before the domain name.

[vassudanagunta]

Cool, I've confirmed it works. But since in the instructions you link to these rules, it's important that your recommendation and Userscripts behavior do not following this part:

Bad pattern	Why it's bad
http://*foo/bar	'*' in the host can be followed only by a '.' or '/'

I think those linked rules make sense, as a rule for "oogle.com" should not match "google.com".

[quoid]

Thanks for pointing that out @vassudanagunta

In the next update I should note that the chrome article is a good general reference but there are some ways where the matching protocols diverge. Better yet, I should include example of some basic match patterns.

Alternatively, I could try to adapt the pattern matching to align better with the article, but I will start with noting the differences in the readme.

[vassudanagunta]

whatever works for you!

The only thing I'd say is there should be a way to say "match any request to oogle.com, ignoring subdomain, but not match google.com or doogle.com".

The way the linked rules do it is confusing, but I don't know a better way without resorting to regexp, e.g. /(.+\.)?oogle.com/

[quoid]

The only thing I'd say is there should be a way to say "match any request to oogle.com, ignoring subdomain, but not match google.com or doogle.com".

Off the top of my head, I would probably do something like:

@match *://*oogle.com/*
@exclude-match *://*google.com/*
@exclude-match *://*doogle.com/*

But I would probably just be specific with the subdomains:

@match *://oogle.com/*
@match *://*.oogle.com/*

[vassudanagunta]

@match *://oogle.com/*
@match *://*.oogle.com/*

That works, but not ideal, having to have two lines per domain. You can see why the chrome extension rules are designed as they are, taking the following semantics-based approach instead of a more literal Regex one:

If the host is *.hostname, then it matches the specified host or any of its subdomains.

The downsides to this rule are:

1. A small amount of confusion because it is not obvious *.example.com will match example.com. People tend to thing in terms of Regex or Glob patterns.
2. There is no way to match all subdomains (e.g. a.example.com, b.example.com) and NOT match the bare domain (example.com).

#1 is very minor and I doubt #2 would be an issue for anyone.

Note that the Glob standard itself has a "semantics" option: **. Check out this Stack Exchange answer I just wrote. The key is that **/file.txt will match directory/file.txt, but will also match just file.txt, even though there is no / in the latter's path. The analogous approach for domain names would be **.oogle.com to match www.oogle.com as well as plain oogle.com even though there is no . preceeding oogle.

On the other hand, if those Chrome extension rules are the convention everyone in Firefox and Chrome land are used to, you should stick to those.

On the other other hand, you might want to take the approach of filter list syntax as used by uBlock and AdBlock (no need for asterisks at all).

[quoid]

On the other hand, if those Chrome extension rules are the convention everyone in Firefox and Chrome land are used to, you should stick to those.

I think this would be the most ideal option, but I am not sure how I would go about implementing it at the current moment.

I am using the, simple, NSPredicate class for matching, thus the differences when compared to Chrome. Of note is how wildcards work and the availability of the ? character (which is noted nowhere in the documentation, but works as expected).

From what I've gathered, most of the time, patterns used in another Userscript manager will work in this manager, but I would be lying if I said it didn't bother me that pattern matching wasn't identical. I think getting matching to work as it does in other userscript managers should be the ultimate goal.

I really appreciate this discussion and the interest in the extension. It's refreshing to have someone else to bounce ideas off of and gain insight from.

[vassudanagunta]

My pleasure. I'm using your extension and giving back because I can. This is how open source should be! :) (Not like those entitled users who give nothing and just complain and criticize with zero appreciation of the work involved or that the maintainer is doing it for free!)

[quoid]

closing this issue, progress can be tracked at #108

thanks again @vassudanagunta