E2E tests for when Bloom updates a book's pages (Notion test case 834, BL-16893)

[hatton]

Stacked on #8407. That PR targets Version6.5, where src/BloomE2E does not exist, so these tests live on a branch made from master with #8407's branch merged in. Merge #8407 first; once it has reached master, this PR's diff shrinks to the tests and the hook below.

Bloom production code changes

• src/BloomExe/web/controllers/E2eTestingApi.cs: new e2e/failPageUpdateAt hook (registered only under --e2e). Its POST body is a 1-based page number.
• src/BloomExe/Book/BookProcessor.cs: when the page pass reaches that page, it throws, as a page whose content could not be captured does. The setting clears itself, so it affects one update only.

Purpose

These tests protect when Bloom brings a book's pages up to date (BookProcessor's page pass), and when it doesn't:

• a page size change or a theme change makes the book need it;
• the first Publish tool the user chooses runs it, and the next one does not;
• a new book made from Basic Book or from The Moon and the Cap needs none;
• a failed update is reported, and the next Publish tool tries again.

Automates Notion test case 834 (Bloom Updates a Book's Pages When a Tool Needs Them): https://app.notion.com/p/Bloom-Updates-a-Book-s-Pages-When-a-Tool-Needs-Them-3e74bb19df128125bce8dc2d84c8b725

Steps

src/BloomE2E/tests/page-layout-update.spec.ts, five tests, each on a new book:

• Basic Book → A5Landscape → PDF & Print runs the update → Web does not.
• Basic Book → theme rounded-border-ebook → PDF & Print runs the update.
• A new Basic Book: PDF & Print runs no update.
• A new book from the Sample Shell The Moon and the Cap: PDF & Print runs no update.
• Basic Book → A5Landscape → a failure armed at page 2 → PDF & Print:
  • the dialog reports the failure and no longer says "Please wait";
  • the tool opens only after Close;
  • the book still needs the update;
  • Web then runs the update again, and this time it succeeds.

How it verifies the result

• Whether the update ran: a watch set up before each Publish click records whether the update's progress dialog appeared at all. That works however briefly the dialog shows.
• Whether the book is up to date: the test reads pageLayoutUpdateLevel from the saved .htm. It expects "0" after a layout change and "1" after an update.
• Whether the tool opened: the test waits for the tool's panel to be visible.

New helpers

• helpers/updateBookDialog.ts (new): watch for the update dialog, arm a failure, wait for the dialog's problem report, close it.
• helpers/bookSettings.ts (new): setBookTheme, which posts what the Book Settings dialog posts.
• helpers/publish.ts: showPublishDestination and isPublishDestinationShowing.
• helpers/bookHtml.ts: readPageLayoutUpdateLevel and waitForPageLayoutUpdateLevel.
• helpers/bookMaking.ts: makeBookFromSampleShell; the template lookup now takes the source collection's name.

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16893

🤖 Generated with Claude Code

Devin review

---

This change is 

[greptile-apps]

[Medium risk] Adds end-to-end tests for page layout updates.

The PR does not appear safe to merge until successive-page processing, appearance invalidation, and Publish completion ordering are addressed.

Findings

1.  Successive page navigation can hang ▶
2.  Publish completion can be lost ▶
3.  Appearance overrides leave stale measurements ▶
4.  Previously processed books run again ▶

Summary

The PR adds end-to-end coverage for page-layout updates and a test-only failure hook, while also changing update scheduling, metadata, off-screen browser reuse, and progress UI.

• Publish destinations now wait for an automatic page pass when one is due.
• Book Settings and layout changes invalidate the new pageLayoutUpdateLevel record.
• The review identified risks in successive off-screen page loads, Publish completion ordering, and appearance changes outside Book Settings.

_{Reviews (1) · Last reviewed commit: "E2E tests for when Bloom brings a book's..."}