I have a page that produces more than 50,000 lines of code after it runs.
Although hard to believe (sarcasm), IE7 chokes up on it (gives me slow script warning), and of course IE6 is worse. I get errors on the page - but depending on what information I load the line number can be anything from the ASP to HTML to jQuery. I've separated these three and it just comes down to the size of the loops.
I tried using response.buffer/ response.flush throughout the page but that has not helped. It could be I'm using it wrong, but as far as I know response.buffer just needs to equal true- and response.flush just needs to be anywhere you need to not hold on information too long (i did both inside and outside of all loops- perhaps this is a no no?).
Short of splitting up the page into several web pages, is there anything else I could try?
I have to develop for IE7 so no way around it unfortunately.
Related
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.');
So, this is weird.
We have a 2008 R2 server and Win 7x64 dev workstations running Classic ASP.
One page in the site, at exactly carat position 98301, a </div is being inserted into the source. Notice it's not a fully closing div (</div>) tag. Just </div .
So, all sorts of things are breaking since it moves around, based on other things that modify the page (user permissions, querystring values, etc). But always exactly at position 98301 in the code. And always only on this one page.
I've never seen this before and have no idea where to figure out what's doing it. We have many other pages with hundreds of thousands of characters that are fine. We have shorter pages, too. All the IIS settings are the same for all pages and include a 4Mb response buffer and both static and dynamic compression enabled (which I togged both ways without change). We also have 3 source control branches and this is happening in them all, only on this one page.
We are using 2 Win7x64 dev workstations, 1 Win2008R2 local test server and 1 Win2008R2 prod server, and they all do exactly the same thing.
I've moved around the code some, cut out functions, added new code in there to loop Hello World, and no matter what I do, it always inserts just </div at exactly carat position 98301.
I can't think of anything else to test. All suggestions are welcome! Thank you!
Turns out it was the combination of htmlEncode() and htmlDecode() being on the page, and was only a problem in Chrome (currently v39.x). Firefox and IE worked fine. On our page we had about a 600 line script block, and htmlEncode() and htmlDecode() were close to the top of the block. By moving them to immediately before the </script> tag everything worked and </div was not being injected. While I was not the author of that page, I can see the htmlEncode() and htmlDecode() functions were sourced from here: HTML-encoding lost when attribute read from input field
Additionally, we have both Prototype (1.7.1) and jQuery (1.11.x) loaded, and jQuery loading as var $j = jQuery.noConflict(); before Prototype. Changing return $('<div/>').... to return $j('<div/>').... and even return jQuery('<div/>').... had absolutely no affect on the situation.
I still do not know WHY this was happening, but it has been resolved (for now, anyway) by moving the functions to the bottom of the script tag.
No this isn't a post from the previous century.
We are stuck with IE6 and some old ASP code using FRAMESETs
The problem:
An ASP page sets up a load of values in a form and then submits it to another ASP page
This second page is a FRAMESET with a map and other associated stuff, the first thing it does is read all the values to setup the layout.
All works well most of the time but sometimes it all goes horribly wrong.
The first page calls the second but the Request.Form.Count is 0 and it all falls over
Once this happens it never works again until I close IE6 and restart it.
Then when I submit Request.Form.Count = 29 which it should be.
Any ideas as to what might be going on in IE?
For some reason calling the initial ASP page from a link on another page causes it to go wrong much more often that just pasting the URL into the address bar.
I've tried all possible methods of linking and redirecting and they all cause the problem more often than not.
Also, it works fine in every other browser I've tried but IE6 is the one we have to target.
Ken
Forgot to say that trying to debug with Fiddler doesn't help since it never goes wrong then
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.
Ok so I'm writing a failry complex ASP.NET page that has quite a bit of javascript related to it. The problem is the page has alot going on with it but the browser just acts unresponsive alot of the time and lags while the javascript seems to perform fine.
In this page, I send down a array list of available items for the user to select from. Well when this list grows to like a 1000+ items in the list the page just sucks for lack of better words. If i don't have that many items to select from the page acts fine. I mean the javascript performance is ok but the page just lags. The scroll bars on the page are just laggy, it just feels like horrible. Of course none of this happens in Chrome or Firefox.
To kind of give you a little more perspective on the issue, the site has about 150k unminified uncompress css styles for this page, about 10,000 lines of code for js including frameworks, controls, and business rules specific for the page, and the array object text saved to a text document is about 200kb.
Any help on the matter would be greatly appeciated as this is about my 5th month stab at getting this faster...
One of the Yahoo performance rules is "Reduce the number of DOM elements". They say this for a reason.
When you start to go into the range of "thousands" of DOM elements, IE bogs down pretty rapidly. Every interaction with the page becomes slow. The only "solution" is to use fewer DOM elements.
For example, I recently made a web app containing 4 grids with 100 rows each with around 10 columns, all visible at the same time. Those 4000 cells were making IE really slow. I solved this by using a buffered view grid, that only renders the visible rows, and removes the rows outside of the visible scroll area from the DOM (using the ExtJS grid if it interests you).
Of course none of this happens in Chrome or Firefox.
The bane of my little web app developer existence once things get awesome. There's no answer usually other than to simplify the page.
The concepts behind pagination apply to other application pieces. Active Directory won't display every record in a single list once it's large--and it's a desktop app.
Cut it back and then use the interface to get things gradually (usually through JSON requests for me).