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.
Related
I have a QGraphicsWebView to which I construct a page by appending tags. For example:
webElement.appendInside("<img src=<img src=\"qrc:/img/ioLlogoTopLeft.png\" />");
This happens in a secondary QThread. I also use resources to set styling in the same thread:
defaultBaseFrame->setStyleProperty("background-image", "url(qrc:/img/ioLGradientTop.png)");
Both of these lines were working fine, but in the last few builds they've stopped working, and I've no idea why. Instead of an image I now get an empty frame, and the background fails to appear. The resource paths seem fine, and work fine in other (non web-view) parts of the program.
On the other hand, when I replace an image URL with a location on the internet (an http:// url), the image loads normally.
Is there some quirk to using resources in a multithreaded environment (or was that just a red-herring?) Resource images were working before, and I can't think of anything relevant in the code that I've changed recently.
Solved it. And not a particularly satisfying solution; more just a quirk of Qt. It turns out the problem started when I removed the (I assumed) redundant initialisation of the WebView to a blank page:
webView->setHtml("<html><head></head><body></body></html>");
When I re-added it, images in resource files started working again. There didn't seem to be any other difference in functionality; all the other page elements render the same, just that one little quirk was fixed.
Recall that I'm building up the page from a blank DOM tree. I had falsely assumed that the above line was redundant because QWebView always inserts those boilerplate HTML tags automatically regardless, and almost everything works as it should either way.
Currently, I'm investigating several tips/recommendations for improving the performance of web sites. So, I've started with Steve Souders' excellent books (High performance web sites and even faster web sites), but I've got a couple of questions regarding some of the rules that are presented. FOr instance, chapter 5 of High performance web sites say that CSS stylesheets should be put at the top of the page because putting them at the bottom stops the progressive rendering that is performed by the browsers. According to Steve, some browsers (most notably IE) do get stuck with it and show a blank page instead of showing the items progressively. Here's the url for that test page:
http://stevesouders.com/hpws/css-bottom.php
Now, I do understand that we're talking about a book with a couple of years and that browsers (including IE) have been updated and improved. The reason I'm asking this is because I can't reproduce the behavior he mentions with any current version of FF, Chrome or IE.
Well, the thing is that Yahoo (http://developer.yahoo.com/performance/rules.html#css_top) and google (https://developers.google.com/speed/docs/best-practices/rendering#PutCSSInHead) still say that.
So, what I'd like to know is if browsers have evolved in this area and this is only problematic for, say IE 8? If that is the case, why haven't yahoo and google updated their recommendations? (btw, I've tried simulating IE7 from within IE11 and still don't see the expected result that is described in the book...)
*UDPATE*One more final note: I've decided to reproduce Steve's cgi script in asp.net and I've created a simple generic handler that does the same thing as the sleep.cgi script. what I'm seeing here is that putting a stylesheet reference (which takes some time to load - I've went with 10 seconds) inside the head ends up producing the blank page problem that is reported in the book. If you put at the end, the browser ends up rendering everything and making a second pass for applying the styles after they have been loaded. In my opinion, this makes sense because when you put the style in the header element, the browser is holding up until it gets the styles before rendering (notice that the other referenced components are still being downloaded on the background, but they're not being shown in the screen). On the other hand, when they're at the bottom, the browser will simply apply the current styles until it gets stuck in the stylesheet. WHen that happens, it will only show the html it has loaded until the stylesheet (if there are any images below it, the browser will still download them but it will only render them after the styles have been loaded).
So, after these tests, I'm starting to think that 1.) I'm missing something here or 2.) yahoo and google recommendations are no longer valid today.
Thoughts?
Thanks guys!
Simply inserting a <link> tag in the footer is not the way to defer stylesheets. The currently accepted method is to attach it using javascript:
<script>
function loadStyleSheet(e){if(document.createStyleSheet)try{document.createStyleSheet(e)}catch(t){}else{var l;l=document.createElement("link"),l.rel="stylesheet",l.type="text/css",l.media="all",l.href=e,document.getElementsByTagName("head")[0].appendChild(l)}}loadStyleSheet("/your/stylesheet.css");
</script>
Optimizing your page for speed involves determining what CSS is above the fold, inlining that part in the header, and loading the main stylesheet later using the above method.
I recommend doing some searches for "above the fold css" and check out Google Pagespeed Insights.
https://developers.google.com/speed/pagespeed/insights/
Have a look at the following site http://www.soe.gr.
The whole page has been built with CSS Page Builder Magic 2 (projectseven.com).
Every button is a link to a different .html page.
However, I do not know why every button press creates a flash effect in the page, the background changes instantly color and generally it gives an impression of abnormal operation. I have not met any site with such behavior except some pages inside projectseven site.
Do you have any idea why that happens? Is it something wrong with Page Builder Magic approach?
I am new to Web Development world and I want to know if there is any problem with these guys.
Thank you very much
I checked it out, it doesn't behave abnormally at all for all those effects you have there, I checked out the size of one of the images it is about 250kb, then imagine the other images which I assume are of the same size, and they are all going to be loaded when the page loads, you definitely should expect some effect
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 seems rather a common problem, however I can't find any reliable sources on this.
Once in a while Chrome will display a stylesheet-less version of page for like 2-3 seconds and soon after the page is displayed correctly. It can affect the very same page once in every 20-50 refresh and its not tied to a specific site. Happens all over the place. There are some threads about this here and there, but I have yet to find a full explanation.
Is this a bug? Feature? Is there a way to prevent Chrome from behaving like this on the client or perhaps server side?
In my experience, this happens when the network connection is poor and the page is (necessarily) loading slowly. The page's HTML will render first, and other assets called for within that HTML (like stylesheets or images) are rendered only after their calls are complete and their respective files load.
I have noticed this as well. It's definitely a bug. It seems to be this issue:
http://code.google.com/p/chromium/issues/detail?id=75761
You can "force" the stylesheet to load by opening the inspector (ctrl+shift+i).
shift + f5 should reload the page and the referenced stylesheets
With a normal reload it will only reload the page itself, and incorrectly assume that the stylesheets in the cache (the ones that never loaded in the first place) are correct.