Repository navigation
fix: accept upload-only video attachments for upload_file - #3179
Merged
esokullu merged 2 commits intoOct 12, 2026
Merged
Conversation
Fixes webbrain-one#3166 - The sidebar accepts MP4, MOV/QuickTime and WebM files as upload-only attachments (25 MB cap). Video contents never enter model context; the agent attaches the file to a page file input with upload_file and its attachmentId. - upload_file checks video container signatures (ftyp brands, EBML DocType) against the page accept, so a renamed file cannot pass an MP4-only input. - On X public composer routes (/compose/post, /compose/tweet), upload_file no longer requires recipient binding, because a public post has no recipient. Clicks, typing and key presses on those routes keep the generic guard, and DM routes are unchanged. - Chrome and Firefox are mirrored. Unit, recipient-upload and real Chrome MV3 coverage are registered in the existing CI shards. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot stopped reviewing on behalf of
16Miku due to an error
October 12, 2026 16:21
Bring the branch up to date with webbrain-one/webbrain main (40dc6cb) so the PR merges cleanly. The only textual conflict was in package.json test shard command lists; both sides are kept (upstream shard additions plus the video upload unit and MV3 tests). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
@16Miku is attempting to deploy a commit to the esokullu's projects Team on Vercel. A member of the Team first needs to authorize it. |
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.
Fixes #3166
Summary
upload_file({attachmentId}).upload_filechecks video container signatures (ftyp brands, EBML DocType) against the page'saccept, so a renamed file cannot pass an MP4-only input./compose/post,/compose/tweet),upload_fileno longer requires recipient binding. Clicks, typing and key presses on those routes keep the existing guard. DMs (/i/chat/) are unchanged.Why the X exemption is needed
Recipient binding stops a message from reaching the wrong person. A public post has no recipient, and its composer sits near the top of the page, so the upload probe returned
recipient_upload_target_unverifiableon every attempt. This was reproduced intest/message-recipient-upload.mjsfor both Chrome and Firefox. The exemption applies only toupload_file, and only to routes an adapter declares withmessaging.publicComposer.Review notes
isPublicComposerRouteand its two call sites inagent.js:_messageRecipientGuardBlockand_recipientBoundUploadContext.UNTRUSTED_CONTENT_TOOLSis unchanged.attachmentCount. The attachment payload stays in memory.getFullPageCapturePolicyimport.webbrain-one/webbrainmain at40dc6cbe9to resolve a conflict inpackage.jsonshard lists. Both sides are kept.Testing (on the merged branch,
25647e536)node --test test/video-upload-attachment.mjs test/file-upload-accept.mjs test/file-upload-accept-agent.mjsnode test/message-recipient-upload.mjs(includes new X public-composer and DM cases)node test/quality/video-upload-attachment-mv3.mjs(real Chrome MV3)node test/run.jsrepository changelog retains complete…, which compares CHANGELOG.md (40.2.2) with package.json (40.4.0) on main. This PR changes neither file.node test/fixtures/run.mjswebbrain-one/webbrainmain:steering after a submission permits verified social recovery controls(chrome and firefox) and two Firefox geometry cases.node --test test/draftjs-text.mjsdirect-caret,wrapped-caret,Chrome: native appends preserve strong empty-editor proof…) also fail on pristine upstream main.npm run build:chrome,npm run build:firefoxThe failures listed above exist on upstream main without this PR. They are called out so CI results can be read against that baseline.
Known limitations
sp.attach.unsupported_typecopy in the 24 locale files still lists the old types. This PR does not translate it.acceptdecides, and a mismatch is reported asfile_type_mismatch.CONTRIBUTING.md checklist
test/run.js. One pre-existing failure is unrelated to this PR.docs/prompt-injection-defense.md. No new tools or registry changes. No page-derived content added.test:shard:runtime-unitandtest:shard:browser-b2sp.attach.unsupported_type(follow-up)