[Bug] `@match` wrong behaivour after v1.5.0 update

[esterTion]

Expected:
@match https://example.com/ and @match https://example.com/* should match on https://example.com/

Result:
https://example.com/ is not matched with the script

Tested on both v1.5.0 from app store and v4.6.0-beta.6

Example:

// ==UserScript==
// @name        Test Match
// @namespace   userscript
// @license     MIT
// @match       https://www.google.com.hk/*
// @match       https://www.google.com.hk/
// @version     1.0
// @author      esterTion
// @description 
// ==/UserScript==

Script above is not matched on https://www.google.com.hk/, match on https://www.google.com.hk/webhp is working as expected

[ACTCD]

Unable to reproduce, it is recommended to check the current page URL.

[esterTion]

Fresh install seems to be fine... What old settings can cause this?
I just loaded the same page with extension fully reinstalled and things work now

[esterTion]

OK try this

// ==UserScript==
// @name        Test Match
// @namespace   userscript
// @license     MIT
// @match       https://whattrainisitnow.com/calendar/*
// @version     1.0
// @author      esterTion
// @description 
// ==/UserScript==

This does not match on https://whattrainisitnow.com/calendar/ , but match on https://whattrainisitnow.com/calendar/test

[ACTCD]

Unfortunately, it still cannot be reproduced. In my case, two URLs are matched.

[esterTion]

Does iOS version matters? I'm on iOS 15.4.1. I saw some version specific code in previous update.

[ACTCD]

Please check if your URL contains a query string and guess what your issue may from:

• Breaking changes URL matching in 1.4.1 #487 (comment)
• fix: metadata @match now for url path plus query string #463

As far as I can remember, we haven't made any changes to the match implementation since then, and we have unit tests for this so we'll find out if something goes wrong.

[esterTion]

Please check if your URL contains a query string

It doesn't, I clicked on the link in this thread directly and it does not match

I can only guess if there is some difference from this, it might cause a difference for system under ios 16 to behave differently. I don't have a debug setup right now to test it.

My current user scripts have a lot of exact matches (@match with no wildcard) that just stops working, which is just so weird. First google homepage example started working after a fresh install though my old exact match script still won't.
Installing an old version (I have 1.2.2 on my pc) instantly makes the same script work with just a page refresh.

[ACTCD]

Although the unit tests are only for Mac builds, the functions code is shared between Mac and iOS, so this should not be the issue.

I've just tested it on a real iOS device, and I could not reproduce the issue you described, whether on the v1.5.0 or the latest beta.

[ACTCD]

My current user scripts have a lot of exact matches (@match with no wildcard) that just stops working

My best guess, maybe you have some other script or extension that is redirecting the URL and causing the query string to be added there?

Also check the global exclude list? I couldn't think of any other possibilities at the moment.

[ACTCD]

Also, try checking if there are any error logs:

• FAQ and How to Review Error Logs 常见问题和如何查看错误日志 #409

By turning on the Enable Native Logger setting of this App in the iOS Settings App you should also be able to check the device's matching logs in macOS Console.app.

[esterTion]

I just copied the code and tested the code path for #available(macOS 13.0, iOS 16.0, *) === false,

var testUrl = "https://mozilla.org/path/"
var matched = match(testUrl, testUrl)

This will return false

---

When url ends with /, e.g. https://mozilla.org/path/, this code will remove the last /, and makes pathname become /path, therefore matching is failed

[esterTion]

url not ending with / is working as expected