JavaScript console.log causa un error: "XMLHttpRequest síncrono en el subproceso principal está en desuso ..."

He estado agregando registros a la consola para verificar el estado de diferentes variables sin usar el depurador de Firefox.

Sin embargo, en muchos lugares en los que agrego un archivo a console.logmi main.jsarchivo, recibo el siguiente error en lugar de mis adorables mensajes escritos a mano:

XMLHttpRequest síncrono en el subproceso principal está en desuso debido a sus efectos perjudiciales para la experiencia del usuario final. Para más ayuda http://xhr.spec.whatwg.org/

¿Qué alternativas o envoltorios console.logpuedo agregar al uso de mi código que no causen este error?

¿Lo estoy "haciendo mal"?

Esto me sucedió cuando era flojo e incluí una etiqueta de script como parte del contenido que se devolvía. Como tal:

Contenido parcial de HTML:

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

Parece, al menos en mi caso, que si devuelve contenido HTML como ese a través de xhr, hará que jQuery haga una llamada para obtener ese script. Esa llamada ocurre con un indicador asíncrono falso ya que supone que necesita el script para continuar cargándose.

En situaciones como esta, será mejor que busque un marco vinculante de algún tipo y solo devuelva un objeto JSON, o dependiendo de su backend y plantillas, puede cambiar la forma en que carga sus scripts.

También puede usar jQuery'sgetScript() para obtener scripts relevantes. Aquí hay un violín, es solo una copia directa del ejemplo de jQuery, pero no veo ninguna advertencia cuando se cargan los scripts de esa manera.

Ejemplo

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

http://jsfiddle.net/49tkL0qd/

El mensaje de advertencia PUEDE SER debido a una solicitud XMLHttpRequest dentro del hilo principal con el indicador asíncrono establecido en falso.

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

XMLHttpRequest síncrono fuera de los trabajadores está en proceso de ser eliminado de la plataforma web, ya que tiene efectos perjudiciales para la experiencia del usuario final. (Este es un proceso largo que lleva muchos años). Los desarrolladores no deben pasar falso por el argumento asíncrono cuando el entorno global de JavaScript es un entorno de documentos. Se recomienda encarecidamente a los agentes de usuario que adviertan sobre dicho uso en las herramientas de desarrollador y que puedan experimentar lanzando una excepción InvalidAccessError cuando ocurra.

La dirección futura es permitir solo XMLHttpRequests en subprocesos de trabajo. El mensaje pretende ser una advertencia a tal efecto.

También estaba enfrentando el mismo problema, pero pude solucionarlo poniendo async: true. Sé que es cierto por defecto, pero funciona cuando lo escribo explícitamente

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

El depurador en vivo de Visual Studio 2015/2017 está inyectando código que contiene la llamada en desuso.

A veces es necesario cargar una secuencia de comandos ajax pero retrasar el documento listo hasta después de cargar la secuencia de comandos.

jQuery admite esto con el holdReady() función.

Ejemplo de uso:

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

La carga real del script es asíncrona ( sin error ), pero el efecto es sincrónico si el resto de su JavaScript se ejecuta después de que el documento esté listo .

Esta característica avanzada normalmente la usarían los cargadores de scripts dinámicos que desean cargar JavaScript adicional, como los complementos jQuery, antes de permitir que ocurra el evento listo, aunque el DOM esté listo.

Documentación:
https://api.jquery.com/jquery.holdready

ACTUALIZACIÓN 7 de enero de 2019

De JQMIGRATE :

jQuery.holdReady () está en desuso

Causa: el jQuery.holdReady()método ha quedado en desuso debido a su efecto perjudicial en el rendimiento global de la página. Este método puede evitar que todo el código de la página se inicialice durante largos períodos de tiempo.

Solución: reescriba la página de modo que no requiera que todos los controladores listos para jQuery se retrasen. Esto podría lograrse, por ejemplo, cargando solo el código que requiere la demora cuando es seguro ejecutarlo. Debido a la complejidad de este método, jQuery Migrate no intenta completar la funcionalidad. Si la versión subyacente de jQuery utilizada con jQuery Migrate ya no contiene jQuery.holdReady()el código fallará poco después de que aparezca esta advertencia.

Para evitar esta advertencia, no use:

async: false

en cualquiera de sus llamadas $ .ajax (). Esta es la única característica de XMLHttpRequest que está en desuso.

El valor predeterminado es

async: true

jQuery ha desaprobado XMLHTTPRequest sincrónico

