ASP.NET ReportViewer Uso de la CPU de Google Chrome

Question

Hemos encontrado un problema interesante entre ASP.NET 3.5 y ReportViewer con Google Chrome. Nuestro conjunto de páginas funciona bien hasta que un control ReportViewer muestra un informe.

Google Chrome se come el 50% de la CPU sin hacer nada.

He extraído el control ReportViewer a un proyecto de Web Forms en blanco para confirmar su control y no un fragmento deshonesto de mi código.

Estoy utilizando ReportViewer en modo local (archivo RDLC) así que supongo que es la versión de 2005?

¿Alguien ha visto esto antes y tiene una solución?

Phil

Editar: Google Chrome 3.0.195.33 en Vista Business x64

Edición 2: Agregado de recompensas ayuda para solucionar este

Answer 1

La solución es, en realidad, que el JavaScript ReportViewer causa un bucle infinito en Chrome, estoy publicando el código fuente sobre cómo resolver este problema creando una versión personalizada del control ReportViewer y reparando el JavaScript roto (perdí el enlace a la solución, pero no escribí esto, simplemente lo usé :))

Puedo confirmar que ahora nos hemos actualizado al último ReportViewer en Visual Studio 2010, el problema de la CPU de Chrome ya no existe y este trabajo no es necesario.

public class MyReportViewer : Microsoft.Reporting.WebForms.ReportViewer 
{ 
    protected override void Render(HtmlTextWriter writer) 
    { 
     using (StringWriter sw = new StringWriter()) 
     { 
      HtmlTextWriter tmpWriter = new HtmlTextWriter(sw); 
      base.Render(tmpWriter); 
      string val = sw.ToString(); 
      val = val.Replace(@"!= 'javascript:\'\''", @"!= 'javascript:\'\'' && false"); 
      writer.Write(val); 
     } 
    } 
} 

Answer 2

tuve este problema y me volvió absolutamente loco!

Antes que nada, guarde el archivo generado, esto es si puede. A veces se congela. Guarde y verifique el tamaño del informe que se está generando. Mi problema resuletd en archivos que se generan más de 16 MB y ralentizar el navegador y la red.

Hágase un favor eche un vistazo al html, al ver la fuente, que se está generando dentro del formulario web. Compruebe si el estilo se ha escrito explícitamente en línea dentro del documento generado en lugar de hacerlo desde un archivo.

Intente eliminar el estilo del informe y vea si eso ayuda.

Answer 3

Hay un hilo en los foros de Google Chrome hablando de esto. No sé si es posible ejecutar el informe en el servidor en lugar de localmente, lo que parece solucionar el problema. Aquí está el hilo: ReportViewer rendering maxes out thread CPU usage

Answer 4

Mientras que Chrome es un buen navegador y está evolucionando bastante rápido, me temo que por el momento no hay otra solución que usar otro navegador. Creo que Google estará trabajando en este tema con el tiempo, pero por ahora no es fijo.

Creo que intentarían solucionar otros problemas. Vi que otras páginas se representaban de una manera extraña con Chrome y no con IE.

Answer 5

Si está utilizando el Administrador de informes como yo (versión 2005), no hay mucho que pueda hacer con el control ReportViewer. (¿existe?) Sin embargo, existe una alternativa:

La solución de Phil desactiva efectivamente el código ejecutado por el evento onload de un iframe.En SSRS 2005, este es un iframe con id 'ctl140TouchSession0':

<iframe name="ctl140TouchSession0" id="ctl140TouchSession0" onload="if (frames['ctl140TouchSession0'].location != 'javascript:\'\'') frames['ctl140TouchSession0'].location.replace('javascript:\'\'');" src="javascript:''" style="position:absolute;width:0;height:0;border-width:0;visibility:hidden;"> 

se puede ver el código erróneo en el proceso de carga - el código Render desactiva la sentencia if añadiendo "& & falsa" a la condición.

El siguiente javascript logra lo mismo al vaciar la carga después de cargar la página, deteniendo el ciclo.

(Añadir este en la parte inferior de [MSSQL Reporting Services carpeta] \ ReportManager \ js \ ReportingServices.js)

// CUSTOMIZATIONS 
addLoadEvent(customize); 

//some browser-independent onload-adder I pulled from somewhere 
function addLoadEvent(fn) 
{ 
    if (window.addEventListener) 
     window.addEventListener('load', fn, false); 
    else if (window.attachEvent) 
     window.attachEvent('onload', fn); 
} 

function customize() 
{ 
    //the actual fix. 
    //check first, we may be in a page without a reportviewer 
    if(document.getElementById('ctl140TouchSession0')) 
     document.getElementById('ctl140TouchSession0').onload = ""; 
} 

Nota: No estoy seguro de lo que hace en realidad el proceso de carga y si quitarlo como esto mata alguna otra funcionalidad. Debería haber alguna forma de cambiar la carga de la misma forma que la solución de Phil o una solución dependiente del navegador, pero esto funciona y todavía no he encontrado problemas en IE.

Answer 6

Esto funcionó para mí, pero no es que lo recomiende. Noté que mi WebKitInspector provocaría que el navegador se congelara.

var iframes = document.getElementsByTagName("IFRAME"); 

for (var i = 0, ln = iframes.length; i < ln; i++) { 

    iframes[0].parentNode.removeChild(iframes[0]); 
} 

Answer 7

Si cambiamos el tipo de documento a partir de:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> 

a:

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 

funciona en Chrome, pero deja de funcionar en IE.