fix: text matching Object.prototype property names silently not rendered (closes #746)#758
Open
Vitalini wants to merge 1 commit into
Open
fix: text matching Object.prototype property names silently not rendered (closes #746)#758Vitalini wants to merge 1 commit into
Vitalini wants to merge 1 commit into
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Fixes vercel#746. `graphemeImages` was created as a plain object via `{ ...options.graphemeImages }`, which means it inherits from `Object.prototype`. When the text being rendered exactly matches an inherited property name (e.g. "constructor", "toString", "valueOf", "hasOwnProperty"), the lookup `graphemeImages[text]` returned the inherited method instead of `undefined`. Downstream code then treated that function as an image URL and emitted `<image href="function Object() { [native code] }" ...>` instead of rendering the text as glyph paths. The fix changes the backing storage to a null-prototype object via `Object.assign(Object.create(null), options.graphemeImages)`. Bracket lookups for non-own properties now return `undefined` as expected, and the text falls through to the normal glyph-rendering path. No behaviour change for legitimate emoji/image keys. Test plan: new case in `test/emoji.test.tsx` that renders the text "constructor toString valueOf" without any graphemeImages and asserts the SVG contains no `[native code]`, `[object Object]`, or `<image>` element. All existing emoji and basic tests continue to pass.
7cf7621 to
5e200f1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #746.
graphemeImageswas created as a plain object via{ ...options.graphemeImages }, which means it inherits fromObject.prototype. When the text being rendered exactly matches an inherited property name (e.g. `constructor`, `toString`, `valueOf`, `hasOwnProperty`), the lookupgraphemeImages[text]returned the inherited method instead of `undefined`. Downstream code then treated that function as an image URL and emitted `<image href="function Object() { [native code] }" ...>` in the SVG output instead of rendering the text as glyph paths.Repro (from the issue)
Affected strings: any exact match of an `Object.prototype` property — `constructor`, `toString`, `valueOf`, `hasOwnProperty`, `isPrototypeOf`, `propertyIsEnumerable`, `toLocaleString`, `proto`. Real-world example from the issue: titles containing the word "constructor" silently dropped from OGP images.
Fix
Change the backing storage in `src/satori.ts` from `{ ...options.graphemeImages }` to `Object.assign(Object.create(null), options.graphemeImages)`. The resulting object has no prototype, so bracket lookups for non-own properties return `undefined` as expected, and the text falls through to the normal glyph-rendering path. No behaviour change for legitimate user-provided emoji/image keys.
Test plan