fix(content-drive): upload-button flow drops the file in Chrome (#36279 follow-up)

[zJaaal]

Proposed Changes

Follow-up to #36317 (merged). The Content Drive Upload-button flow silently dropped the selected file in Chrome — the OS picker opened, you chose a file, and nothing happened (no upload, no error).

Root cause

onFileChange read input.files (a live FileList) but reset input.value = '' before the guard/consume. Clearing the input empties that same live FileList, so files.length was 0 by the time the code checked it → silent early-return, upload never fired. (The drag-and-drop flow was unaffected — it never goes through the file input.)

Fix

Consume the files — fire resolveFilesUpload, which captures the File into FormData synchronously — before resetting the input.

if (files && files.length > 0 && selection) {
    this.resolveFilesUpload({ ...selection, files });
}
// reset only AFTER consuming
this.$activeSelection.set(undefined);
input.value = '';

Checklist

• Regression test added (should consume the file before resetting the input (live FileList)) that models the live-FileList semantics jsdom doesn't reproduce (the existing test stubbed files as a static array, which is why this slipped through).
• Verified red→green: the test fails on the old reset-before-consume ordering and passes with the fix.
• portlets-content-drive suite green (668 tests).

Testing

1. In Content Drive (Chrome), click Upload, choose Asset or File, pick a file from the OS dialog → the asset is now created.
2. Drag-and-drop upload still works (unchanged path).

🤖 Generated with Claude Code

This PR fixes: #36279

This PR fixes: #36279

[claude]

Claude finished @zJaaal's task in 48s —— View job

---

Rollback Safety Analysis

• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against unsafe categories
• Apply appropriate label

---

Result: ✅ Safe To Rollback

The changes in this PR are purely frontend/TypeScript — no backend, database, Elasticsearch, or API contract changes are involved.

Files changed:

• dot-content-drive-shell.component.ts — reorders two lines in onFileChange(): calls resolveFilesUpload() before clearing input.value, fixing the live-FileList emptying bug in Chrome.
• dot-content-drive-shell.component.spec.ts — adds a regression test that models live-FileList semantics.

Against every unsafe category:

Category	Verdict
C-1 Structural Data Model Change	✅ No DB touched
C-2 Elasticsearch Mapping Change	✅ No ES mapping touched
C-3 Content JSON Model Version Bump	✅ No contentlet_as_json changes
C-4 DROP TABLE / DROP COLUMN	✅ No DDL
H-1 One-Way Data Migration	✅ No data migration
H-2 RENAME TABLE / COLUMN	✅ No DDL
H-3 PK Restructuring	✅ No DDL
H-4 New ContentType Field Type	✅ No field types
H-5 Storage Provider Change	✅ No storage changes
H-6 DROP PROCEDURE / FUNCTION	✅ No DDL
H-7 NOT NULL column without default	✅ No DDL
H-8 VTL Viewtool Contract Change	✅ No viewtools
M-1 Column Type Change	✅ No DDL
M-2 Push Publishing Bundle Format	✅ No bundlers
M-3 REST/GraphQL API Contract	✅ No API changes
M-4 OSGi Plugin API Breakage	✅ No OSGi interfaces

Rolling back this change reverts the fix, restoring the Chrome-specific bug where uploading via the button silently did nothing. No data loss or system instability.

Label applied: AI: Safe To Rollback

[github-actions]

🤖 dotBot Review (Bedrock)

Reviewed 2 file(s); 0 candidate(s) → 0 confirmed, 0 uncertain (unverified, kept for review).

✅ No issues found after verification.

---

_{us.deepseek.r1-v1:0 · Run: #28383471567 · tokens: in: 6635 · out: 1241 · total: 7876 · calls: 3 · est. ~$0.016}

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request