Repository navigation
Conversation
jrusso1020
reviewed
Oct 15, 2026
jrusso1020
left a comment
Collaborator
There was a problem hiding this comment.
The change looks good to me. I'm commenting instead of approving only because the branch conflicts with main. Please rebase and I'll approve.
The conflicts are in packages/studio/package.json and bun.lock: main removed bpm-detective next to where acorn is added. Both are a one-line resolution. It merges cleanly with #3900.
On the change itself:
packages/studio/src/captions/parser.ts:128-131: letting Acorn find the array boundary (parseExpressionAt, then requiring a;token) fixes the];-inside-a-string case from #3852. Like the old regex, it still requires a terminating;.readStaticValueaccepts only literals, signed numeric literals, arrays and plaininitproperties. Getters, methods, shorthand, computed keys, spreads, template literals, regex and bigint all reject the transcript, and nothing is ever evaluated.Object.fromEntriesmakes a__proto__key an own property, so there's no prototype risk.- Adding
acornas a direct Studio dependency doesn't grow the bundle. Studio already ships acorn through@hyperframes/parsers(gsapParserAcorn,scriptShape, etc.), so this just makes the import explicit.
What I ran:
vitest run src/captions: 94/94 pass.- Mutation check: with the base
parser.tsrestored, 6 new cases fail (];delimiter,,]text, object-key text, escaped double quotes, hex/Unicode escapes, comments). The rejection cases already passed on main, which is expected because the old code also returned[]for them.
— Rames
AksharP5
force-pushed
the
fix/caption-transcript-literals
branch
from
October 15, 2026 17:24
df983ce to
1f7a5b5
Compare
Contributor
Author
|
@jrusso1020 Rebased onto main and resolved both dependency conflicts in |
This branch has not been deployed
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.
Caption editing can miss an entire transcript when a word contains
];. The old normalization also changes literal text such as,]and rejects JavaScript escapes.Use Acorn to find the array boundary and decode static data without executing the source. Text, word IDs, timing, and existing JSON/single-quoted syntax are preserved. Executable expressions and malformed input still return an empty transcript.
Fixes #3852.
Verification
parseCaptionCompositionwith an iframe DOM preservedx ]; y,literal ,] and ,}, hex escapes, escaped quotes, IDs, and timing. An executable initializer was rejected with zero calls.Four files changed. No visual styling or layout changes.
Before
Main imports none of the three words when the first contains
];. Browser regression harness using the actual Studio parser from main (a4a7cbeac) and synthetic fixture data in a live iframe DOM.After
The same input imports all three words with literal text, IDs, and timing preserved. The harness uses this PR’s parser with the same source and DOM.