JavaScript console.log verursacht Fehler: "Synchrones XMLHttpRequest im Hauptthread ist veraltet ..."

Ich habe der Konsole Protokolle hinzugefügt, um den Status verschiedener Variablen zu überprüfen, ohne den Firefox-Debugger zu verwenden.

An vielen Stellen, an denen ich ein console.login meine main.jsDatei einfüge, erhalte ich jedoch anstelle meiner kleinen handgeschriebenen Nachrichten den folgenden Fehler:

Die synchrone XMLHttpRequest im Hauptthread ist aufgrund ihrer nachteiligen Auswirkungen auf die Benutzererfahrung veraltet. Weitere Hilfe unter http://xhr.spec.whatwg.org/

Welche Alternativen oder Wrapper console.logkann ich zu meiner Codeverwendung hinzufügen, die diesen Fehler nicht verursachen?

Mache ich "es falsch"?

Dies passierte mir, als ich faul war und ein Skript-Tag als Teil des zurückgegebenen Inhalts einfügte. So wie:

Teilweiser HTML-Inhalt:

<div> 
 SOME CONTENT HERE
</div>
<script src="/scripts/script.js"></script> 

Zumindest in meinem Fall scheint es so zu sein, dass jQuery einen Aufruf zum Abrufen dieses Skripts veranlasst, wenn Sie HTML-Inhalte wie diesen über xhr zurückgeben. Dieser Aufruf erfolgt mit einem asynchronen Flag false, da davon ausgegangen wird, dass Sie das Skript zum weiteren Laden benötigen.

In Situationen wie dieser ist es besser, wenn Sie sich ein verbindliches Framework ansehen und nur ein JSON-Objekt zurückgeben. Abhängig von Ihrem Backend und Ihren Vorlagen können Sie die Art und Weise ändern, in der Sie Ihre Skripte laden.

Sie können auch jQuery's verwendengetScript() , um relevante Skripte abzurufen. Hier ist eine Geige: Es ist nur eine direkte Kopie des jQuery-Beispiels, aber ich sehe keine Warnungen, wenn Skripte auf diese Weise geladen werden.

Beispiel

<script>
var url = "/scripts/script.js";
$.getScript(url);
</script>

http://jsfiddle.net/49tkL0qd/

Die Warnmeldung kann auf eine XMLHttpRequest-Anforderung im Hauptthread zurückzuführen sein, bei der das asynchrone Flag auf false gesetzt ist.

https://xhr.spec.whatwg.org/#synchronous-flag :

Die synchrone XMLHttpRequest außerhalb der Mitarbeiter wird gerade von der Webplattform entfernt, da sie sich nachteilig auf die Benutzererfahrung auswirkt. (Dies ist ein langer Prozess, der viele Jahre dauert.) Entwickler dürfen für das asynchrone Argument nicht false übergeben, wenn die globale JavaScript-Umgebung eine Dokumentumgebung ist. Benutzeragenten werden dringend gebeten, vor einer solchen Verwendung in Entwicklertools zu warnen, und können versuchen, eine InvalidAccessError-Ausnahme auszulösen, wenn sie auftritt.

Die zukünftige Richtung besteht darin, XMLHttpRequests nur in Arbeitsthreads zuzulassen. Die Nachricht soll eine entsprechende Warnung sein.

Ich hatte auch das gleiche Problem, konnte es aber beheben, indem ich async: true setzte. Ich weiß, dass es standardmäßig wahr ist, aber es funktioniert, wenn ich es explizit schreibe

$.ajax({
   async: true,   // this will solve the problem
   type: "POST",
   url: "/Page/Method",
   contentType: "application/json",
   data: JSON.stringify({ ParameterName: paramValue }),
});

Der Live-Debugger von Visual Studio 2015/2017 fügt Code ein, der den veralteten Aufruf enthält.

Manchmal ist es notwendig, ein Skript zu laden, das Dokument jedoch erst nach dem Laden des Skripts zu warten.

jQuery unterstützt dies mit der holdReady()Funktion.

Anwendungsbeispiel:

$.holdReady(true);                              //set hold
function releaseHold() { $.holdReady(false); }  //callback to release hold
$.getScript('script.js', releaseHold);          //load script then release hold

Das eigentliche Laden des Skripts ist asynchron ( kein Fehler ), aber der Effekt ist synchron, wenn der Rest Ihres JavaScript ausgeführt wird, nachdem das Dokument fertig ist .

