Wait for the marking strip in testPDF, rather than reading it off the next line - #673
Merged
Merged
Conversation
… next line The test asserted on the strip's tools on the line after the click that opens mark-up mode. On the api 26 emulator that read as missing: the strip reaches the screen after the click returns on a slow device. It waits for `editing_tools` now, and checks the highlighter - the tool every edition offers, and the first in the row, so a 320dp screen shows it without scrolling. The pen gets a `scrollTo()` for the same reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
andiwand
enabled auto-merge (squash)
September 20, 2026 13:21
andiwand
disabled auto-merge
September 20, 2026 13:29
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.
testPDFasserted on the strip's tools on the line after the click that opens mark-up mode. On the API 26 emulator that read as missing and the test failed in foss and lite - the strip reaches the screen after the click returns on a slow device.It now waits for
editing_toolsto be visible, and then checks the highlighter: it is the tool every edition offers, and the first in the row, so a 320dp screen shows it without scrolling the strip. The pen, which lite taps to raise the Pro offer, gets ascrollTo()for the same reason.What else API 26 says
The floor has been red for a while, and this was the only new red. Comparing the artifacts either side of the editing work:
c4756212(before)9ac90a0a(after)DarkModeTests×2LargeTextTests.aMegabyteOfTextOpensAndIsSearchableMainActivityTests.testODT(pro)MainActivityTests.testPDFThe two
DarkModeTestsareAssumptionViolatedException- the suite's own skip for a WebView that cannot darken (69.0.3497.100), which the runner counts as a failure.LargeTextTestspasses on its own and fails in a full run on every device I have tried, here included.testODTreportsbodyEditable=false editableNodes=0 odr=object, so the page loads and the editor never takes on that WebView; that one looks real and is worth its own look.Checked on a Pixel 6 Pro emulator:
MainActivityTestsgreen in both editions.