JavaScript console.log provoca un errore: "XMLHttpRequest sincrono sul thread principale è obsoleto ..."

Ho aggiunto i log alla console per verificare lo stato di diverse variabili senza utilizzare il debugger di Firefox.

Tuttavia, in molti punti in cui aggiungo un file console.lognel mio main.jsfile, ricevo il seguente errore invece dei miei adorabili messaggi scritti a mano:

XMLHttpRequest sincrono sul thread principale è obsoleto a causa dei suoi effetti dannosi per l'esperienza dell'utente finale. Per ulteriori informazioni http://xhr.spec.whatwg.org/

Quali alternative o wrapper console.logposso aggiungere al mio uso del codice che non causerà questo errore?

Sto "sbagliando"?

Questo è successo a me quando ero pigro e includevo un tag di script come parte del contenuto che veniva restituito. Come tale:

Contenuto HTML parziale:

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

Sembra, almeno nel mio caso, che se si restituisce un contenuto HTML simile tramite xhr, si farà in modo che jQuery effettui una chiamata per ottenere quello script. Tale chiamata si verifica con un flag asincrono falso poiché presuppone che sia necessario lo script per continuare il caricamento.

In situazioni come questa, saresti meglio servito guardando in un quadro vincolante di qualche tipo e semplicemente restituendo un oggetto JSON, o in base al tuo back-end e al modello potresti cambiare il modo in cui carichi i tuoi script.

Puoi anche usare jQuerygetScript() per acquisire script rilevanti. Ecco un violino, è solo una copia semplice dell'esempio jQuery, ma non vedo alcun avviso lanciato quando gli script vengono caricati in quel modo.

Esempio

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

http://jsfiddle.net/49tkL0qd/

Il messaggio di avviso PUO 'ESSERE dovuto a una richiesta XMLHttpRequest all'interno del thread principale con il flag asincrono impostato su false.

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

XMLHttpRequest sincrono al di fuori dei lavoratori è in procinto di essere rimosso dalla piattaforma Web in quanto ha effetti dannosi per l'esperienza dell'utente finale. (Questo è un lungo processo che richiede molti anni.) Gli sviluppatori non devono passare false per l'argomento asincrono quando l'ambiente globale JavaScript è un ambiente documentale. Gli interpreti sono caldamente invitati ad avvertire di tale utilizzo negli strumenti di sviluppo e possono provare a lanciare un'eccezione InvalidAccessError quando si verifica.

La direzione futura è consentire solo XMLHttpRequests nei thread di lavoro. Il messaggio vuole essere un avvertimento in tal senso.

Stavo anche affrontando lo stesso problema, ma sono riuscito a risolverlo mettendo asincrono: vero. So che è vero per impostazione predefinita, ma funziona quando lo scrivo esplicitamente

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

Il debugger live di Visual Studio 2015/2017 sta iniettando il codice che contiene la chiamata obsoleta.

A volte è necessario ajax caricare uno script ma ritardare il documento pronto fino a quando non viene caricato lo script.

jQuery supporta questo con la holdReady()funzione.

Esempio di utilizzo:

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

Il caricamento dello script effettivo è asincrono ( nessun errore ), ma l'effetto è sincrono se il resto del JavaScript viene eseguito dopo che il documento è pronto .

Questa funzionalità avanzata viene in genere utilizzata dai caricatori di script dinamici che desiderano caricare JavaScript aggiuntivo come plug-in jQuery prima di consentire che si verifichi l'evento ready, anche se il DOM potrebbe essere pronto.

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

AGGIORNAMENTO 7 gennaio 2019

Da JQMIGRATE :

jQuery.holdReady () è obsoleto

Causa: il jQuery.holdReady()metodo è stato deprecato a causa del suo effetto dannoso sulle prestazioni globali della pagina. Questo metodo può impedire l'inizializzazione di tutto il codice della pagina per lunghi periodi di tempo.

Soluzione: riscrivere la pagina in modo che non richieda il ritardo di tutti i gestori pronti per jQuery. Ciò potrebbe essere realizzato, ad esempio, caricando in ritardo solo il codice che richiede il ritardo quando è sicuro eseguirlo. A causa della complessità di questo metodo, jQuery Migrate non tenta di riempire la funzionalità. Se la versione sottostante di jQuery utilizzata con jQuery Migrate non contiene più jQuery.holdReady()il codice fallirà poco dopo la visualizzazione di questo avviso.

Per evitare questo avviso, non utilizzare:

async: false

in una qualsiasi delle tue chiamate $ .ajax (). Questa è l'unica caratteristica di XMLHttpRequest che è obsoleta.

L'impostazione predefinita è

async: true

jQuery ha deprecato XMLHTTPRequest sincrono

La risposta parziale di @Webgr in realtà mi ha aiutato a eseguire il debug di questo avviso @ log della console, peccato che l'altra parte di quella risposta abbia portato così tanti downgrade :(

Ad ogni modo, ecco come ho scoperto qual è stata la causa di questo avviso nel mio caso:

