visibilitychange événement n'est pas déclenché lors de la commutation de programme/fenêtre avec ALT+TAB ou en cliquant dans la barre des tâches
Fondamentalement, le problème est avec le comportement de l'événement "visibilitychange".
Il est déclenché:
- Quand je suis passer à un autre onglet dans la fenêtre du navigateur.
- Quand je clique en réduire /restaurer les boutons de la fenêtre du navigateur.
(c'est ok)
Ce n'est pas déclenchée:
- Lorsque je passe à une autre fenêtre/programme à l'aide de ALT+TAB.
- Lorsque je passe à une autre fenêtre/programme en cliquant sur la barre des tâches.
(ce qui DEVRAIT déclencher, parce que, tout comme lors de la réduction, la visibilité de la fenêtre peut changer)
W3 Page Visibilité de la Documentation de l'API: http://www.w3.org/TR/page-visibility/
Il n'y a pas de définition de la page de "visibilité" sur ALT+TAB/programme de commutation dans la feuille de spécifications. J'imagine qu'il a quelque chose à faire entre l'OS et le Navigateur.
TESTÉ DANS
- Navigateurs:
Chrome 40.0.2214.115 m /Firefox 36.0.1 /Internet Explorer 11.0.9600.17107 - OS: Windows 8.1
Est-il une solution pour corriger ce comportement? La mise en œuvre est assez simple, j'écoute les "visibilitychange" de l'événement à l'aide de jQuery, puis dans son rappel, j'ai vérifier la valeur de document".visibilityState", mais le problème est que l'événement n'est pas de tir à la date prévue.
$(document).on('visibilitychange', function() {
if(document.visibilityState == 'hidden') {
//page is hidden
} else {
//page is visible
}
});
Cela peut être fait sans jQuery trop, mais le ALT+TAB et la barre des tâches commutateur de cacher/montrer un comportement attendu est toujours manquant:
if(document.addEventListener){
document.addEventListener("visibilitychange", function() {
//check for page visibility
});
}
J'ai aussi essayé le ifvisible.js module ( https://github.com/serkanyersen/ifvisible.js ), mais le comportement est le même.
ifvisible.on('blur', function() {
//page is hidden
});
ifvisible.on('focus', function() {
//page is visible
});
Je n'ai pas testé sur d'autres navigateurs, parce que si je ne peux pas le faire fonctionner dans google Chrome sur Windows, je n'ai vraiment pas de soins sur les autres navigateurs encore.
Toute aide ou suggestion est la remercie à l'avance.
Mise à JOUR
J'ai essayé à l'aide de différents fournisseurs préfixe pour le nom de l'événement (visibilitychange, webkitvisibilitychange, mozvisibilitychange, msvisibilitychange) mais encore l'événement n'est pas déclenché lorsque je passe à un autre programme dans la barre des tâches ou ALT+TAB, ou même si j'ouvre le menu démarrer dans windows avec la touche windows, qui couvre la totalité de l'écran.
Je peux reproduire exactement le même problème dans Chrome, Firefox et Internet Explorer.
Mise à JOUR #2
Voici un tour d'horizon post que j'ai écrit pour ce problème et une solution de contournement en pure javascript pour résoudre les problèmes rencontrés.
Mise à JOUR #3
Modifié pour inclure une copie de la source blog. (voir accepté de répondre)
hey, j'ai édité le lien, le post est maintenant sur: stereologics.wordpress.com/2015/04/02/...
OriginalL'auteur agbb | 2015-03-11
Vous devez vous connecter pour publier un commentaire.
Voici un tour d'horizon post que j'ai écrit pour ce problème et une solution de contournement en pure javascript pour résoudre les problèmes rencontrés.
Modifié pour inclure une copie de la source blog:
Dans n'importe quel type de javascript de l'application, nous développons il y a peut être une fonction ou tout changement dans l'application qui réagit en fonction de l'utilisateur actuel état de visibilité, ce qui pourrait être de mettre en pause la lecture d'une vidéo lorsque l'utilisateur ALT+Onglets d'une fenêtre différente, le suivi des statistiques sur la façon dont les utilisateurs interagissent avec notre application, combien de fois ne lui passer à un autre onglet, combien de temps faut-il pour revenir et un grand nombre d'améliorations qui peuvent profiter de ce genre d'API.
La Page de la Visibilité de l'API nous offre avec deux haut-niveau attributs: document.cachés (boolean) et document.visibilityState (qui peut être l'une de ces chaînes: “caché”, “visible”, “pré-rendu”, “déchargées”). Ce ne serait pas assez bon sans un événement, nous avons pu écouter, si, c'est pourquoi l'API fournit également la durée de visibilitychange événement.
Donc, voici un exemple de base sur la façon dont nous pourrions prendre des mesures sur une visibilité changement:
Nous avons pu également vérifier le document.visibilityState valeur.
Traitant des problèmes liés aux fournisseurs
George Berkeley par John Smibert
Certaines implémentations sur certains navigateurs encore besoin que les attributs ou même le nom de l'événement est préfixé fournisseur, cela signifie que nous pouvons être à l'écoute de la msvisibilitychange de l'événement ou de vérifier le document.webkitHidden ou le document.mozHidden attributs. Pour ce faire, nous devons vérifier si tout préfixé fournisseur attribut est défini, et une fois que nous savons qui est celui utilisé dans le navigateur actuel (seulement si il existe le besoin d'un préfixe), nous pouvons nommer l'événement et attributs correctement.
Voici un exemple d'approche sur la façon de gérer ces préfixes:
D'autres questions
Il y a une question difficile, autour de la Page “Visibilité” définition: comment faire pour déterminer si l'application est visible ou pas, si la fenêtre est perdu par l'autre fenêtre, mais pas la réelle visibilité sur l'écran? a propos des différentes formes de visibilité perdu, comme ALT+TAB, WIN/MAC touche (menu démarrer /tableau de bord), la barre des tâches/dock actions, WIN+L (écran de verrouillage), fenêtre, réduire, fermer la fenêtre, onglet de commutation. Quel est le comportement sur les appareils mobiles?
Il existe de nombreuses façons dans lequel on peut perdre ou gagner de la visibilité et beaucoup d'interactions possibles entre le navigateur et le système d'exploitation, donc je ne pense pas qu'il y a une véritable et complète “visible à la page” définition du W3C spec. C'est la définition que nous obtenons pour le document.attribut caché:
ATTRIBUT CACHÉ
Sur l'obtention, l'attribut caché DOIT retourner true si le Document contenait par le haut niveau de contexte de navigation (racine de la fenêtre dans le navigateur de la fenêtre d'affichage) [HTML5] n'est pas visible à tous. L'attribut DOIT retourner false si le Document contient de par le haut niveau de contexte de navigation est au moins partiellement visible sur au moins un écran.
Si la defaultView le Document est nulle, sur l'obtention, l'attribut caché DOIT retourner true.
Pour accueillir les outils d'accessibilité qui sont généralement en plein écran, mais encore de montrer une vue de la page, le cas échéant, cet attribut PEUT retourner false lorsque l'Agent Utilisateur n'est pas réduite, mais est entièrement caché par d'autres applications.
J'ai trouvé quelques incohérences lorsque l'événement est effectivement tiré, par exemple (Chrome 41.0.2272.101 m, sur Windows 8.1) l'événement n'est pas déclenché quand j'ai ALT+TAB sur une autre fenêtre/programme ni quand je les touches ALT+TAB pour revenir, mais il EST déclenché si je CTRL+TAB et CTRL+MAJ+TAB pour basculer entre les onglets du navigateur. Il est également déclenché quand je clique sur le bouton réduire, mais ce n'est pas déclenché si la fenêtre n'est pas maximisée et que je clique sur ma fenêtre de l'éditeur qui est derrière la fenêtre du navigateur. Ainsi, le comportement de cette API et ses différentes implémentations sont encore obscures.
Une solution de contournement pour ce, qui est de compenser en prenant avantage de la meilleure mise en œuvre focus et blur événements, et de faire une approche personnalisée pour l'ensemble de la Page “Visibilité” de l'émission à l'aide d'un indicateur interne pour empêcher les exécutions multiples, c'est ce que je suis venu avec:
Je souhaite la bienvenue à tout commentaire sur cette solution de contournement. Quelques autres grandes sources d'idées sur ce sujet:
En utilisant la Page de la Visibilité de l'API
À l'aide de Matériel PC de manière plus efficace en HTML5: les Nouvelles de la Performance Web Api, Partie 2
Introduction à la Page de la Visibilité de l'API
Conclusion
Les technologies du web sont en constante évolution, nous sommes toujours à la récupération à partir d'un sombre passé où des tables où le balisage roi, où la sémantique n'a pas d'importance, et ils n'étaient pas de normes sur la manière dont un navigateur devrait afficher une page.
Il est important de nous appuyer sur ces nouvelles normes de l'avant, mais parfois, nos exigences en matière de développement nous faire encore besoin de s'adapter à ce genre de transitions, de la manipulation d'un fournisseur de préfixes, des tests sur différents navigateurs et différents logiciels libres ou dépendent des outils de tiers, d'identifier ces différences.
Nous ne pouvons qu'espérer pour un avenir où les spécifications du W3C sont strictement révisée, strictement mis en œuvre par le navigateur développeur équipes, et peut-être qu'un jour nous aurons un standard commun pour nous tous de travailler avec.
Comme pour la Page de la Visibilité de l'API faut juste laisser un peu citer George Berkeley et de dire que:
“être visible” est perçu.
désolé, j'ai corrigé le lien, le poste est stereologics.wordpress.com/2015/04/02/...
comme il l'a dit, vous devez donner la réponse exacte à la place de la liaison. Liens de mourir (comme c'est arrivé une fois, et continuera de se produire
Dans le cas où le lien ne meurent: web.archive.org/web/20180912061844/https://...
Merci, modifié pour inclure une copie de la source de blog trop.
OriginalL'auteur agbb
Une solution de travail est proposé est décrit ici: https://stackoverflow.com/a/9502074/698168. Il utilise une combinaison de la W3C Page de la Visibilité de l'API, flou/focus et les mouvements de la souris. Caché pages HTML liées à Alt+Tab sont identifiés de façon probabiliste (c'est à dire vous ne pouvez pas déterminer si votre page est cachée avec 100% de précision).
OriginalL'auteur Julien Kronegg
Il y a une solution très simple à ce que j'ai rencontré.
Vous avez juste besoin de passer à false pour le useCapture tandis que d'attacher un écouteur d'événement pour le document. Fonctionne comme un charme!
Je l'ai eu avec de faux et cela ne fonctionne toujours pas dans les deux dernières Chrome (56.0) ou le dernier Firefox (52.0)
Le faux est la valeur par défaut, donc cela ne changera rien.
OriginalL'auteur vishal kokate
nous pouvons faire comme ci-dessous lors de la commutation entre les onglets et la commutation entre les applications
OriginalL'auteur Anjaneyulu Batta