Update href_matches examples

Now that URL patterns are better, as of whatwg/urlpattern@ed205a4, we no longer need the ?* or ?*#* syntax.

chrome-2023q1-experiment-overview.md

@@ -59,9 +59,9 @@ For example, you could permit specific same-origin URLs:
 {"prefetch": [
    {"source": "document",
     "where": {"or": [
-       {"href_matches": "/articles/*\\?*",
+       {"href_matches": "/articles/*",
         "relative_to": "document"},
-       {"href_matches": "/products/*\\?*",
+       {"href_matches": "/products/*",
         "relative_to": "document"}
     ]}}
 ]}
@@ -73,9 +73,9 @@ Or you could expressly block specific problematic URLs:
 {"prefetch": [
    {"source": "document",
     "where": {"and": [
-       {"href_matches": "/*\\?*",
+       {"href_matches": "/*",
         "relative_to": "document"},
-       {"not": {"href_matches": "*://*/logout?*"}}
+       {"not": {"href_matches": "*://*/logout"}}
     ]}}
 ]}
 ```
@@ -140,10 +140,10 @@ Fields of the performance timing entry which occurred before navigation start ar
 
 There are a few potential pitfalls to be aware of:
 
-* URL patterns which don't specify the query string only match links with no query string. Adding `?*` (with the required escaping for URL pattern and JSON syntax) or using `search: '*'` for the long form syntax will allow you to match links with any query parameters. URL patterns are constructed with a base URL (and this affects default behavior in some cases).
+* Before Chrome 121, URL patterns which don't specify the query string or fragment only match links with no query string or fragment. Adding `?*#*` (with the required escaping for URL pattern and JSON syntax) or using `search: '*', hash: '*'` for the long form syntax will allow you to match links with any query parameters or fragments. This is due to how URL patterns interact with base URLs, which [changed recently](https://github.com/whatwg/urlpattern/commit/ed205a47785a5483106b5bb59bd3f4834785f923).
 * If you use a restrictive [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP), you may need to adjust your CSP. For inline speculation rules, you'll need to permit inline scripts generally, use nonces or hashes, or use the experimental `'inline-speculation-rules'` source. For HTTP-fetched rules, the origin your rules is fetched from will need to be included in the allow list.
 * If you specify a non-default [referrer policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy), it will be respected. If it is not [sufficiently strict](https://wicg.github.io/nav-speculation/prefetch.html#list-of-sufficiently-strict-speculative-navigation-referrer-policies), then the prefetch will not occur. You can override the referrer policy which applies to your prefetches using `"referrer_policy"` in your speculation rules, or using the `referrerpolicy` attribute on individual links.
 * If you use HTTP-fetched speculation rules, and especially if fetched cross-origin, note that URLs and URL patterns in your speculation rules are resolved relative to the URL of your speculation rules (after redirects). If you want to specify URLs relative to the document instead, you can specify `"relative_to": "document"` to adjust this behavior. This may be particularly useful if you wish to select some or all same-origin links.
 * If you use HTTP-fetched speculation rules with a cross-origin URL, make sure the server sends a suitable `Access-Control-Allow-Origin` header to permit this.
 * If you select cross-origin links, note that for privacy reasons they cannot be prefetched with existing cookies and credentials. For this reason, such links will not be prefetched if credentials are found.
-* Chrome does not yet follow redirects during prefetching.
+* Chrome does not yet follow redirects during prefetching.

triggers.md

@@ -240,8 +240,8 @@ An example of using these would be the following, which marks up as safe-to-prer
   "prerender": [
     {"source": "document",
      "where": {"and": [
-       {"href_matches": "/*\\?*"},
-       {"not": {"href_matches": "/logout\\?*"}},
+       {"href_matches": "/*"},
+       {"not": {"href_matches": "/logout"}},
        {"not": {"selector_matches": ".no-prerender"}}
      ]}}
   ]
@@ -274,8 +274,8 @@ For document rules, `"relative_to"` can be paired directly with `"href_matches"`
 {
   "source": "document",
   "where": {"or": [
-    {"href_matches": "/home\\?*", "relative_to": "document"},
-    {"href_matches": "/about\\?*"}
+    {"href_matches": "/home", "relative_to": "document"},
+    {"href_matches": "/about"}
   ]}
 }
 ```
@@ -309,8 +309,8 @@ The user agent takes this into consideration along with its own heuristics, so i
   "prerender": [
     {"source": "document",
      "where": {"and": [
-       {"href_matches": "/*\\?*"},
-       {"not": {"href_matches": "/logout\\?*"}},
+       {"href_matches": "/*"},
+       {"not": {"href_matches": "/logout"}},
        {"not": {"selector_matches": ".no-prerender"}}
      ]},
      "eagerness": "conservative"