La respuesta parcial de @Webgr en realidad me ayudó a depurar esta advertencia en el registro de la consola, lástima que la otra parte de esa respuesta trajo tantos votos negativos :(

De todos modos, así es como descubrí cuál fue la causa de esta advertencia en mi caso:

1. Use el navegador Chrome> Hit F12 para traer DevTools
2. Abra el menú del cajón (en Chrome 3 puntos verticales en la esquina superior derecha)
3. En Consola > marque la opción Registrar XMLHttpRequests
4. Vuelva a cargar su página que le estaba dando el error y observe lo que sucede en cada solicitud ajax en el registro de la consola.

En mi caso, otro complemento estaba cargando 2 bibliotecas .js después de cada llamada ajax, que no eran necesarias ni necesarias. La desactivación del complemento no autorizado eliminó la advertencia del registro. Desde ese punto, puede intentar solucionar el problema usted mismo (por ejemplo, limitar la carga de los scripts a ciertas páginas o eventos; esto es demasiado específico para una respuesta aquí) o ponerse en contacto con un desarrollador de complementos de terceros para resolverlo.

Espero que esto ayude a alguien.

He estado mirando las respuestas todas impresionantes. Creo que debería proporcionar el código que le está dando un problema. Dado el ejemplo a continuación, si tiene un script para vincular a jquery en page.php, recibirá ese aviso.

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

Recibo tal advertencia en el siguiente caso:

1) archivo1 que contiene <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>. La página tiene campos de entrada. Ingreso algún valor en el campo de entrada y hago clic en el botón. Jquery envía entradas al archivo php externo.

2) el archivo php externo también contiene jquery y en el archivo php externo también lo incluí <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>. Porque si esto recibí la advertencia.

Eliminado <script type="text/javascript" src="/javascript/jquery-1.10.2.js"></script>del archivo php externo y funciona sin la advertencia.

Según tengo entendido al cargar el primer archivo (archivo1), cargo jquery-1.10.2.jsy como la página no se vuelve a cargar (envía datos al archivo php externo usando jquery $.post), luego jquery-1.10.2.jscontinúo existiendo. Entonces no es necesario volver a cargarlo.

Obtuve esta excepción cuando configuré url en una consulta como "example.com/files/text.txt". He cambiado la URL a " http://example.com/files/text.txt " y esta excepción desapareció.

Y obtuve esta excepción por incluir un script can.js dentro de otro, por ejemplo,

{{>anotherScript}}

En una aplicación MVC, recibí esta advertencia porque estaba abriendo una ventana de Kendo con un método que devolvía una Vista (), en lugar de una Vista parcial (). La Vista () intentaba recuperar de nuevo todos los scripts de la página.

Me estaba pasando en ZF2. Intenté cargar el contenido modal pero olvidé deshabilitar el diseño antes.

Entonces:

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

Al igual que @Nycen, también recibí este error debido a un enlace a Cloudfare. El mío era para el complemento Select2 .

para arreglarlo acabo de quitar

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

y el error desapareció

1. En Chrome press F12
2. Herramientas de desarrollo-> prensa F1.
3. Ver configuración-> general-> Apariencia: "Don't show chrome Data Saver warning"- configure esta casilla de verificación.
4. Ver configuración-> general-> Consola: "Log XMLHTTPRequest"- configure también esta casilla de verificación.

Disfrutar

Esto se resuelve en mi caso.

JS

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

Esta respuesta fue insertada en este enlace

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

En mi caso, esto fue causado por el script flexible que era parte de la aplicación "Selecciones CDNJS" ofrecida por Cloudflare .

Según Cloudflare "Esta aplicación está en desuso en marzo de 2015". Lo apagué y el mensaje desapareció al instante.

Puede acceder a las aplicaciones visitando https://www.cloudflare.com/a/cloudflare-apps/yourdomain.com

NB: esta es una copia de mi respuesta en este hilo Advertencia de Synchronous XMLHttpRequest y <script> (Visité ambos cuando buscaba una solución)

Lo arreglé con los siguientes pasos:

1. Verifique sus scripts de CDN y agréguelos localmente.
2. Mueva sus scripts incluidos en la sección de encabezado.

En mi caso particular, estaba renderizando un Rails parcial sin el render layout: falsecual estaba renderizando nuevamente el diseño completo, incluyendo todos los scripts en la <head>etiqueta. Agregar render layout: falsea la acción del controlador solucionó el problema.

Para mí, el problema era que en una solicitud OK, esperaba que la respuesta ajax fuera una cadena HTML bien formateada, como una tabla, pero en este caso, el servidor estaba experimentando un problema con la solicitud, redirigiendo a una página de error, y, por lo tanto, estaba devolviendo el código HTML de la página de error (que tenía una <scriptetiqueta en alguna parte. Consola registró la respuesta ajax y fue entonces cuando me di cuenta de que no era lo que esperaba, luego procedí a hacer mi depuración.

La pregunta se planteó en 2014 y es 2019, así que supongo que es bueno buscar una mejor opción.

Simplemente puedes usar fetch api en Javascript que le brinda más flexibilidad.

por ejemplo, vea este código

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