Pregunta

Estoy hospedando un control de navegador web, que generalmente carga un documento externo, luego hace algunas modificaciones usando HTML DOM.

También incrustamos enlaces de aplicaciones personalizadas utilizando un protocolo falso, como " Cerrar este " que se capturan y manejan en BeforeNavigate2 .

Cuando el tarket del enlace está mal escrito (por ejemplo, " spp: CloseWindow "), BeforeNavigate no activará la gestión personalizada. El control del navegador no muestra un error de navegación, pero permanece en READYSTATE_INTERACTIVE y no dispara un NavigateComplete o DocumentComplete .


Mi problema: La mayoría de las operaciones (por ejemplo, recuperar o actualizar los contenidos) se retrasan y esperan a que el estado listo llegue a READYSTATE_COMPLETE . Después de hacer clic en un enlace no válido, el navegador ya no se actualiza, un estado que me gustaría evitar. ¿Cómo puedo hacer eso?

  • ¿Puedo detectar en " DownloadComplete " que la navegacion falló? (Por lo tanto, podría relajar la prueba a " READYSTATE_COMPLETE o READYSTATE_INTERACTIVE y la última descarga fue completada ")
  • ¿Puedo " restablecer " el control del navegador para READYSTATE_COMPLETE (probablemente no)
  • ¿Puedo detectar los pseudoprotocols que realmente son compatibles con el navegador?

(En retrospectiva, usar el prefijo xxxx: no fue una buena idea, pero cambiar eso ahora es un problema).

¿Fue útil?

Solución

Internet Explorer y Windows tienen una lista extensible de protocolos disponibles implementados en UrlMon.dll, creo. Consulte aquí un poco acerca de arquitectura de IE .

La razón por la que no puede detectar el protocolo incorrecto en BeforeNavigate es que el protocolo es desconocido, por lo que no se está realizando una navegación real. El navegador decide mostrar una página de error en su lugar. La navegación de la página de error no provoca evidentemente todos los eventos normales.

Sin embargo, hay una manera de detectar cuando la navegación ha entrado en la maleza. Si se conecta al evento DocumentCompleted del navegador web, puede analizar las URL particulares asociadas con los errores, o más generalmente, cualquier cosa con una URL que comience con res: //ieframe.dll.

Ejemplos:

  • res: //ieframe.dll/unknownprotocol.htm#spp: CloseWindow
  • res: //ieframe.dll/dnserrordiagoff_webOC.htm# http: // 192 ...

Una forma más limpia es engancharse en el NavigateError de Interfaz DWebBrowserEvents2 .

Otros consejos

Tuvimos un problema al alojar un control de navegador web ( Google Map ) en el hecho de que se nos notificara que la navegación estaba completa ( NavigateComplete ), sin embargo, la página web en sí no había terminado de renderizar. Para solucionar este problema, agregamos una función javascript notifyInitialised que simplemente navegó a 'app: // onInitialised' - un mecanismo similar que estás usando.

Tal vez podrías hacer algo como esto (si tienes control sobre las páginas a las que el usuario está navegando). Podría agregar este mecanismo de notificación y verificarlo en su código. Si no se recibe después de un tiempo de espera prescrito, podría asumir que algo salió mal y mostrar un mensaje relevante.

Si está interesado, también usamos un mecanismo para llamar directamente a funciones javascript desde nuestro código C ++ descrito here y here .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top