@match with query parameters not working

[HimbeersaftLP]

It appears the extension only compares the contents of the @match property with the site's URL without the query parameters.
I'm not sure if this is a bug, as the Chrome extension spec doesn't have those, but Violentmonkey works with query parameters.
This is useful for websites where they don't use a path but rather something like "index.php?page=something".

[quoid]

#273 (comment)

This is useful for websites where they don't use a path but rather something like "index.php?page=something".

Agreed, it would be helpful

[ACTCD]

Sorry I keep chasing issues like this. I've actually experienced this issue myself, so I hope people understand it more. As a complement to the original comment, I'll add some more detailed instructions.

It seems to me that it makes sense that Match patterns does not process and match the part after path. We should not expect exact matching of query parameters using this feature.

We should keep in mind that query parameters is out of order and repeatable. For example, if you want to match page=something, how should we face the following possible actual situations:

index.php?page=something
index.php?ref=a&page=something
index.php?page=something&page=thing

Unless we make the @match metadata complex and personalized, we can't handle the actual needs well. But that means that's another metadata.

In the current framework and consensus. We already have some alternative and reliable solutions.

• Use @include instead of @match, which supports a more flexible syntax, but you should note that it is not recommended due to possible lack of safety.
• Use the built-in syntax of javascript new URL(window.location) to parse the current tab URL, and then use URL.searchParams to check and match the query parameters you need. Here is an example user script 249#issuecomment-1150674097

[HimbeersaftLP]

You're right of course, but in practise, there is lots of sites out there where the order of query parameters is constant, and for quickly hacked together scripts it's very easy to do it over the match property.
I can see where you are coming from, though. And if this behaviour is completely intentional I would suggest the extension should throw an error if you give it a script with a match property that has query parameters.

[ACTCD]

I'm just explaining how browsers work with Match patterns and my understanding, I didn't define that metadata. We should respect and preserve its original way of working, otherwise that's what creates confusion. That's why we don't want to add additional customization improvements to this metadata.

Proper improvement error feedback is always nice. I know some users are always complaining that some scripts don't show up or don't work. But considering the complexity of this scenario, I don't have a complete idea right now. It is easy to parse and prompt when the editor is saved, but considering the various installation methods of user scripts, prompting in a suitable form at the right time is a problem that needs to be fully considered.

I really wish developers could more reference documentation and compliance, users deserve better scripts.

[ACTCD]

Re-read the MDN documentation on the definition of path in Match patterns:

The value for the path matches against the string which is the URL path plus the URL query string. This includes the ? between the two, if the query string is present in the URL. For example, if you want to match URLs on any domain where the URL path ends with foo.bar, then you need to use an array of Match Patterns like ['*://*/*foo.bar', '*://*/*foo.bar?*']. The ?* is needed, rather than just bar*, in order to anchor the ending * as applying to the URL query string and not some portion of the URL path.

Now this is an issue that should be fixed.