Encounter this bug while on chatgpt.com. Mermaid diagrams in chatgpt.com fail to render.
Summary
Orion incorrectly returns false for a valid JavaScript regular expression when the first branch of an anchored alternation requires more characters than the input, even though the second branch matches.
Reordering the two semantically equivalent alternatives makes the expression succeed.
This causes Mermaid.js diagrams to fail on ChatGPT and potentially other applications because Mermaid's khroma dependency uses the affected expression to parse hexadecimal colors such as #333`.
Environment
- Orion version: Version 1.1.1 (149-rc), WebKit 625.1.8
- macOS version: Version 26.5.2 (25F84)
- Hardware/architecture: Apple Silicon
- Compatibility Mode enabled: Happens on both
The issue does not occur in Safari, Chrome, or Firefox on the same machine.
Steps to reproduce
Open Orion's Web Inspector console and run:
[
["simple", /^#[a-f0-9]{3}$/i.test("#333")],
[
"original",
/^#((?:[a-f0-9]{2}){2,4}|[a-f0-9]{3})$/i.test("#333"),
],
[
"reordered",
/^#([a-f0-9]{3}|(?:[a-f0-9]{2}){2,4})$/i.test("#333"),
],
[
"expanded",
/^#(?:[a-f0-9]{3}|[a-f0-9]{4}|[a-f0-9]{6}|[a-f0-9]{8})$/i.test("#333"),
],
[
"six-digit",
/^#((?:[a-f0-9]{2}){2,4}|[a-f0-9]{3})$/i.test("#333333"),
],
];
Actual result in Orion
[
["simple", true],
["original", false],
["reordered", true],
["expanded", true],
["six-digit", true],
]
The minimal failing case is:
/^#((?:[a-f0-9]{2}){2,4}|[a-f0-9]{3})$/i.test("#333")
// false in Orion
The input contains the expected ASCII code points:
[..."#333"].map((character) =>
character.codePointAt(0).toString(16)
);
// ["23", "33", "33", "33"]
Expected result
The original expression should return true.
The second branch:
[a-f0-9]{3}
matches the 333 portion of #333`.
The following expressions are semantically equivalent for this input and should both succeed:
/^#((?:[a-f0-9]{2}){2,4}|[a-f0-9]{3})$/i.test("#333");
/^#([a-f0-9]{3}|(?:[a-f0-9]{2}){2,4})$/i.test("#333");
Changing only the order of the alternatives should not change the result.
Suspected cause
This appears to be a RegExp length-analysis, alternation, or JIT optimization bug in Orion's JavaScriptCore/Yarr environment.
In the failing expression, the first alternative has a minimum width of four characters:
(?:[a-f0-9]{2}){2,4}
That branch cannot match the three-character substring 333, but the engine should then try the second alternative. The results suggest that Orion may be rejecting the complete alternation based on the first branch's minimum width.
Real-world impact
I originally encountered this on chatgpt.com while it was rendering a Mermaid diagram:
Error: Unsupported color format: "#333"
Mermaid uses the khroma color library. Khroma's hexadecimal parser contains the affected expression:
/^#((?:[a-f0-9]{2}){2,4}|[a-f0-9]{3})$/i
Source:
https://github.com/fabiospampinato/khroma/blob/a4cab73583633391a976c383d24c4007f1f25094/src/color/hex.ts#L15-L25
Mermaid also uses #333` as a built-in theme color:
https://github.com/mermaid-js/mermaid/blob/4bc79dd223bd47d445949819951cf46fdaae33ca/packages/mermaid/src/themes/theme-default.js#L31-L40
As a result, Mermaid's JavaScript color parser rejects a valid color and diagram rendering fails.
An unrelated application has reported the same Unsupported color format: "#333" failure specifically in Orion:
https://github.com/backnotprop/plannotator/issues/894
Possible application-level workaround
Reordering the alternatives avoids the problem in Orion:
/^#([a-f0-9]{3}|(?:[a-f0-9]{2}){2,4})$/i
Using six-digit colors such as #333333` also avoids this particular failure.
However, the original expression is valid ECMAScript and works correctly in Safari, Chrome, and Firefox, so the underlying issue appears to be in Orion's JavaScript execution environment.
regex should work properly.
Version 1.1.1 (149-rc), WebKit 625.1.8
Tahoe (26)
