test: the page counts the keys it is given, and a timing key waits for the player - #309
Merged
Merged
Conversation
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
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.
Summary
layer-owns-the-keyboard.spec.jshas been failing on the runner and here, always the same way: T is pressed, the app writes noplayback:line at all, and the check waits out its whole timeout. It read as one of the silences under N101, and it is not one. Both beats were regular through it, the page had the keyboard, and a click guard proved no gesture was landing on the X root.What settled it is a counter.
App.tsxnow records every keydown the page is given, straight onto the root element, and the check reads it: on the failing run the page had been given the key and the command still did not run. That leaves one thing, and it has a precedent written in this repository: the press lands on a command that is still greyed.timing-play-keys.spec.jspaid for this and says so in its ownbeforehook; this file waited only for the transport to be drawn, which is not the player being ready.Closes N173.
Changes
document.documentElement.dataset.keysSeen.beforehook waits for the media's length and for the transport button to come alive, which is what wakes the timing keys.How to verify by using the app
Nothing changes on screen. The counter is a data attribute the harness reads; it costs no render and no IPC.
Verified on Linux. The spec passes, and the battery it kept failing in passed with it. Proved by a mutation in the build: with the counter not written, the string is gone from the bundle and both checks in that file fail with
the page never saw a keydown, which is the message that made the diagnosis in the first place.One thing stated rather than buried: the battery in that gate run went red on
transport-after-open.spec.js, on a five second wait. That file is not touched here, it passes alone, and batteries on this machine started dropping one spec per run at about nine this morning with no behavioural change of mine in between, which reads as the machine rather than the tree.