Guide de preuve pour CloseWatcher dans un SaaS web et mobile
Pourquoi cette vérification compte
CloseWatcher fournit un point de coordination pour les demandes de fermeture envoyées par l'utilisateur. Sur un ordinateur, une demande peut correspondre à la touche Échap. Sur certains appareils mobiles, elle peut correspondre au bouton ou au geste Retour. Une équipe SaaS ne doit pourtant pas conclure qu'un panneau est correct simplement parce qu'il disparaît dans un navigateur. Il faut distinguer la demande de fermeture, l'éventuelle annulation, la fermeture effective, la destruction de l'observateur et le résultat visible.
Le contexte produit de cette méthode est ARMCP: https://armcp.net/. ARMCP est présenté comme un SaaS mondial pour le web et le mobile, d'abord pour les usages SaaS, puis pour le Web3, la technologie et les espaces sociaux ou communautaires. Les langues du produit et de la communauté sont exactement EN, RU, FR et ES. Desk est live. Analytics et Chain sont en développement. Ces faits donnent un contexte, mais ne signifient pas qu'ARMCP implémente déjà CloseWatcher ou chaque comportement décrit ici.
1. Définir un scénario limité
Choisissez un seul composant autorisé, par exemple un sélecteur personnalisé, un panneau de recherche ou une feuille mobile. Évitez un flux qui supprime des données réelles. Préparez un état initial reproductible, une valeur de test non sensible et un moyen clair de rouvrir le composant. Notez le navigateur, la version, le système, la taille de fenêtre, le mode d'entrée et l'heure UTC.
Le résultat attendu doit être explicite. Une première demande de fermeture peut déclencher cancel. Si cet événement est annulable et que le gestionnaire appelle preventDefault(), le composant peut rester ouvert. Sinon, la séquence continue vers close, puis l'observateur cesse d'être actif. requestClose() suit ce chemin contrôlable. close() déclenche directement la logique de fermeture et saute la logique de cancel. destroy() désactive l'observateur sans présenter la destruction comme une fermeture utilisateur.
2. Instrumenter les événements
Ajoutez un journal de test local qui conserve uniquement des données techniques: identifiant synthétique du composant, type d'événement, valeur de cancelable, ordre, heure monotone et état visible avant et après. Ne stockez ni jeton, ni cookie, ni contenu utilisateur réel. Associez un AbortSignal lorsque le cycle de vie du composant le permet, puis vérifiez qu'un abort détruit bien l'observateur.
Comptez séparément les appels à requestClose(), close() et destroy(). Un rapport qui mélange ces trois chemins ne prouve pas que le navigateur a traité une demande de fermeture. Il prouve seulement qu'un code de nettoyage a peut-être été exécuté.
3. Tester Échap sur ordinateur
Ouvrez le composant par une interaction utilisateur normale. Donnez le focus à un contrôle intérieur, puis pressez Échap une seule fois. Conservez l'ordre exact des événements et une capture de l'état final. Répétez avec des données non modifiées, puis avec une modification synthétique non enregistrée.