FOXA-2699 : le focus d'entrée attend le bouton Lecture, il n'abandonne plus après 240 ms #1010
No reviewers
Labels
No labels
montee-majeure
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
foXaCe/NuvioTV!1010
Loading…
Reference in a new issue
No description provided.
Delete branch "passe-20261018-183000-focusentree"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Résumé
FOXA-2699 — quand la fiche n'a aucune lecture possible, l'écran ne descend plus tout seul en bas.
2c3baf229FOXA-2699 : le focus d'entrée attend le bouton Lecture, il n'abandonne plus après 240 msPourquoi
Le focus d'entrée était demandé trois fois à 80 ms d'intervalle, puis abandonné :
240 ms. Or une fiche sans source met plus longtemps que ça à résoudre : le bouton Lecture n'est
pas encore attaché, les trois demandes ne visent aucun nœud, et le focus retombe sur la recherche par
défaut de Compose — le premier focalisable de la liste, très bas.
C'est ce qui explique « sur une seule fiche et pas sur les autres » : la fiche dont la résolution
traîne est précisément celle qui tombe.
Le registre
CiblesAttacheessait déjà si le bouton porte un nœud —suivreLAttacheest posé dessus.On l'attend au lieu de deviner une durée, borné à ~4 s, puis on demande le focus une seule
fois, quand il existe.
⚠ Le retour de bande-annonce garde son comportement d'avant (une demande, un jeton honoré une fois) :
ce correctif ne touche que l'entrée.
Ce qui a été mesuré
3 tests, dont un qui nomme la cause en interdisant le retour du
repeat(... 1 else 3):!ciblesAttachees.estAttachee(heroPlayFocusRequester)repeat(if (apresBandeAnnonce) 1 else 3)absentattente < 50— une boucle sans limite bloquerait le focus pour toujours⚠ Ce banc lit la source, et il ne remplace pas la boîte. Aucun banc du dépôt n'instancie la fiche
détails entière (une vingtaine de paramètres, plusieurs sections, un état de bande-annonce). Ce qui
est verrouillé est la cause : le renoncement à durée fixe. La preuve « le focus reste sur le
héros » demande la Freebox et le film concerné — elle est le seul maillon que cette PR ne prouve pas.
Porte jouée par la forge : « Porte / porte* » est le seul contexte qu'exige la protection de
main.Scope boundaries
Le retour de bande-annonce (
LECTURE_APRES_BANDE_ANNONCE) n'est pas modifié. Aucun autre écrivain defocus de la fiche n'est touché : les
focusRestorerdes sections (épisodes, distribution, similaires,bandes-annonces, collection, logos) restent tels quels.
Quand la fiche n'a **aucune lecture possible**, l'écran descendait tout seul en bas au lieu de rester sur le héros. La cause était une durée devinée : ```kotlin repeat(if (apresBandeAnnonce) 1 else 3) { heroPlayFocusRequester.requestFocusAfterFrames() delay(80) } ``` Trois demandes à 80 ms d'intervalle, puis **renoncement** — 240 ms. Or une fiche sans source met plus longtemps que ça à résoudre : le bouton Lecture n'est pas encore attaché, les trois demandes ne visent aucun nœud, et le focus retombe sur la recherche par défaut de Compose — le premier focalisable de la liste, très bas. C'est ce qui explique « sur une seule fiche et pas sur les autres » : la fiche dont la résolution traîne est celle qui tombe. Le registre `CiblesAttachees` sait déjà si le bouton porte un nœud (`suivreLAttache` est posé dessus). On l'**attend** au lieu de deviner une durée — borné à ~4 s, puis on demande le focus une seule fois, quand il existe. ⚠ Le retour de bande-annonce garde son comportement d'avant (une demande, un jeton honoré une fois) : ce correctif ne touche que l'entrée. 3 tests, dont un qui interdit le retour du `repeat(... 1 else 3)` — c'est lui qui nomme la cause.