Diese erweiterte Funktion wird normalerweise von dynamischen Skriptladern verwendet, die zusätzliches JavaScript wie jQuery-Plugins laden möchten, bevor das Ereignis ready zugelassen wird, obwohl das DOM möglicherweise bereit ist.

Dokumentation:
https://api.jquery.com/jquery.holdready

UPDATE 7. Januar 2019

Von JQMIGRATE :

jQuery.holdReady () ist veraltet

Ursache: Die jQuery.holdReady()Methode wurde aufgrund ihrer nachteiligen Auswirkungen auf die globale Leistung der Seite nicht mehr unterstützt. Diese Methode kann verhindern, dass der gesamte Code auf der Seite für längere Zeit initialisiert wird.

Lösung: Schreiben Sie die Seite neu, sodass nicht alle jQuery-fähigen Handler verzögert werden müssen. Dies kann beispielsweise dadurch erreicht werden, dass nur der Code verspätet geladen wird, für den die Verzögerung erforderlich ist, wenn die Ausführung sicher ist. Aufgrund der Komplexität dieser Methode versucht jQuery Migrate nicht, die Funktionalität zu füllen. Wenn die zugrunde liegende Version von jQuery, die mit jQuery Migrate jQuery.holdReady()verwendet wird, den Code nicht mehr enthält, schlägt der Code kurz nach Erscheinen dieser Warnung fehl.

Verwenden Sie nicht, um diese Warnung zu vermeiden:

async: false

in einem Ihrer $ .ajax () -Aufrufe. Dies ist die einzige Funktion von XMLHttpRequest, die veraltet ist.

Der Standardwert ist

async: true

jQuery hat synchrones XMLHTTPRequest abgelehnt

Die Teilantwort von @Webgr hat mir tatsächlich geholfen, dieses @ Konsolenprotokoll zu debuggen. Schade, dass der andere Teil dieser Antwort so viele Abstimmungen gebracht hat :(

Wie auch immer, hier ist, wie ich herausgefunden habe, was die Ursache für diese Warnung in meinem Fall war:

1. Verwenden Sie Chrome Browser> Drücken Sie F12, um DevTools zu starten
2. Öffnen Sie das Schubladenmenü (in Chrome 3 vertikale Punkte oben rechts).
3. Aktivieren Sie unter Konsole die Option XMLHttpRequests protokollieren
4. Laden Sie Ihre Seite, auf der der Fehler aufgetreten ist, neu und beobachten Sie, was bei jeder Ajax-Anforderung im Konsolenprotokoll passiert.

In meinem Fall lud ein anderes Plugin nach jedem Ajax-Aufruf 2 .js-Bibliotheken , die absolut weder erforderlich noch notwendig waren. Durch Deaktivieren des Rogue-Plugins wurde die Warnung aus dem Protokoll entfernt. Ab diesem Zeitpunkt können Sie entweder versuchen, das Problem selbst zu beheben (z. B. das Laden der Skripte auf bestimmte Seiten oder Ereignisse zu beschränken - dies ist viel zu spezifisch für eine Antwort hier) oder sich an den Plugin-Entwickler eines Drittanbieters wenden, um es zu lösen.

Hoffe das hilft jemandem.

Ich habe mir die Antworten alle beeindruckend angesehen. Ich denke, er sollte den Code bereitstellen, der ihm ein Problem bereitet. Wenn Sie im folgenden Beispiel ein Skript zum Verknüpfen mit jquery in page.php haben, erhalten Sie diesen Hinweis.

$().ready(function () {
    $.ajax({url: "page.php",
        type: 'GET',
        success: function (result) {
        $("#page").html(result);
   }});
 });

Ich erhalte eine solche Warnung in folgendem Fall:

1) Datei1, die enthält <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>. Seite hat Eingabefelder. Ich gebe einen Wert in das Eingabefeld ein und klicke auf die Schaltfläche. Jquery sendet Eingaben an eine externe PHP-Datei.

2) externe PHP-Datei enthält auch JQuery und in der externen PHP-Datei habe ich auch enthalten <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>. Denn wenn das so ist, habe ich die Warnung bekommen.

Aus <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>externer PHP-Datei entfernt und funktioniert ohne Warnung.

