Skip to content

fix(renderer): strip Mozilla UA prefix for lightpanda#186

Merged
us merged 1 commit into
mainfrom
fix/lightpanda-emulation-ua
Jun 23, 2026
Merged

fix(renderer): strip Mozilla UA prefix for lightpanda#186
us merged 1 commit into
mainfrom
fix/lightpanda-emulation-ua

Conversation

@us

@us us commented Jun 23, 2026

Copy link
Copy Markdown
Owner

v0.18.2's UA override was a silent no-op on lightpanda (default engine): its validateUserAgent rejects ANY UA containing "Mozilla" (error.Reserved, verified in lightpanda source) → kept its own default UA → JS scrapes still tripped "browser outdated". Strip "Mozilla/5.0 " prefix for lightpanda; the "...Chrome/..." token survives. Chrome keeps full UA. Plan→3x review (caught the Network==Emulation + Mozilla-reject premise)→implement→2x code-review→revise. clippy+209 tests green. Ships in v0.18.3.

Known follow-up (separate, stealth-only): with stealth UA rotation, a Firefox/Safari pool entry sent to lightpanda has no Chrome token — Chrome-only gates may still reject. Not this bug (Mozilla-reject affected everyone); tracked separately.

v0.18.2's Network.setUserAgentOverride was a silent no-op on lightpanda: its
validateUserAgent rejects ANY UA containing "Mozilla" (error.Reserved) and keeps
its own default UA, so JS-rendered scrapes via lightpanda (the default engine)
still tripped "browser outdated" gates. Strip the "Mozilla/5.0 " prefix when the
tier is lightpanda — the "...Chrome/<ver>..." token UA gates check survives, and
lightpanda accepts it. Chrome keeps the full UA. (lightpanda routes Network.* to
the same Emulation handler, so no method change needed.)
@us us merged commit fda6139 into main Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant