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.

InformationsquelleAutor amit_saxena | 2014-01-23

6

Unten ist der Arbeits-code:
```
<script type="text/javascript">
        var heartbeat;
        var lastInterval;

        function clearTimers() {
            clearTimeout(heartbeat);
        }

        function getTime() {
            return (new Date()).getTime();
        }

        function intervalHeartbeat() {
            var now = getTime();
            var diff = now - lastInterval - 200;
            lastInterval = now;
            if(diff > 1000) { //don't trigger on small stutters less than 1000ms
                clearTimers();
            }
        }
        lastInterval = getTime();
        heartbeat = setInterval(intervalHeartbeat, 200);
```
Finden Sie weitere details hier: http://aawaara.com/post/74543339755/smallest-piece-of-code-thats-going-to-change-the-world
- Die Tatsache, dass dies überhaupt funktioniert (vorausgesetzt, ich nehme dein Wort, dass es in der Tat tut), bedeutet, dass javascript-Timer nicht ausgelöst wird, auf hintergrund-tabs oder während der browser minimiert ist. Also kann man da auch anrufen 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 Sie clearTimers(): Diese Browser weiterhin ausgeführt, JS-Timer/events/code sogar in hintergrund-tabs oder, wenn es minimiert wird.
- Es funktioniert für mich. Und ja, ich benutze das nur auf iOS-Geräten durch den Nachweis, dass die server-Seite.
- Für Chrome auf iOS dieser "Herzschlag" Ansatz scheint zu sein, die einzige funktionierende Lösung, wie visibilitychange nicht das Feuer auf iOS Chrome (ähnlich pageshow/pagehide nicht feuern).
InformationsquelleAutor amit_saxena
2

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 mit document.hidden oder document.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() auf visibilitychange, und fallen zurück auf die Benennung von auf pagehide 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
- Page visibility API ist schlecht (nicht so gut) browser-Unterstützung, und ich hatte zu verbringen Aufwand versuchen, damit es funktioniert in allen Browsern. Sie finden weitere details hier: aawaara.com/post/88310470252/...
- Nach upvoting diese Antwort, fand ich heraus, dass die visibilitychange Veranstaltungen leiden unter dem gleichen Problem in der iOS-Chrome als pageshow/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).
- Ich nehme wieder meinen Vorschlag zu verwenden setTimeout statt setInterval. 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). Ein setInterval Umsetzung scheint konsequent Feuer, bevor der lange timeout ausgelöst wird, das ist, was wir wollen.
InformationsquelleAutor Doin

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.