Wie ich beim Laden der ersten Datei (Datei1) verstehe, lade ich jquery-1.10.2.jsund da die Seite nicht neu geladen wird (sie sendet Daten mit jquery an eine externe PHP-Datei $.post), jquery-1.10.2.jsbleibt sie bestehen. Also nicht nochmal zum laden nötig.

Ich habe diese Ausnahme erhalten, als ich eine URL in einer Abfrage wie "example.com/files/text.txt" festgelegt habe. Ich habe die URL in " http://example.com/files/text.txt " geändert und diese Ausnahme ist verschwunden.

Und ich habe diese Ausnahme erhalten, weil ich ein can.js-Skript in ein anderes eingefügt habe, z.

{{>anotherScript}}

In einer MVC-Anwendung wurde diese Warnung angezeigt, weil ich ein Kendo-Fenster mit einer Methode öffnete, die eine View () anstelle einer PartialView () zurückgab. The View () hat versucht, alle Skripte der Seite erneut abzurufen.

Es passierte mir in ZF2. Ich habe versucht, den Modal-Inhalt zu laden, aber ich habe vergessen, das Layout zuvor zu deaktivieren.

Damit:

$viewModel = new ViewModel();
$viewModel->setTerminal(true);
return $viewModel;

Wie bei @Nycen habe ich auch diesen Fehler aufgrund eines Links zu Cloudfare erhalten. Meins war für das Select2- Plugin.

Um das Problem zu beheben, habe ich es gerade entfernt

 src="//cdnjs.cloudflare.com/ajax/libs/select2/4.0.0/js/select2.min.js"

und der Fehler ging weg.

1. In Chrome press F12
2. Entwicklungswerkzeuge-> drücken F1.
3. Siehe Einstellungen-> Allgemein-> Darstellung: "Don't show chrome Data Saver warning"- Aktivieren Sie dieses Kontrollkästchen.
4. Siehe Einstellungen-> Allgemein-> Konsole: "Log XMLHTTPRequest"- Aktivieren Sie auch dieses Kontrollkästchen.

Genießen

Dies ist in meinem Fall gelöst.

JS

$.ajaxPrefilter(function( options, original_Options, jqXHR ) {
    options.async = true;
});

Diese Antwort wurde in diesen Link eingefügt

/programming/28322636/synchronous-xmlhttprequest-warning-and-script

In meinem Fall wurde dies durch das Flexie- Skript verursacht, das Teil der von Cloudflare angebotenen App "CDNJS Selections" war .

Laut Cloudflare "wird diese App im März 2015 nicht mehr unterstützt". Ich schaltete es aus und die Nachricht verschwand sofort.

Sie können auf die Apps zugreifen, indem Sie https://www.cloudflare.com/a/cloudflare-apps/yourdomain.com besuchen

NB: Dies ist eine Kopie meiner Antwort auf diesen Thread Synchronous XMLHttpRequest-Warnung und <script> (ich habe beide besucht, als ich nach einer Lösung gesucht habe)

Ich habe dies mit den folgenden Schritten behoben:

1. Überprüfen Sie Ihre CDN-Skripte und fügen Sie sie lokal hinzu.
2. Verschieben Sie Ihre Skripte in den Header-Bereich.

In meinem speziellen Fall habe ich einen Rails-Teil gerendert, ohne render layout: falseden das gesamte Layout einschließlich aller Skripte im <head>Tag neu gerendert wurde . Das Hinzufügen render layout: falsezur Controller-Aktion hat das Problem behoben.

Für mich bestand das Problem darin, dass ich bei einer OK-Anfrage erwartet hatte, dass die Ajax-Antwort eine gut formatierte HTML-Zeichenfolge wie eine Tabelle ist. In diesem Fall trat jedoch ein Problem mit der Anfrage auf, die auf eine Fehlerseite umleitete. und gab daher den HTML-Code der Fehlerseite zurück (die <scriptirgendwo ein Tag hatte. Ich habe die Ajax-Antwort auf der Konsole protokolliert und festgestellt, dass dies nicht das war, was ich erwartet hatte, und dann mein Debugging durchgeführt.

Die Frage wurde 2014 und 2019 gestellt. Ich denke, es ist gut, nach einer besseren Option zu suchen.

Sie können einfach fetchAPI in Javascript verwenden, um mehr Flexibilität zu erhalten.

Siehe zum Beispiel diesen Code

fetch('./api/some.json')
    .then((response) => {
        response.json().then((data) => { 
            ... 
        });
    })
    .catch((err) => { ... });