Retry the font information pane's close click in the e2e helper - #8351
Merged
Conversation
Contributor
Author
|
[Claude Opus 5 (1M context)] Consulted Devin on 2026-09-11 20:42 UTC up to commit Devin's review completed for that commit with no findings: no Bugs, no Investigate flags, and no Informational items. Nothing to mirror. The local review (a read-only sub-agent over the diff) was also clean, and the font-chooser e2e spec passes locally, 11/11. |
The nightly BloomE2E suite has failed two runs running on the same font-chooser test, "the information icon shows the font's raw metadata". The test is what is broken, not Bloom, and while it is red it hides whatever else the nightly would have caught. The information pane is a MUI popover, so it shuts on a click away -- and dismissing the browser alert that showFontDetails raises counts as one. On a slow machine the pane is therefore usually gone before closeFontInformationPane runs, and sometimes caught mid-unmount, where its close button reads "not stable" and then "detached from the DOM", which is the shape the nightly log showed. Either way the helper spent its whole 30-second budget waiting for a button on its way out, and failed a test whose subject is not that button at all. So click the X only while there is one, and let an already-shut pane be a success. The pane ending up shut is the whole of what this helper owes its caller; the toBeHidden assertion that checks it is unchanged. Verified by running the full e2e suite twice locally, where the failure reproduces under load: font-chooser fails on the old code and passes on this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
andrew-polk
force-pushed
the
e2e-font-pane-close-retry
branch
from
September 11, 2026 21:11
c1fdb57 to
ac8ca12
Compare
andrew-polk
marked this pull request as ready for review
September 11, 2026 21:11
andrew-polk
added a commit
that referenced
this pull request
Sep 11, 2026
…lection Three nightlies have now lost a cover title: a title typed on the cover of a brand-new book is missing from the saved book, so the collection never learns it and Bloom never renames the folder to match. import-recording hit it on 5 September; bulk-upload-quick-test has died on it on 10 and 11 September, which is why that test is red every night. On the runner it is close to deterministic; on a developer machine it has never once reproduced, so nobody can say whether Bloom is dropping an edit or our own typing is not enough like a person's. This adds no fix. It adds the instruments that should settle that question from a single nightly run. - cover-title-save.spec.ts makes the same book three times, typing the title a different way each time -- today's insertText, real key presses, and insertText followed by an explicit blur -- and reports for each what the box held just before the save and whether the collection learned the title. Every read of the box is non-interacting, because clicking it back into focus before the save would undo the blur variant and put a fresh click into all three runs. - typeInGroup gains an optional typing-method argument for that, defaulting to today's behavior, so no existing test changes. - EditingModel logs the bookTitle it finds in the page content the browser sends back for a save, and only for pages that have one. That says whether the text was already gone before Bloom saw it, or was lost after. - AUTOMATION-DEBT.md records what the investigation established -- only the cover title is lost while everything typed after it saves; the log signature is a missing "Renaming folder" line after InsertTemplatePage; twelve local attempts could not reproduce it -- and what each probe outcome would mean. Both instruments are meant to be deleted once the question is settled. Also on that file: a dropped page-thumbnail click, found while preflighting #8351, recorded as a seen-again on the entry it belongs to rather than as a new gap. And a papercut for the kept Bloom log being reachable only by unzipping the trace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The nightly BloomE2E suite has gone red on the same font-chooser test two runs running — "the information icon shows the font's raw metadata". It is the test, not Bloom, that is broken, and every nightly failure hides the real ones behind it.
Cause
The font information pane is a MUI popover, so it shuts on a click away — and dismissing the browser alert that
showFontDetailsraises counts as one. On a slow machine the pane has therefore usually closed itself beforecloseFontInformationPaneruns, or is caught mid-unmount, where its close button reads "not stable" and then "detached from the DOM". Either way the helper spends its whole 30-second budget waiting for a button that is on its way out, and fails a test whose subject is not that button at all.The first attempt at a fix here retried the click, which did not help — the retry just spent the same 30 seconds. Running the full suite locally reproduced the failure and the page snapshot settled it: at the moment of failure the font dropdown is open and there is no information pane on screen.
Fix
closeFontInformationPanenow clicks the X only while there is one, and treats an already-shut pane as done. The pane ending up shut is the whole of what the helper owes its caller, and thetoBeHiddenassertion that checks it is unchanged.Verified by running the whole e2e suite twice locally, where the failure reproduces under load: font-chooser fails on the old code and passes on this.
Devin review
🤖 Generated with Claude Code
This change is