Host subdomain wildcard should match the bare domain

[marekweb]

Your libraries have been very helpful while working on our web extensions at Sourcegraph, thank you!

I encountered an unexpected result while matching a pattern like *://*.gitlab.com/* against the URL https://gitlab.com. This came to my attention while developing a web extension for Safari, because Safari generates permissions that follow that pattern (including the subdomain wildcard) when requesting permission to a website, even if your requested URL doesn't have a subdomain.

According to the match pattern docs:

https://*.google.com/foo*bar: "Matches any URL that uses the https scheme, is on a google.com host (such as www.google.com, docs.google.com, or google.com" (emphasis added)

It looks like https://google.com/foobar (on the bare domain) should match *.google.com - I think the docs should have included it in the right-hand column as an example/test case.

Steps to reproduce

Evaluate patternToRegex("https://*.google.com/foo*bar").test("https://google.com/foobar")

Expected result

It should match, and evaluate to true.

Actual result

It doesn't match because the regex expects a subdomain to be present (or at least a leading . on the host), and it evaluates to false.

[fregante]

Thanks for the report! I’m glad to see you porting the extension.

I have a similar issue in a related module fregante/webext-permissions#1, are you using webext-patterns directly or is it a subdependency of something else?

[marekweb]

Initially I hoped to use webext-dynamic-content-scripts but it didn't work on Safari. Since I found webext-patterns I tried using this module directly. I think this present issue is the root cause of why webext-dynamic-content-scripts didn't work for me (correct me if I wrong, I forget how I arrived at finding webext-patterns)

For now I'm using webext-patterns with a workaround for this particular edge case, which you can see here in this PR.. This workaround isn't really a proper fix, it just fixes the edge case for Safari.

[fregante]

Are you already shipping the Safari version? The way I’m going to handle it in my extensions is by doing away with all of this and just specifying <all_urls> in the content_scripts. This way Safari is ready to inject it into every page, as soon as the user enables it on their domain, via Safari’s own UI.

The downside may be that Safari might display a “this extension wants to run on this website” icon on the browser action button. My extensions don’t need that button so it won’t be visible.

[fregante]

This should now be fixed in both modules. Let me know if it works for you.