it-swarm.com.de

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

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

An vielen Stellen, an denen ich einen console.log in meine main.js-Datei hinzufüge, erhalte ich folgende Fehlermeldung anstelle meiner schönen kleinen handgeschriebenen Nachrichten an mich: 

Synchrones XMLHttpRequest im Hauptthread wird aufgrund seiner nachteiligen Auswirkungen auf die Benutzererfahrung als veraltet eingestuft. Für weitere Hilfe http://xhr.spec.whatwg.org/

Welche Alternativen zu oder welche Wrapper für console.log kann ich meinem Code verwenden, um diesen Fehler nicht zu verursachen? 

Mache ich es falsch? 

337
Nathan Basanese

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

Teilweise HTML-Inhalt:

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

Es scheint zumindest in meinem Fall so zu sein, dass wenn Sie HTML-Inhalte über xhr zurückgeben, jQuery dazu veranlasst wird, dieses Skript abzurufen. Dieser Aufruf geschieht 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 einfach ein JSON-Objekt zurückgeben oder je nach Backend und Template das Laden Ihrer Skripte ändern. 

Sie können auch jQuery's getScript() verwenden, um relevante Skripts abzurufen. Hier ist eine Geige, es ist nur eine direkte Kopie des jQuery-Beispiels, aber es werden keine Warnungen angezeigt, wenn Skripts auf diese Weise geladen werden.

Beispiel

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

http://jsfiddle.net/49tkL0qd/

254
kroolk

Die Warnmeldung MUSS aufgrund einer XMLHttpRequest-Anforderung im Hauptthread sein, wobei das async-Flag auf false gesetzt ist.

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

Synchronous XMLHttpRequest außerhalb von Workern befindet sich im Prozess von von der Webplattform entfernt werden, da dies negative Auswirkungen auf .__ hat. die Erfahrung des Endbenutzers. (Dies ist ein langer Prozess, der viele Jahre dauert.) Entwickler dürfen beim asynchronen Argument nicht falsch übergeben, wenn der Die globale JavaScript-Umgebung ist eine Dokumentumgebung. Benutzeragenten Es wird dringend empfohlen, vor einer solchen Verwendung in Entwicklertools zu warnen und kann mit dem Auslösen einer InvalidAccessError-Ausnahme experimentieren, wenn es passiert.

Die zukünftige Richtung ist, nur XMLHttpRequests in Arbeitsthreads zuzulassen. Die Nachricht soll dazu eine Warnung sein.

67
PedanticDan

Ich war ebenfalls mit demselben Problem konfrontiert, konnte es jedoch 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 }),
});
56
Irfan Ashraf

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

28
Charlie

Manchmal ist es notwendig, ein Skript ajax zu laden, aber document ready zu verzögern, bis das Skript geladen ist.

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

Verwendungsbeispiel:

$.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), der Effekt ist jedoch synchron, wenn der Rest Ihres JavaScript nach document ready ausgeführt wird.

Dieses erweiterte Funktion wird normalerweise von einem dynamischen Skript verwendet Loader, die zusätzliches JavaScript laden möchten, z. B. jQuery-Plugins bevor das Ready-Ereignis eintreten kann, auch wenn das DOM möglicherweise .__ ist. bereit.

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 zu spät geladen wird, für den die Verzögerung erforderlich ist, wenn er sicher ausgeführt werden kann. 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 verwendet wird, jQuery.holdReady() nicht mehr enthält, schlägt der Code kurz nach dem Erscheinen dieser Warnung fehl.

15
Dem Pilafian

Um diese Warnung zu vermeiden, verwenden Sie nicht:

async: false

in einem Ihrer $ .ajax () - Aufrufe. Dies ist die einzige Funktion von XMLHttpRequest, die nicht mehr unterstützt wird.

Der Standardwert ist 

async: true

jQuery hat synchrones XMLHTTPRequest abgelehnt

13
Sonu K

