Deprecate `@include` and `@exclude` metadata

[ACTCD]

We will deprecate @include and @exclude and only support @match and @exclude-match in the future.

• Match pattern structure is safer and stricter, not too many accidents happen.
• It reduces code logic, and may helps improve matching efficiency.
• In the Web Extension API, include_globs and exclude_globs
  • Only support globs instead of regular expressions.
  • And Apple never implement these keys in Safari.
  • The newer API scripting.RegisteredContentScript no longer supports these keys.
• Reduce confusion and difficult choices caused by different syntaxes.

We plan to add a deprecation hint in v5 and eventually remove it in v6.0.

[F9y4ng]

Hi @ACTCD , Google search engine has hundreds of national domain names, use @include *://*.Google.* can match all national domain names, But, how to achieve wildcard through @match?

[ACTCD]

Hi @F9y4ng, The @include *://*.Google.* will also match:

https://example.com/1.google.html
https://example.com/?site=www.google.com
https://1.google.example.com/
...

Obviously these are not your intentions, and may cause all kinds of damage.

That's why we want to make the change, to encourage developers to make more secure and accurate user scripts.

For your question, here is a userscript for Google, you can refer to its implementation: ACT.Google.DM.NCR.user.js

Hope this explains your question and satisfies you. Stay safe! :)

[F9y4ng]

Maybe I have to adopt your scheme after the browser forces to MV3. 😅

Thanks for your reply.

[jesus2099]

IMO, you should keep supporting include.
Match is very nice and better than include for simple things but it does not support regular expressions.

And many existing userscripts will not run on your extension.

[ACTCD]

@jesus2099 Thank you for your opinion.

I think I have made it clear in OP.

If it retains it means additional complexity, maintenance, delay, and safety risks, I think it is reasonable to deprecate it.

For regular expression, I recommend using it in user scripts, for example: 249#issuecomment-1150674097

I always think:

• The project should be refined and easier to maintain
• Safety first, not external compatibility
• Users deserve higher quality user scripts

So far I have not seen the reason for favorable reasons to change this, but I remain open.

[ACTCD]

And many existing userscripts will not run on your extension.

For this point, I would like to explain my view additionally.

We have a reasonable deprecation cycle and this is not a change with a significant burden for any user script developer/author.

It takes very little time and effort to migrate, and comes with significant security and/or other benefits.

For those long term, unmaintained user scripts, I'm curious if they really still work properly on their own?

A user script is not a standalone program, it almost always works with the structure of the site's pages at a particular stage, and typically modern sites change their structure so often that if they aren't maintained and adapted in a timely manner, they will usually fail to work correctly very shortly.

And is it really worth carrying the burden and cost of these obsolete user scripts that may not work properly anyway?