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?

[jesus2099]

I discovered this extension by random. I didn't know there was an iOS userscript extension! It's great for those iPhone users, at last!

But match sometimes takes more lines and is less strict than regex include.

It was my reasons to migrate this userscript from matches to regex include.

But as userscript author I don't always know that this or that userscript extensions supports everything in GM metadata and API standard, or not.

[ACTCD]

@jesus2099 More lines != bad.

If needed, please use @match on more lines than the more error-prone regex.

The WebExtension API never supported "regex", it needs to be supported separately with complex logic.
And there are the same issues when switching to UserScripts API in the future.

But as userscript author I don't always know that this or that userscript extensions supports everything in GM metadata and API standard, or not.

Then, please read their documents.

[ACTCD]

I need to emphasize again that this will not prevent you from using the Regex. The difference is that you only need to implement yourself in the user script, rather than we support it at the Extension level.

We want to make thin packaging of Web Extension API, and adopt and promote better security and less errors.

@jesus2099 If you want, you could even @match *://*/* and then use just ONE extra-long line of regex in your user script, no problem and works with almost any user script manager.

But what's the point?

Comparing lines doesn't make any sense, and not everyone is a regular expression expert.

We want better readability and less chance of error, which is why the Web Extension API created and recommends the use of Match patterns, and we hope to accurately convey that.

[jesus2099]

Yes yes, I see. 😁

I think you should display an error when one tries to install an include based userscript, once it's no longer supported.

So that people understand that they should request a new version from the author.

And same when an auto-update brings a version that introduces an include.

[ACTCD]

I think you should display an error when one tries to install an include based userscript, once it's no longer supported.

We will warn about all metadata that will be deprecated or unsupported in the next major release, this is a work in progress.