[AlexSamBY]

What

Upload refuses a drop that holds a file larger than its maxSize, and
a drop with no file of a type its formats take, and hands the
document's popup a title and a message that say so. It handed them
without isOpen, and AppProvider's setPopupState keeps the popup's
isOpen when it is not given, which is false: the popup got its
title and message and stayed closed, and the user was refused without a
word. Every 0.34.x release has the same two calls and the same
provider. The engine's own popups pass isOpen: true (popupAlert),
and so does the demo page's.

Both of the upload's popups now pass it. Nothing else changes: a drop
that holds one file too large is still refused whole, and the texts are
the built-in phrases, translated with the document's translator. An
upload inside an open popup is the one case that showed the message
before, measured: it takes that popup's place, before and after this
change.

Tests

• upload-popups.test.js, through the library entry, with the real
  popup state and Modal:
  • a file over maxSize opens the dialog, named by its title, with the
    file's name and the limit, and uploadFile is not called;
  • a drop of a small and a large file is refused whole;
  • a drop of a type the formats do not take opens the
    File Upload Failed! dialog;
  • Ok closes it, and the next refused drop opens it again;
  • an accepted file opens no dialog and reaches uploadFile.
• built-in-phrases.test.js showed the upload's popups in a Modal of
  its own, since the document opened none. It now reads them from the
  document, for each of the three translators.
• The two Upload unit tests that stub setPopupState now expect
  isOpen: true, and the size case expects no onChange call.
• interactive-views.pw.js, in Chromium: a 2 MB + 1 byte image picked
  from the keyboard on the uploadVariants example opens the dialog
  above the page; it takes the focus, Escape closes it, and the focus
  goes back to the drop zone. view-coverage.js names it under
  Upload, and reference.js holds its values.

On the code before this change, all twelve of the changed and added
jest tests that open a popup fail, and so does the browser test. The
accepted-file case passes on both.

Gates

On Node 24.14.0, on the branch merged with origin/master (#242 and
#239), these exit 0:

• npm test (244 suites, 3187 tests) and test:coverage, with every
  threshold held;

• test:react16, test:react17 and test:react19;

• lint:js, typecheck, docs:views:check, docs:props:check and
  docs:phrases:check;

• test:e2e and test:e2e:react19, 76 tests each in Chromium, desktop
  and touch.

• The merges conflicted only where both sides added entries: with
  EPBDS-13515: a background class in a header's classNameHeader colours the whole header cell #242 in interactive-views.pw.js, reference.js and the changelog,
  and with EPBDS-12884: a date field keeps text that is no date, and says Invalid date #239 in the changelog. Both sides are kept.

• test:react16, on the merge with EPBDS-13515: a background class in a header's classNameHeader colours the whole header cell #242 alone, exited 1 on two
  runs: a jest worker died with SIGSEGV, a known Node 24 crash, in two
  suites this PR does not touch. It exited 0 on the third run, and on
  the merge with EPBDS-12884: a date field keeps text that is no date, and says Invalid date #239 on the first.

• The jest legs ran with <rootDir>/\.claude/ ignored, for a stray,
  gitignored probe in this checkout, which CI's checkout does not have.

• The new browser test, and the upload's keyboard test, also pass in
  WebKit. Firefox did not start in this environment.

🤖 Generated with Claude Code