Summary
Orion's regex engine returns false for a pattern that matches correctly in Safari, Firefox and Node. When the first branch of an alternation ends in a bounded group quantifier (?:…){2,4} and fails, the engine never falls through to the second branch.
Minimal reproduction
In Orion's Web Inspector console, on any page:
/^#((?:[a-f0-9]{2}){2,4}|[a-f0-9]{3})$/i.test('#333')
- Orion:
false
- Expected (Safari 26.0, Firefox, Node 26 — all on the same machine):
true
Narrowing
| expression | input | Orion |
|---|
/^#((?:[a-f0-9]{2}){2,4}\|[a-f0-9]{3})$/i | #333` | false ← bug |
same, without the i flag | #333` | false (not flag-related) |
/^#([a-f0-9]{3})$/i (second branch alone) | #333` | true |
/^#((?:[a-f0-9]{2}){2,4})$/i (first branch alone) | #333333` | true |
/^#((?:[a-f0-9]{2}){2,4}\|[a-f0-9]{3})$/i | #333333` | true |
/^#((?:[a-f0-9]{2}){2,4}\|[a-f0-9]{3})$/i | #abc | false (any 3-char input) |
branches swapped: /^#([a-f0-9]{3}\|(?:[a-f0-9]{2}){2,4})$/i | #333` | true |
Both branches match correctly in isolation. Reordering them fixes the combined pattern. So the failure is specifically that the second alternative is never attempted once the bounded-quantifier branch fails.
Environment
- Orion, UA:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15
- macOS, Darwin 25.6.0
- Safari on the same machine returns
true, so this is not the system WebKit — it appears specific to Orion's engine build.
Real-world impact
Every mermaid diagram on GitHub fails to render in Orion.
That exact regex is the hex-colour parser in khroma, which is mermaid's colour library. mermaid's built-in themes hardcode 75 three-digit hex literals ( #333`, #eee, #ccc, …), so Color.parse('#333') throws Unsupported color format: "#333" during theme initialisation.
GitHub renders mermaid inside a cross-origin iframe served from viewscreen.githubusercontent.com. The throw kills that bundle before it posts back to the parent, the parent's watchdog times out, and the reader sees a permanent spinner followed by "Unable to render rich display".
Full chain:
Orion regex bug
→ khroma Color.parse('#333') throws
→ mermaid theme init dies
→ viewscreen iframe never posts back
→ GitHub shows a spinner forever
The same diagrams render correctly in Safari and in Firefox-based browsers on this machine, which is what isolated the cause.
Any site using khroma is affected, as is any site whose code happens to use a regex of this shape.
Note for anyone hitting this
It cannot be worked around with a userscript. Orion runs userscripts in an isolated world, and a <script> element inserted from that world into the page never executes (tested at document-start, at every readystatechange, and across 40 polls after load — no error, simply no effect). So String.prototype in the page world is unreachable, and the affected iframe is cross-origin. Until this is fixed the only options are a different browser or a local proxy that rewrites the bundle.
for mermaid diagrams to render properly in github, as they do in Safari and firefox.
Version 1.1.2 (151), WebKit 625.1.8
