Fix: dropping files on a project page no longer triggers Chrome's def...
From the PR description
...ault file-open
Previously, dragging a file from the OS onto /projects/[id] caused Chrome to navigate to/download the file because dragover wasn't preventDefault'd on the header, sidebar gutter, or padding around the document list. The existing drop handlers only covered folder rows + the doc-list container and only knew how to move internal mike-doc / mike-folder MIME types.
Adds:
- A page-level dragover/drop fallback on the outer ProjectPage wrapper that preventDefaults on file drags and uploads to project root.
- File-upload handling in handleDropOnFolder so dropping on a folder row (existing target) uploads INTO that folder.
- Client-side suffix allowlist (pdf, docx, doc, txt, eml, xlsx) matching the backend ALLOWED_TYPES; unsupported drops show an alert listing filenames and supported types.
- stopPropagation on the existing doc-list root drop so it doesn't double-fire with the new page-level handler.
Our analysis
Fix project page drag-and-drop to prevent default file-open — read the full analysis →
Think the analysis missed something the PR description covers?
Capture this PR into my fork
Download a Markdown prompt that tells Claude how to port every
commit in this PR into your working tree. Run it via
claude -p < capture-pull-9.md from
inside the repo you want the changes in.