ASP.NET ReportViewer Google Chrome CPU usage
We have found an interesting issue between ASP.NET 3.5 and ReportViewer with Google Chrome. Our set of pages work fine until a ReportViewer control displays a report.
Google Chrome then eats up 50% of the CPU doing nothing it seems.
I've extracted the ReportViewer control to a blank Web Forms project to confirm its that control and not a rogue bit of my cod开发者_运维技巧e.
I'm using ReportViewer in local mode (RDLC file) so I presume its the 2005 version?
Anyone seen this before and have a solution?
Phil
Edit: Google Chrome 3.0.195.33 on Vista Business x64
Edit 2: Added bounty for help fixing this
The solution is actually some of the ReportViewer JavaScript causes an infinite loop in Chrome, I am posting the source code on how to solve this issue by making a custom version of the ReportViewer control and fixing the broken JavaScript (I've lost the link to the solution, but I didn't write this, just used it :))
I can confirm that now we have upgraded to the newest ReportViewer in Visual Studio 2010, the Chrome CPU issue no longer exists and this work around isn't required.
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);
}
}
}
There's a thread on the Google Chrome forums talking about this. I don't know if it's possible for you to run the report on the server instead of locally, which seems to fix the issue. Here's the thread: ReportViewer rendering maxes out thread CPU usage
If you are using the Report Manager like me (2005 version) there is not much you can do about the ReportViewer control. (is there?) There is an alternative, though:
Phil's solution effectively disables the code run by the onload event of a an iframe. In SSRS 2005 this is an iframe with 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;">
You can see the offending code in the onload event - the Render code disables the if statement by adding " && false" to the condition.
The following javascript accomplishes the same thing by emptying the onload after the page is loaded, stopping the loop.
(Add this at the bottom of [MSSQL Reporting services Folder]\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 = "";
}
Note: I am unsure what the onload event actually does and if removing it like this kills some other functionality. There should be some way to change the onload in the same way as Phil's solution, or a browser dependent fix, but this does the trick and I have not encountered problems in IE yet.
If we change the doc type from:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
to:
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
it works on chrome but stops working on IE.
I had this problem and it drove me absolutly crazy!
First of all save the generated file - this is if you can. Sometimes it freezes up. Save and check the size of the report being generated. My issue resuletd in files in excess of 16MB being generated and slowing down the browser and network.
Do yourself a favour have a look at the html, by viewing source, that is being generated inside the web form. Check whether the styling has been written explicitly inline within the generated document instead of referenced from a file.
Try removing the styling from the report and see if that helps.
While Chrome is a nice browser and is evolving rather quickly, I am afraid there are for now no solution other than use another browser. I would think that Google will be working on this issue eventually but for now it is not fixed.
I'de think they would try to fix other issues. I did see other pages being rendered in a weird way with chrome and not with IE.
This did work for me, it's not that I would recommend it though. I noticed that my WebKitInspector would cause the browser to freeze.
var iframes = document.getElementsByTagName("IFRAME");
for (var i = 0, ln = iframes.length; i < ln; i++) {
iframes[0].parentNode.removeChild(iframes[0]);
}
加载中,请稍侯......
精彩评论