@Webgr partielle Antwort hat mir tatsächlich beim Debuggen dieser Warnung geholfen @ Konsole log, schade, der andere Teil dieser Antwort brachte so viele Downvotes :(

Wie auch immer, ich habe herausgefunden, was in diesem Fall die Ursache dieser Warnung war:

  1. Verwenden Sie den Chrome-Browser> F12, um die DevTools zu laden
  2. Öffnen Sie das drawer Menü (in Chrome 3 vertikale Punkte oben rechts)
  3. Unter Console > check Log XMLHttpRequests Option
  4. Laden Sie Ihre Seite mit der Fehlermeldung erneut und beobachten Sie, was bei jeder Ajax-Anforderung im Konsolenprotokoll passiert.

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

Hoffe das hilft jemandem.

11
dev101

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 zur Verlinkung auf "jquery" in page.php verwenden, wird diese Benachrichtigung angezeigt. 

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

Ich bekomme eine solche Warnung in folgendem Fall:

1) Datei1, die <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script> enthält. 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 ist auch <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script> enthalten. Wenn dies der Fall war, bekam ich die Warnung. 

<script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script> wurde aus der externen PHP-Datei entfernt und funktioniert ohne Warnung.

Wie ich beim Laden der ersten Datei (file1) verstehe, lade ich jquery-1.10.2.js und da die Seite nicht neu lädt (sie sendet Daten an eine externe PHP-Datei mit jquery $.post), dann jquery-1.10.2.js weiterhin vorhanden. Also nicht mehr nötig, um es zu laden.

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

Genießen

4
Webgr

In einer MVC-Anwendung habe ich diese Warnung erhalten, weil ich ein Kendo-Fenster mit einer Methode geöffnet habe, die eine View () anstelle einer PartialView () zurückgegeben hat. Die Ansicht () hat versucht, alle Skripts der Seite erneut abzurufen. 

4
Misi

Und ich habe diese Ausnahme bekommen, weil ich ein can.js-Skript in ein anderes aufgenommen habe, z.

{{>anotherScript}}
4
Charles Merriam

Ich habe diese Ausnahmebedingung erhalten, wenn ich eine URL wie "example.com/files/text.txt" setze. Ich habe die URL in " http://example.com/files/text.txt " geändert, und diese Ausnahme verschwand.

4
Radren

Wie @Nycen habe ich auch diesen Fehler wegen eines Links zu Cloudfare erhalten. Meines war für das Select2 Plugin.

um es 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.

4
Rockwell Rice

In ZF2 passierte es mir ... Ich versuchte, den Modal-Inhalt zu laden, hatte aber vergessen, das Layout vorher zu deaktivieren.

So:

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

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

Laut Cloudflare "Diese App wird im März 2015 nicht mehr unterstützt". Ich stellte es ab und die Nachricht verschwand sofort.

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

Hinweis: Dies ist eine Kopie meiner Antwort in diesem Thread Warnung für synchrones XMLHttpRequest und <script> (Ich habe beide auf der Suche nach einer Lösung besucht)

3
Nycen

Das ist in meinem Fall gelöst.

JS

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

Diese Antwort wurde in diesen Link eingefügt

https://stackoverflow.com/questions/28322636/synchronous-xmlhttprequest-warning-and-script

3
Bagrat Zakaryan

Ich habe das mit den folgenden Schritten behoben:

  1. Überprüfen Sie Ihre CDN-Skripts und fügen Sie sie lokal hinzu.
  2. Verschieben Sie Ihre Skripteinschlüsse in den Kopfzeilenbereich.
2
mzonerz

Für mich bestand das Problem darin, dass ich in einer OK-Anforderung erwartete, dass die Ajax-Antwort eine gut formatierte HTML-Zeichenfolge wie eine Tabelle ist. In diesem Fall trat jedoch ein Problem mit der Anforderung auf dem Server auf. und gab daher den HTML-Code der Fehlerseite zurück (die irgendwo einen <script-Tag hatte. Ich habe die Ajax-Antwort in der Konsole protokolliert, und da wurde mir klar, dass es nicht das war, was ich erwartet hatte.

2
gthuo

In meinem speziellen Fall habe ich ein Rails-Partial ohne render layout: false gerendert, das das gesamte Layout einschließlich aller Skripts im <head>-Tag neu renderte. Durch Hinzufügen von render layout: false zur Controller-Aktion wurde das Problem behoben.

2
dps

Die im Jahr 2014 aufgeworfene Frage ist 2019, und ich denke, es ist gut, nach einer besseren Option zu suchen.

Sie können fetch api einfach in Javascript verwenden, wodurch Sie mehr Flexibilität erhalten.

siehe zum Beispiel diesen Code

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