Open what the core can read, and say when it cannot

[andiwand]

Opening a zip offered the reader and then failed. Fixing that turned up the same
problem from both sides: the reader kept its own list of formats to hand to the web
view, and that list had gone out of date.

What changed

The reader asks odrcore what it can read instead of deciding for itself. The list of
45 extensions is gone.

• A zip opens and lists what is inside. Its entries open too — odrcore writes every
  link with target="_blank", which a web view with no window to open drops on the
  floor, so they lead nowhere without a WKUIDelegate. Swipe back returns to the
  listing.
• .heic .heif .hif .jpe .dib .text now open. They were only failing
  because the list predated them, and .heic is what an iPhone camera writes.
• A file that will not open closes the reader and says so over the document browser,
  the way OpenDocument.droid does. Three outcomes, and only one asks for mail:
  a format odrcore cannot read, a locked legacy Office file, and a file odrcore took
  and then could not show. The last also fires on a served page answering 4xx/5xx and
  on a web view navigation failure. The four strings are lifted from Android's own
  translations in all 16 languages, so both apps say the same thing.
• public.audiovisual-content is out of both plists. odrcore plays a sound or a film
  because Android once did; a document reader should not be the handler for an mp3.

iWork keeps its rendering

.pages, .numbers and .key are zips, so "core decides" would have shown a file
listing where the system used to draw the document properly. They keep the system's
rendering, but through a condition that names no format: odrcore saw only a
container, and the system knows this file as composite content. .pages is; .zip
and .jar are not.

It retires itself twice over. The day odrcore reads iWork, the file stops being an
archive to it and the branch never fires. And if the system turns out not to be able
to draw it — an .epub — canShowMIMEType says so and odrcore's listing takes over.

Checked against real files

	route	result
.pages (real, 3 pages)	system	full render, snapshot identical to before
.epub	system refuses → core	listing
.zip	core	listing
.heic	core	image
.odt	core	document

Also verified end to end with the 64 MB zip of photos that started this.

Upstream

odrcore never rejects anything — its last resort is "this is a text file", which it
returns for an empty file, a database or a program, then serves 27 KB of nonsense. The
charset check that catches it is Android's, and it is a workaround in both apps now:

• Text is the fallback for anything unrecognised, so unreadable files render as nonsense OpenDocument.core#728 — the text fallback, with the measurement that
  the charset check misses NUL-padded binaries
• translate_html cannot tell a format whose page renders from one whose page is blank OpenDocument.core#729 — translate_html cannot tell a format whose
  page renders from one whose page is blank, which is why .psd and .jp2 now show a
  blank page instead of the old message
• Views set target="_blank", so links are dead in an embedded web view OpenDocument.core#730 — target="_blank" on every view

Tests

65 pass. New coverage for the archive listing and its links, the routing between core
and the system, the charset refusal and its counterpart, and each failure message.
testUnsupportedFileTypeReportsTypedError was flaky — random bytes are often named as
a charset — and now uses every byte value instead.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a0080967a4

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".