1. Usa Chrome Browser> Premi F12 per portare DevTools
2. Apri il menu del cassetto (in Chrome 3 punti verticali in alto a destra)
3. Sotto Console > seleziona l' opzione Registra XMLHttpRequests
4. Ricarica la tua pagina che ti stava dando l'errore e osserva cosa succede su ogni richiesta Ajax nel registro della console.

Nel mio caso, un altro plugin stava caricando 2 librerie .js dopo ogni chiamata ajax, che non erano assolutamente necessarie né necessarie. La disabilitazione del plug-in canaglia ha rimosso l'avviso dal registro. Da quel momento, puoi provare a risolvere il problema da solo (ad esempio limitare il caricamento degli script su determinate pagine o eventi - questo è troppo specifico per una risposta qui) o contattare lo sviluppatore di plugin di terze parti per risolverlo.

Spero che questo aiuti qualcuno.

Ho visto le risposte tutte impressionanti. Penso che dovrebbe fornire il codice che gli sta causando un problema. Dato l'esempio seguente, se hai uno script da collegare a jquery in page.php, ricevi questo avviso.

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

Ricevo tale avviso nel seguente caso:

1) file1 che contiene <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>. La pagina ha campi di input. Inserisco un valore nel campo di inserimento e faccio clic sul pulsante. Jquery invia input a un file php esterno.

2) il file php esterno contiene anche jquery e nel file php esterno ho anche incluso <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>. Perché se questo avessi ricevuto l'avvertimento.

Rimosso <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>dal file php esterno e funziona senza preavviso.

Come ho capito sul caricamento del primo file (file1), carico jquery-1.10.2.jse poiché la pagina non si ricarica (invia i dati al file php esterno utilizzando jquery $.post), quindi jquery-1.10.2.jscontinua ad esistere. Quindi non è necessario nuovamente caricarlo.

Ho ricevuto questa eccezione quando ho impostato l'URL in una query come "esempio.com/files/text.txt". Ho cambiato l'URL in " http://example.com/files/text.txt " e questa eccezione è scomparsa.

E ho ottenuto questa eccezione per l'inclusione di uno script can.js all'interno di un altro, ad es.

{{>anotherScript}}

In un'applicazione MVC, ho ricevuto questo avviso perché stavo aprendo una finestra di Kendo con un metodo che restituiva un View (), anziché un PartialView (). Il View () stava provando a recuperare nuovamente tutti gli script della pagina.

Mi stava succedendo in ZF2. Stavo provando a caricare il contenuto modale ma prima ho dimenticato di disabilitare il layout.

Così:

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

Come @Nycen ho anche avuto questo errore a causa di un link a Cloudfare. Il mio era per il plugin Select2 .

per ripararlo ho appena rimosso

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

e l'errore è andato via.

1. In Chrome, press F12
2. Sviluppo di strumenti-> stampa F1.
3. Vedi impostazioni-> generale-> Aspetto: "Don't show chrome Data Saver warning"- imposta questa casella di controllo.
4. Vedi impostazioni-> generale-> Console: "Log XMLHTTPRequest"- imposta anche questa casella di controllo.

Godere

Questo è risolto nel mio caso.

JS

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

Questa risposta è stata inserita in questo link

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

Nel mio caso, ciò è stato causato dallo script flexie che faceva parte dell'app "CDNJS Selections" offerta da Cloudflare .

Secondo Cloudflare "Questa app è stata deprecata a marzo 2015". L'ho spento e il messaggio è scomparso all'istante.

Puoi accedere alle app visitando https://www.cloudflare.com/a/cloudflare-apps/yourdomain.com

NB: questa è una copia della mia risposta su questo thread Synchronous XMLHttpRequest warning e <script> (ho visitato entrambi mentre cercavo una soluzione)

Ho risolto questo problema con i passaggi seguenti:

1. Controlla i tuoi script CDN e aggiungili localmente.
2. Sposta i tuoi script inclusi nella sezione dell'intestazione.

Nel mio caso particolare stavo eseguendo il rendering parziale di Rails senza il render layout: falsequale stavo ridistribuendo l'intero layout, inclusi tutti gli script nel <head>tag. L'aggiunta render layout: falseall'azione del controller ha risolto il problema.

Per me, il problema era che in una richiesta OK, mi aspettavo che la risposta ajax fosse una stringa HTML ben formattata come una tabella, ma in questo caso il server stava riscontrando un problema con la richiesta, reindirizzando a una pagina di errore, e quindi restituivo il codice HTML della pagina di errore (che aveva un <scripttag da qualche parte. Ho consolato la risposta ajax ed è stato allora che mi sono reso conto che non era quello che mi aspettavo, quindi ho proceduto al debug.

La domanda è stata sollevata nel 2014 ed è il 2019, quindi credo sia bello cercare un'opzione migliore.

Puoi semplicemente usare fetchapi in Javascript che ti offre maggiore flessibilità.

ad esempio, vedi questo codice

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