debugging - debugger - ¿Qué significa status=cancelled para un recurso en Chrome Developer Tools?
debugger javascript chrome (21)
En mi caso, el código para mostrar la ventana del cliente de correo electrónico hizo que Chrome dejara de cargar imágenes:
document.location.href = mailToLink;
moviéndolo a $ (window) .load (function () {...}) en lugar de $ (function () {...}) ayudó.
¿Qué causaría que una página fuera cancelada? Tengo una captura de pantalla de las herramientas de desarrollo de Chrome.
Esto sucede a menudo pero no siempre. Parece que una vez que se almacenan en caché otros recursos, una actualización de la página cargará el LeftPane.aspx. Y lo que es realmente extraño es que esto solo ocurre en Google Chrome, no en Internet Explorer 8. ¿Alguna idea de por qué Chrome cancelaría una solicitud?
En mi caso, encontré que se trata de una configuración de tiempo de espera global jquery, un tiempo de espera global de configuración del plugin jquery a 500 ms, de modo que cuando la solicitud supere los 500 ms, Chrome cancelará la solicitud.
Es posible que desee comprobar la etiqueta de encabezado "X-Frame-Options". Si se establece en SAMEORIGIN o DENY, Chrome (y otros navegadores) cancelarán la inserción de iFrame según la spec .
Además, tenga en cuenta que algunos navegadores admiten la configuración ALLOW-FROM pero Chrome no.
Para resolver esto, deberá eliminar la etiqueta del encabezado "Opciones de X-Frame". Esto podría dejarlo abierto a ataques de clickjacking, por lo que tendrá que decidir cuáles son los riesgos y cómo mitigarlos.
Esto es lo que me pasó: el servidor devolvía un encabezado de "Ubicación" con un formato incorrecto para un redireccionamiento 302. Chrome no pudo decirme esto, por supuesto. Abrí la página en Firefox, e inmediatamente descubrí el problema. Es bueno tener múltiples herramientas :)
Esto puede ayudar a cualquiera con el que me encontré con el estado cancelado cuando omití el retorno falso; en el formulario enviar. Esto provocó que el envío ajax fuese seguido inmediatamente por la acción de envío, que sobrescribió la página actual. El código se muestra a continuación, con el retorno importante falso al final.
$(''form'').submit(function() {
$.validator.unobtrusive.parse($(''form''));
var data = $(''form'').serialize();
data.__RequestVerificationToken = $(''input[name=__RequestVerificationToken]'').val();
if ($(''form'').valid()) {
$.ajax({
url: this.action,
type: ''POST'',
data: data,
success: submitSuccess,
fail: submitFailed
});
}
return false; //needed to stop default form submit action
});
Espero que ayude a alguien.
Fue tan simple como un camino incorrecto para mí. Yo sugeriría que el primer paso en la depuración sería ver si puede cargar el archivo independientemente de ajax, etc.
He incorporado todos los tipos de fuentes, así como woff , woff2 , ttf cuando incrusté una fuente web en la hoja de estilo. Recientemente noté que Chrome cancela la solicitud a ttf y woff cuando woff2 está presente. Utilizo la versión 66.0.3359.181 de Chrome en este momento, pero no estoy seguro de cuándo Chrome comenzó a cancelar tipos de fuentes adicionales.
La versión de Chrome 33.0.1750.154 m cancela constantemente las cargas de imágenes si estoy usando la emulación móvil apuntada a mi host local; específicamente con la función de suplantación de User Agent (en comparación con la configuración de pantalla)
Cuando apago el agente de usuario Las solicitudes de imágenes no se cancelan, veo las imágenes.
Todavía no entiendo por qué; en el primer caso, cuando la solicitud se cancela, los encabezados de solicitud (PRECAUCIÓN: se muestran los encabezados provisionales) solo tienen
- Aceptar
- Control de caché
- Pragma
- Referer
- Agente de usuario
En este último caso, todos aquellos más otros como:
- Galleta
- Conexión
- Anfitrión
- Aceptar-codificación
- Aceptar-lenguaje
Encogimiento de hombros
Luchamos contra un problema similar en el que Chrome estaba cancelando solicitudes para cargar cosas dentro de marcos o iframes, pero solo de forma intermitente y parecía dependiente de la computadora y / o la velocidad de la conexión a internet.
Esta información está desactualizada hace unos meses, pero construí Chromium desde cero, busqué en la fuente para encontrar todos los lugares donde se podían cancelar las solicitudes y pisé puntos de interrupción en todos ellos para depurar. Desde la memoria, los únicos lugares donde Chrome cancelará una solicitud:
- El elemento DOM que hizo que se realizara la solicitud se eliminó (es decir, se está cargando una IMG, pero antes de que ocurriera la carga, se eliminó el nodo IMG)
- Hiciste algo que hizo innecesaria la carga de datos. (es decir, usted comenzó a cargar un iframe, luego cambió el src o sobrescribió el contenido)
- Hay muchas solicitudes dirigidas al mismo servidor, y un problema de red en solicitudes anteriores mostró que las solicitudes subsiguientes no iban a funcionar (error de búsqueda de DNS, resultado anterior (igual) resultado, por ejemplo, código de error HTTP 400, etc.)
En nuestro caso, finalmente lo rastreamos en un marco tratando de agregar HTML a otro marco, que a veces sucedía incluso antes de que el marco de destino se cargara. Una vez que toca el contenido de un iframe, ya no puede cargar el recurso (¿cómo sabría dónde colocarlo?), Por lo que cancela la solicitud.
Me había enfrentado al mismo problema, en algún lugar de nuestro código teníamos este pseudocódigo:
- crear un iframe
onload de iframe enviar un formulario
Después de 2 segundos, retire el iframe
por lo tanto, cuando el servidor tarda más de 2 segundos en responder al iframe en el que el servidor estaba escribiendo la respuesta, se eliminó, pero la respuesta aún estaba por escribirse, pero no había ningún iframe para escribir, por lo que Chrome canceló la solicitud. por lo tanto, para evitar esto, me aseguré de que el iframe se elimine solo después de que finalice la respuesta, o puede cambiar el destino a "_blank". Por lo tanto, una de las razones es: cuando el recurso (iframe en mi caso) en el que está escribiendo algo, se elimina o se elimina antes de que deje de escribir en él, la solicitud se cancelará.
Me pasó lo mismo al llamar a un. js archivo con $. ajax, y hacer una solicitud ajax, lo que hice fue llamar normalmente.
NB: Asegúrese de que no tiene ningún elemento de formulario de envoltura .
Tuve un problema similar en el que mi botón con onclick = {} estaba envuelto en un elemento de formulario. Al hacer clic en el botón, también se envía el formulario, y eso lo arruinó todo ...
Esta respuesta probablemente nunca será leída por nadie, pero pensé por qué no escribirla :)
Otra cosa a tener en cuenta podría ser la extensión AdBlock, o extensiones en general.
Pero "mucha" gente tiene AdBlock ....
Para descartar la (s) extensión (es), abra una nueva pestaña en incógnito y asegúrese de que "permitir el ingreso de incógnito está desactivado" para la (s) extensión (es) que desea probar.
Otro lugar donde hemos encontrado el estado (canceled) es en una configuración incorrecta del certificado TLS en particular. Si un sitio como https://www.example.com está mal configurado, el certificado no incluye el www. pero es válido para https://example.com , chrome cancelará esta solicitud y redirigirá automáticamente a este último sitio. Este no es el caso de Firefox.
Ejemplo válido actualmente: https://www.pthree.org/
Para cualquier persona que venga de LoopbackJS y trate de usar el método de flujo personalizado como se muestra en su ejemplo de gráfico. eventsource este error utilizando un Model PersistedModel , el cambio a un Model básico solucionó mi problema de eventsource estado de la eventsource de eventsource .
De nuevo, esto es específicamente para la api de loopback. Y ya que esta es una de las mejores respuestas y las mejores de google, me di cuenta de que había puesto esto en la combinación de respuestas.
Para mí, el estado ''cancelado'' fue porque el archivo no existía. Extraño por qué el cromo no muestra 404 .
Para mi caso, tuve un ancla con evento click como
<a href="" onclick="somemethod($index, hour, $event)">
En caso de hacer clic dentro, recibí una llamada de red y Chrome canceló la solicitud. El ancla tiene href con "" significa que recarga la página y al mismo tiempo tiene un evento de clic con una llamada de red que se cancela. Cada vez que sustituyo el href con vacío como
<a href="javascript:void(0)" onclick="somemethod($index, hour, $event)">
¡El problema se fue!
Recibí este error en Chrome cuando lo redireccioné a través de JavaScript:
<script>
window.location.href = "devhost:88/somepage";
</script>
Como veis , olvidé el ''http: //'' . Después de que lo agregué, funcionó.
Se me ocurrió una solicitud cancelada al redirigir entre páginas seguras y no seguras en dominios separados dentro de un iframe. La solicitud redirigida se muestra en las herramientas de desarrollo como una solicitud "cancelada".
Tengo una página con un iframe que contiene un formulario alojado por mi pasarela de pago. Cuando se envió el formulario en el iframe, la pasarela de pago redirigiría nuevamente a una URL en mi servidor. La redirección recientemente dejó de funcionar y terminó como una solicitud "cancelada" en su lugar.
Parece que Chrome (estaba usando Windows 7 Chrome 30.0.1599.101) ya no permitía una redirección dentro del iframe para ir a una página no segura en un dominio separado. Para solucionarlo, me aseguré de que las solicitudes redirigidas en el iframe siempre se enviaran a direcciones URL seguras.
Cuando creé una página de prueba más simple con solo un iframe, había una advertencia en la consola (que anteriormente había omitido o tal vez no aparecía):
[Blocked] The page at https://mydomain.com/Payment/EnterDetails ran insecure content from http://mydomain.com/Payment/Success
La redirección se convirtió en una solicitud cancelada en Chrome para PC, Mac y Android. No sé si es específico para la configuración de mi sitio web (SagePay Low Profile) o si algo ha cambiado en Chrome.
Tenía exactamente lo mismo con dos archivos CSS que estaban almacenados en otra carpeta fuera de mi carpeta css principal. Estoy usando Expression Engine y encontré que el problema estaba en las reglas en mi archivo htaccess. Acabo de agregar la carpeta a una de mis condiciones y la arreglé. Aquí hay un ejemplo:
RewriteCond %{REQUEST_URI} !(images|css|js|new_folder|favicon.ico)
Por lo tanto, podría valer la pena revisar su archivo htaccess para detectar posibles conflictos.
status = cancelled puede suceder también en solicitudes ajax en eventos de JavaScript:
<script>
$("#call_ajax").on("click", function(event){
$.ajax({
...
});
});
</script>
<button id="call_ajax">call</button>
El evento envía la solicitud correctamente, pero se cancela entonces (pero el servidor la procesa). El motivo es que los elementos envían formularios en eventos de clic, sin importar si realiza alguna solicitud ajax en el mismo evento de clic.
Para evitar que la solicitud se cancele, JavaScript event.preventDefault (); Hay que llamarse:
<script>
$("#call_ajax").on("click", function(event){
event.preventDefault();
$.ajax({
...
});
});
</script>