[Bug]: PPTX (and other OOXML) uploads rejected on Linux — old XDG MIME databases report application/vnd.ms-office

[cosarah]

Bug Description

Uploading a .pptx course material succeeds on macOS Chrome but is rejected on Kylin OS (Linux) Chrome with the toast “当前解析器不支持该格式，请切换解析器或选择其他文件” (“The current parser does not support this format — switch parsers or choose another file”). Same file, same server, same selected extractor (MinerU / AliDocMind — both list PPTX in their capability matrix).

Root cause. On Linux, Chrome derives File.type from the system XDG shared-mime-info database instead of a built-in table. Older or trimmed databases (as shipped on Kylin V10) map *.pptx / *.docx / *.xlsx to the generic OOXML container type application/vnd.ms-office rather than the concrete application/vnd.openxmlformats-officedocument.presentationml.presentation.

normalizeDocumentMimeType() in lib/document/mime.ts then routes that value into the wrong bucket:

1. Empty or zip-family MIME (application/zip, application/octet-stream, …) → falls back to the file extension ✓
2. Canonical or curated alias MIME → mapped ✓
3. Any other MIME → returned verbatim; the extension is deliberately not trusted (anti-spoofing design, pinned by tests/document/mime.test.ts “does not let an unknown MIME masquerade as a supported format”)

application/vnd.ms-office lands in bucket 3: it is neither in GENERIC_DOCUMENT_MIME_TYPES nor in any aliasMimes, so it survives normalization verbatim, fails the provider whitelist in components/generation/generation-toolbar.tsx (isMimeSupportedByProviders on { file.type, file.name }), and the toast fires. The file picker still offers .pptx (the input's accept list contains the extension), so the rejection only appears after selection — which makes it look parser-related to users.

The same browser-reported MIME also reaches the server-side gate in app/api/extract-document/route.ts (normalizeDocumentMimeType on documentFile.type / documentFile.name), and the workbench material path validates the Content-Type header against its own policy (app/api/materials/route.ts → isWorkbenchMaterialMime, 415 unsupported_mime), so both paths share the exposure.

Steps to Reproduce

1. On a Linux desktop whose MIME database maps OOXML extensions to the generic type (reproduced on Kylin OS V10 — xdg-mime query filetype slides.pptx returns application/vnd.ms-office), open Chrome.
2. Open the course generation page with an extractor that supports PPTX selected (e.g. MinerU).
3. Upload a .pptx via the course-material paperclip (file picker or drag-and-drop).
4. The error toast appears immediately; no request leaves the browser.

Quick check of what the browser reports (any page, DevTools console):

const i = document.createElement('input'); i.type = 'file';
i.onchange = () => console.log(i.files[0].type, i.files[0].name); i.click();

On Kylin this prints application/vnd.ms-office slides.pptx; on macOS/Windows Chrome it prints the concrete ...presentationml.presentation MIME, which is why the same upload works there.

Expected Behavior

When the browser reports a generic Office MIME, the file extension should resolve the concrete format — exactly as the existing fallback already does for application/zip and empty types. .pptx uploads should work identically on every OS.

Actual Behavior

The upload is rejected client-side with the “unsupported format” toast because the generic OOXML MIME is passed through verbatim and never normalized to the concrete format.

Deployment Method

Any — the defect is OS-dependent client behavior (observed against a self-hosted deployment; the server plays no role in the rejection).

OpenMAIC Version

main @ 98765db8 (v1.0.2)

Affected Area

Classroom generation

Browser

Chrome (Linux build)

Operating System

Kylin OS V10; expected on any distro shipping an older shared-mime-info. macOS and Windows unaffected.

Relevant Logs

None server-side — the rejection happens in the browser before any request. Bypassing the UI check would hit the same rejection at the extract-document API layer.

Screenshots or Recordings

–

Additional Context

Suggested fix: treat application/vnd.ms-office as a generic upload fallback by adding it to GENERIC_DOCUMENT_MIME_TYPES (lib/document/mime.ts). The semantics match the existing zip-family entries exactly: the MIME says “some Office file” and carries no format specificity, so the extension decides. No new spoofing surface relative to application/zip (a file can already be renamed to .pptx with a zip/empty MIME; downstream parsers still validate real content, and unknown extensions still fall through verbatim and stay rejected).

⚠️ Do not add it to per-format aliasMimes instead: canonicalFromAlias iterates DOCUMENT_FORMATS in declaration order (doc first), so one shared alias would misroute x.pptx → application/msword, which self-hosted MinerU rejects — worse than the status quo.

Two follow-ups worth deciding alongside:

• lib/workbench/material-upload-policy.ts + app/api/materials/route.ts need the same value if Linux clients matter on the workbench path (today they get a 415 unsupported_mime).
• Kylin boxes with WPS Office installed may report WPS-registered MIME values instead; worth collecting real-world values before deciding whether any deserve the same treatment.