pagehide und pageshow-events funktionieren nicht wie erwartet auf ios chrome
Apple-Dokumentation listet unten die verfügbaren iOS-browser-Veranstaltungen finden Sie hier:
https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html
den 'pagehide' und 'pageshow' Ereignisse scheinen zu funktionieren, auf safari, aber chrome funktioniert es nur auf Seite be-und entladen. Es funktioniert nicht auf:
1) Drücken Sie die home-Taste, D. H. das senden von chrome in den hintergrund
2) Wechsel der tabs
Unten ist ein kleines javascript-snippet, das Sie verwenden können, um es zu überprüfen:
<script type="text/javascript">
window.addEventListener("pageshow", function(evt){
alert('show');
}, false);
window.addEventListener("pagehide", function(evt){
alert('hide');
}, false);
</script>
Was kann ich tun, um zu erkennen, ob chrome gesendet wurde, in den hintergrund oder nicht. Ich muss klar eine setTimeout-timer so schnell wie chrome ist wieder in den Vordergrund zu stellen. Irgendwelche workarounds?
- Ich glaube nicht, dass Sie verstehen, was 'pageshow' und 'pagehide' sind gemeint für. Sie passieren die (a) auf load/unload, und (b) auf änderung, ob die Seite die aktuelle Seite im browser Geschichte, Caches (D. H. wenn Sie Weg zu navigieren, oder Sie zurück zu der Seite). Sie haben NICHTS damit ZU TUN, ob das Browserfenster SICHTBAR ist. Sie sind nicht dazu da, um das Feuer in Ihren Fällen (1) und (2).
- auch wenn ich Ihr Wort für es (obwohl ein link zur Dokumentation helfen), warum ist das Verhalten anders als Safari? Safari feuert die Ereignisse in den Szenarien, die ich beschrieben. Mindestens einer von Ihnen ist buggy.
- Vielleicht Minimierung der Safari unter iOS tatsächlich stellt die Seite im Verlauf, cache und schließt es (wie die Navigation entfernt würde) sparen Sie CPU und/oder RAM)? Trotzdem, einige Hinweise: html.spec.whatwg.org/multipage/indices.html#event-pagehide developer.mozilla.org/en-US/docs/Web/Events/pagehide inkling.com/read/javascript-definitive-guide-david-flanagan-6th/... ; ...und der apple link, den Sie klar, dass pagehide/zeigen, sind bevorzugt Ersatz für die (nicht-visuelle) unload/load-Ereignissen.
- Diese Seite beschreibt im detail das Grundprinzip hinter dem pageshow - /ausblenden von Ereignissen: developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching
- Zumindest einen dieser Browser zeigt falsch (inkonsistent w.r.t-web-Entwicklung) Verhalten, und erfordert daher Besondere Behandlung.
- Gut möglicherweise. Alle Browser unterscheiden sich von einander in mancher Hinsicht. Aber ich spekulieren, dass es ist, was ich schon angedeutet: Dass auf den iOS Geräten Safari ist das "einfrieren" seine öffnen Webseite in den cache, wenn es minimiert ist oder der Schalter Registerkarten, speichern beschränkt RAM & CPU-Ressourcen auf diesen Geräten. Dies hat den Effekt (richtig) auslösen pageshow - /ausblenden. In der Erwägung, dass Chrome ist wahrscheinlich genauso Verhalten sich Mehr wie ein desktop-browser und verlassen Sie die Seiten offen und läuft... oder zumindest, nicht tun, die full-schließen-und-cache, würde die trigger-Ereignisse. Beides ist nicht unbedingt falsch. Was bedeutet desktop-Safari machen?
- >> "Was hat der desktop-Safari zu tun?" Kann nicht bestätigen, dass - ich benutze linux. Die Frage ist spezifisch für iOS-Geräte.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Unten ist der Arbeits-code:
Finden Sie weitere details hier: http://aawaara.com/post/74543339755/smallest-piece-of-code-thats-going-to-change-the-world
clearTimers()
früher, als die browser-Registerkarte gesendet wird, um den hintergrund und nicht dann, wenn es wieder in den Vordergrund, wenn Sie erkennen können, dass. Auch die (ich nehme an, Sie erkennen,?), auf jedem desktop-browser, den obigen code wird NIE rufen SieclearTimers()
: Diese Browser weiterhin ausgeführt, JS-Timer/events/code sogar in hintergrund-tabs oder, wenn es minimiert wird.visibilitychange
nicht das Feuer auf iOS Chrome (ähnlichpageshow/pagehide
nicht feuern).Pagehide und pageshow sind nicht die Ereignisse, die Sie brauchen für das, was Sie versuchen zu erreichen.
Verwenden Sie stattdessen die
visibilitychange
Veranstaltung in Kombination mitdocument.hidden
oderdocument.visibilitystate
, das sollte genau das tun, was Sie wollen.Diese werden nur auf unterstützten Browsern, die sich bisher Chrome, Safari (noch) nicht. Also um sicher zu sein, ich würde Sie anrufen
clearTimers()
aufvisibilitychange
, und fallen zurück auf die Benennung von aufpagehide
nur, wenn das Dokument.visibilitystate ist nicht definiert.Finden Sie unter:
MDN: visibilitychange Veranstaltung
MDN: Mit der Page-Visibility-API
Die Sichtbarkeit der Seite - W3C-Empfehlung, Oktober 2013
visibilitychange
Veranstaltungen leiden unter dem gleichen Problem in der iOS-Chrome alspageshow/pagehide
Veranstaltungen: KEINE EREIGNIS AUSGELÖST WIRD, auf iOS Chrome auf z.B. home-Taste drücken, oder deeplinken in einer app/store. Amit ' s Herzschlag Lösung, die sich auf Timer spannen zu 1000ms in hintergrund-tabs scheint ein guter workaround. Würde ich persönlich verwenden Sie eine timeout-über Intervall (Intervalle haben den zusätzlichen Aufwand benötigen, werden gelöscht vs. setTimeout callback-Funktion kann eine Bedingung, die entweder löscht die redirectTimer oder legt Sie eine neue timeout-Wert aufrufen, sich wieder).setTimeout
stattsetInterval
. Während der Testphase von mein setTimeout Umsetzung auf iOS, Chrome, nachdem Sie kommen zurück auf die Registerkarte meine 100ms 'heartbeat' timeout würden oft nur ausgelöst, nachdem die 2000ms-timer, dass ich kündigen wollte in der Herzschlag-Rückruf (in der Regel etwa 20-70ms zu spät). EinsetInterval
Umsetzung scheint konsequent Feuer, bevor der lange timeout ausgelöst wird, das ist, was wir wollen.