Your FiveM Enhanced NUI Is Running Chromium 103 (And It Fails Silently)

A gang-zone capture card on Eclipse City had a colour wash across it — a color-mix() gradient that looked perfect in my desktop browser and never rendered in game. Not broken, not ugly. Just absent, with nothing in F8 to say why. Same week I found a :has() rule in a crafting UI that had never applied once since the day it was written.

Both had the same cause, and it took me until 3 August to go and read the number off the disk instead of guessing.

The number

The Enhanced client ships its web engine in its own product folder, separate from the game client:

products\libcef\v103\libcef.dll
            FileVersion  103.0.0-Unknown.0+gUnknown+chromium-103.0.5060.134
            175,687,776 bytes, written 21 Jul 2026
          

Chromium 103. June 2022. V8 10.3. And because libcef lives in products\libcef\ rather than under products\fivem_gen9\, it updates on its own cadence — it does not move when the client build number ticks over. The folder has been dated launch day since launch day.

Every CSS and JS decision in every NUI you ship to Enhanced is bounded by that, whether you know it or not.

Why it fails silently

This is the bit that costs people days. Browsers are designed to drop CSS they don't understand — an unknown pseudo-class invalidates the whole selector, an unknown function invalidates the declaration, and the page carries on. No console error, no warning, nothing. On the JS side it's worse in a different way: .toSorted() isn't a syntax error, it's a method that doesn't exist, so it fails at runtime on the line you reach for it, not at build time where you'd notice.

And the trap that makes it hard to catch: the browser you preview in is modern Chromium. Your dev preview says yes. The game says nothing at all.

The do-not-use list (verified, not guessed)

I didn't want another "probably not supported" list from caniuse, so the probe reads string presence in libcef.dll itself. A feature's internal name being absent is a strong signal — it cannot work. Presence only means "worth one test", because Chromium ships feature names behind flags years before they're on by default.

CSS:

Feature	Shipped in Chrome	Use instead
:has()	105	Add a class from JS
CSS nesting	112	Flat selectors
color-mix()	111	Pre-computed rgba / hex
oklch() / oklab()	111	hex / rgb / hsl
Subgrid	117	Nested grid with explicit tracks
View transitions	111	CSS transitions / keyframes
text-wrap: balance	114	Manual line breaks
Popover API	114	Your own show/hide class

Container queries show up as a string but 103 predates their default ship, so test before you lean on them.

JS, from the V8 10.3 baseline: .toSorted(), .toReversed(), .with(), .toSpliced() (Chrome 110) · Object.groupBy() / Map.groupBy() (117) · the RegExp v flag (112) · Array.fromAsync (121). .toSorted() in particular is pure muscle memory now and it will take a page down.

What you do have, and should use: grid, flexbox gap, :is() / :where(), aspect-ratio, accent-color, scrollbar-gutter, content-visibility, custom properties, clamp(), position: sticky. On the JS side Object.hasOwn, .at(), .findLast(), structuredClone, top-level await, Error.cause, optional chaining and nullish coalescing are all fine.

One that surprised me: the full ICU build ships (10 MB, 55 locales including en-GB), so stop hand-rolling currency:

new Intl.NumberFormat('en-GB', { style: 'currency', currency: 'GBP' }).format(6230); // £6,230.00
          

Other things the same dig turned up

Once you're reading strings out of the client, a few more long-standing mysteries fall over.

• backdrop-filter draws an oversized opaque black rectangle. Not a support problem — it's been in Chromium since 76. NUI is composited over the game, not with it, so the filter has nothing to sample, resolves against transparent black, and fills the compositing layer. The black isn't even clipped to the element. Banned across every UI I ship.
• Plain HTTP can't be loaded from a NUI page. cfx-nui-<resource> is a secure origin, so Chromium auto-upgrades the URL to HTTPS and then fails. The client binary has disable-web-security and autoplay-policy switches but no allow-running-insecure-content, so this can't be turned off. Anything you serve to a NUI needs TLS.
• Those two switches explain things you shouldn't "fix". autoplay-policy is why NUI audio plays with no user gesture, and disable-web-security is why a NUI page can fetch cross-origin at all.
• The DevTools front-end is in there. devtools_app.html, the Elements/Console/Network/Sources panels and ShowDevTools are all embedded in libcef.dll, and the client has a "NUI DevTools" entry in its ImGui dev menu. What isn't wired is a --remote-debugging-port — none of the plumbing exists in the client binary — so the in-client route is the one to chase, not external Chrome.

The rule, and the one thing to watch

Never check caniuse and assume. Check against 103. The probe is a short Python script that greps the DLL for a list of feature names; it takes seconds and it's the only answer that doesn't involve a relog.

The thing to watch is the folder name. On 12 August I re-checked: still one folder, v103, still dated 21 July, nothing moved. But the client binary gained a CFX_PRODUCT_PATH_LIBCEF constant between the 29 July and 11 August builds, which didn't exist before — that's exactly the plumbing you add before you ship a CEF upgrade. The day a second folder appears beside v103, every restriction above is up for re-testing at once. Don't assume they work that day either. Re-run the probe.

FAQ

Running Enhanced and hit a UI that works everywhere except in game? Come and tell me on Discord — I'd like to know what else 103 is quietly eating.

---

Share: Twitter · LinkedIn