One of our client is trying to generate reports with lots of sub reports, its a single page report. If they generate it for 2-3 years it works for all browsers, but when they generate it for 5 years. Report works fine in chrome and firefox but IE will not be able to load reports and show IE window "Internet explorer cannot load page".
There is no errors in eventlog or in IE console. Even Fiddler does not give any information why IE could not able to load reports. It says response 200.
Reports are generated successfully, as I can see that in log.
I am not sure why this is happening with IE(8,9,10). Please check images below
Thanks
This could be due to the memory management problem in Internet Explorer, as you are fetching the 5 year data.
There is a work around for the memory problem.
->Go IIS
->Open your reporting Website
->Check which application pool its using
->Right click on that and recycle it.
->Then try generating the report.
Not sure if it resolves your problem.
I've seen a very similar issue recently - it started a few months ago, across multiple unchanged reports, and seemed to be triggered by hard or soft Page Breaks (I found that out from a lengthy process of elimination).
That scenario was SQL Server Reporting Services 2012 SP1, via the Native/Report Manager portal.
Does your report render with page breaks?
My solution was to set the Report / InteractiveSize / Height to 1000cm. Then for each hard page break, I disabled it for browser rendering by setting the Page Break / Disable property using this expression:
=Globals!RenderFormat.IsInteractive
The result is a little untidy in the browser, but renders with page breaks in other formats (PDF, Word, Excel). Importantly it stopped the browser freezing in IE.
Personally I have moved away from the report display control. It provides inconsistent display on different platforms (al least it did in 2013 when I did the lions share of converting a project).
Instead I render to PDF (Word or Excel) at the server and use an embed tag to display the content to the user. You are guaranteed to know what it looks like on the user screen that way. A level of caching is possible and its a lot easier to work with.
Related
I've been stumped on this problem for a week. After consulting various questions and failing to find a resolution I decided to finally ask here.
Project Info: Using ASP Net and Visual Studio.
Element causing issue: iframe being loaded from Microsoft Power BI
Issue: when I open my webpage in Internet Explorer or Firefox, the iframe will grab focus (I think this is focus) and force the page down to the iframe after loading.
Possible resolution 1: prevent the iframe from ever grabbing focus.
Possible resolution 2: implement a lazy load system so the iframe doesn't load until the user scrolls to it. This would also be satisfactory.
Background: We are using ASP Net Master and child pages. The issue occurs on a child page. So any advise on where to place a script with solution would be helpful as well.
This is a common issue with Power BI embedded. For example, if you visit the official Microsoft blog where they have embedded an iframe, the "jump" will occur if you open this link in Internet Explorer: https://powerbi.microsoft.com/en-us/blog/announcing-power-bi-publish-to-web/
Here's what the embedded code looks like:
<iframe width="455" height="345" src="https://app.powerbi.com/view?r=eyJrIjoiOTAzYzU2NGUtNzc0Ny00NTU4LWJmNWMtNjJhMWJiOTcwMjdiIiwidCI6ImY4NTA5NjYwLWNiMTMtNGU2Yy1hYzhjLWNlZWNjZDIzNzkyYSIsImMiOjZ9"></iframe>
I have been so stumped on this. Any advice would be so appreciated!
I have a very pretty calendar report that I've created on one machine, that shows my company's daily revenue as a color coded block for every day for the past several years. After finally getting a color scheme down and pretty much finalizing it, I went to test it on another machine - and hit a rather large obstacle.
This is the report that I used as a template:
http://bl.ocks.org/mbostock/4063318
It's awesome. And, inside Internet Explorer 11, it looks fantastic. I never would have expected that copying the code and testing the report would produce a blank page, but there it is. On that page, the calendar report is visible. In IE 11. Copying the code to a new html file and opening it, shows nothing. In Firefox, however, everything is visible. as is.
Now, there's a part of that page that points to "//d3js.org/d3.v3.min.js"
And I figured out that in order to make that work in firefox I had to add the http: in front, so that's not my issue.
I'm literally sitting here at my desk staring at two browser windows open and pointing to the same html file. One contains my beautiful report, one is a completely blank page.
Some cursory google searches reveal that IE 8 or lower have issues with the svg. I can't seem to find any references on someone having a similar issue though. Their situation seems to be that with IE10, you need to specify the height and width, not just one or the other, to make sure everything scales properly.
If I could have my way, I'd just run Firefox on all of the machines that are going to run the report, even if it's just for that one thing! Alas, I am but a mere peasant coder and so I have to make it work. in the dreaded IE.
Are there any svg/html/d3.js coders out there that can tell me another way to spit out the data I'm using so that I can get what I'm looking for?
copying the code and testing the report would produce a blank page
Because you're outputting invalid HTML. There is no html or head element for starters.
Output your code in to a file like example.xhtml and open it in Firefox (specifically) as it's XML parser will very quickly tell you what line and column the first XML parser error is occurring on. You are rendering in standards mode instead of quirks though that does not imply your page meets standards.
var m=(document.compatMode == 'CSS1Compat') ? 'Standards' : 'Quirks'; window.alert(m+'-mode.');
I'm using Firefox developer edition, trying to debug a page (html+javascript) in a frame.
With Firefox 33, in the debugger section I can see the source code of the page inside the frame, activate breakpoints...
My problem with developer edition is that it doesn't show the html code of the page, although it is selected in the left side of the toolbar. It shows some html code, but it's not from the selected page. I can't locate where is it from.
Is there a way to have the same behaviour in debugger for firefox 33 and developer edition?
Thanks in advance, best regards
This is what GC does to you
Short answer, the HTML of the frame was being garbage collected away by the browser engine. This happens when the page/html has no script active on it which has still some work left to do.
This can be otherwise prevented by holding a strong reference to any object in the page and putting it somewhere where the browser thinks that its still being used.
For example,
window.foobar = some_object_from_the_page
will work.
Here is the root cause and a potential & partial fix is coming up in near future.
This may sound like a SuperUser issue, but I wrote the page in question and I'm wondering if there is something I can do to fix the problem....
I have a page in production that simlply displays data in a bunch of tables. Our employees basically go to this page to print a form with our clients information filled in for them. Today for a specific client the page is not printing. I've tried printing using IE 7 and 8 as well as Chrome on Windows XP and Windows 7. This client's data is by no means make the page longer or contain more data that others clients.
Symptoms:
Does NOT print using IE8 or IE7 on WinXP and Windows 7.
DOES print with Chrome.
The page to print is displayed fine as a far as the actual web page goes... it scrolls, there are no errors and and nothing seems to be wrong with the page.
When using IE to print, the document just spools with out actually printing out...I end up canceling the document from the printers window.
When viewing print preview the first page is displayed, but when we try to go to the second page in the print preview IE locks up.
This does not happen for every client, but when it does happen it can be reproduced.
The page is pretty long and has client info that is keeping me from just copy and pasting the markup for you guys. I am hopeing that some one else has experienced a similiar issue in IE and has some advice.
NOTE: The users are not allowed to use other browsers, so save the IE flamming please.
Hmmm, very hard to tell without markup.
Just to throw some ideas:
Are you using anything difficult on the pages, like Flash or Java?
Custom fonts / cufon?
Huge downscaled images?
opacity or IE specific crazy filter CSS rules?
A huge structure that IE doesn't manage to break up into pages, e.g. a giant table with position: absolute ?
If you use images, try turning off the images. Try turning off CSS.
A few things to try when debugging:
Switch everything over to a standard font and font size (e.g. Arial 12px).
Eliminate all CSS and JavaScript, and if that fixes it then you can narrow down from there by taking out chunk by chunk until it starts working.
If that doesn't work, try cutting down the content significantly to see if it will show up.
I was working on some ASP.NET 2.0 pages when I noticed that some of the pages' back buttons were unavailable - greyed out. And clicking the drop down menu next to them showed clear results, as if I had come to this page fresh. I looked through the code trying to find something to specifically disable the back buttons (redirects, clever javascript), but found nothing. So I started picking apart the page and noticed that when two particularly large drop down lists (One had 38 thousand items!) were commented out that the back button would again be available. By 'Commented out' I mean I did not databind them in the code behind.
It seems that these pages used to work before I inherited this project. One of the things we did was upgrade the server from .NET 2.0 to .NET 3.5, although the code still targets the 2.0 framework. I doubt this is the culprit though.
This problem occurs in both IE 6 and IE 8 with all the latest updates. It occurs on Server 2003 RC2 with all the updates I could find and on Windows XP machines that the client has selectively updated but are all running IE 6.
My question is, has anyone ever heard of this, and if so, what causes it? Is it just an Internet Explorer bug?
Well, 38k options # 28 characters^1 gives one a page size of 1,064,000 characters for the options alone, nevermind the accompanying viewstate. Which, when I think about it is probably what is killing IE as your POST size has to be in the megabytes range.
Personally, rather than beat on the issue which you probably can't fix, I'd go for hitting it from the easier side of re-factoring the interface so users get a managable number of options. I really don't know how one could pick the correct one in 38k in the first place anyhow . . .
^1: <option value="x">y</option> is about as short an option as ASP.NET will generate and that is 28 characters. I'd bet we are looking at far more data than that. I pray this is an intranet app . . .