Internet Explorer 7 (but not 8/9) blocks anything downloading until the CSS file has finished on our site.
We are not using Internet Explorer tests around it <!--[if IE ]><![endif]-->, nor are we using protocol independent URI's (// instead of http://). It is just a straight forward /css/global/core.css link and yet the browser waits until it has finished downloading before commencing.
Are there any techniques to prevent this behaviour?
PS: All the JavaScript is at the bottom, all the static content is hosted on another domain (except the CSS due to it being able to reuse the existing connection after the HTML document, resulting in a faster experience for the user even with additional cookie headers).
EDIT:
The problem is that profiling IE7 with DynaTrace causes CSS files to block further downloads, however with DynaTrace turned off it works. So this is a DynaTrace bug, not an IE7 one.
WITH DynaTrace:
WITHOUT DynaTrace:
Perhaps you hitting the limit for the number of parallel downloads per domain?
I believe IE7's default is 2 files per domain , whereas many newer browsers support 6 by default.
http://www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
Related
Good day.
So, here is my issue.
I'm currently using sharepoint 2010 for web applications, I am supposed to display pdf as part of a web page. Currently, the browser tends to download the pdf file instead of displaying it.
Content-disposition is already set to inline.
I've also used iframe, and src is pointing to custom httpHandler.
I've already added "application/pdf" MIME type in the list of AllowedInlineDownloadedMimeTypes as per the advice in this link http://www.pdfshareforms.com/sharepoint-2010-and-pdf-integration-series-part-1/.
However, the application still failed to display it, and it prompts the user to download the file instead.
I'm using mozilla firefox v12 and ie8 to test the application, they both exhibit the same behavior.
What else is missing? Thank you.
It's important to remember that not all browsers, especially older ones like Internet Explorer 8, have the ability to render PDF content inline. In these older browsers, this was generally accomplished through plug-ins like Adobe Reader or Foxit being installed on the client machine.
Basically, if you are using an older browser, your users will likely need one of these (or a similar) plug-in installed. Otherwise when the browser encounters a PDF file, it will serve it to the user, as it doesn't really know how to deal with it.
There is also a chance that this could be a permissions / settings issue similar to the one addressed in this related question. You may want to review over some of the discussions within that thread as well as this Sharepoint 2010 one, which details a a setting called "Browser File Handling" and how it's default value of "strict" can affect how PDFs and other files are accessed.
He came across the solution while looking at the "Web Application General Settings". There is a setting called Browser File Handling and by default it is set to strict.
Ok, this might be more of a networking question than programming but I'm not really sure what is going on here:
I'm having intermittent problems with my site where I am only partially downloading javascript documents. By intermittent, I mean that on the same browser (Safari in this case) I can view that javascript file in my browser and refresh the page and still only see the file partially downloaded, but another browser (Chrome) I see the file correctly downloaded. Clearing the browser cache has no effect either.
The odd thing is that it appears to be location specific, as when I check the site from home, still using Safari, I have zero issues. The problem also seems to be machine independent, as I also occasionally get the same javascript errors on my iPad (when at work on the same network).
I'm 100% sure it isn't a syntax error or anything with the javascript, as the file that fails most often is a minified copy of jQuery (downloaded from their site, though hosted on my site's server)
I have tried turning off mod_deflate on the idea that it might be compression that was causing the issue, but this had no effect.
I have spoken to the network admins at both my end, and the hosting server end and they claim that it isn't anything wrong with their network, though they are possibly just deflecting a complex issue.
Any ideas on how I can narrow down the issue?
I have tested my pages in Firefox & IE and looking at Firebug in Firefox for some reason some images are taking a long time to load. They are not very big in comparison to the ones which are loading quicker.
Attached is a screenshot of Firebug.
I especially notice it in IE with the progress bar at the bottom of the page, it just sits there saying loading image...
Could it be the path or something which is http://localhost:49211/Content/_layout/images/bg-footer.png for example
I guess you are running the site in VS (using Cassini) this is really slow, I had the same issue. I used Chrome, as it shows when the browser makes a requests to the images and file, which showed a large delay on Cassini delivering them.
if this is a case, try putting you site on the local IIS (if you have an instance). the site should run a lot faster.
It may be related to the number of available connections. It is just sitting there since it is waiting for a connection.
With older browsers there was a limit of 2 connections from the browser to a site.
I'm working on a site that will go on my company's intranet. I developed it locally on my computer, checking it in different browsers and on colleague's computers, and when it was done I handed it off to IT. They put identical copies on a staging server, and on the production server. This is a site built only with html, javascript, and css. No server side scripting. It also uses a DWF viewer plugin from Autodesk. It is a single standalone page (not part of a CMS) that allows users to load drawings into the viewer and then click to see info from a database of space info saved in a series of js arrays (the space DB software spits out a js file with all the info listed in array literals, creating a crap ton of global variables - ugh, but I digress).
When I followed their links (using IE 8) the version on the staging server looked as expected, but the layout is hosed on the version from the production server. Specifically, it seems like a div that is supposed to flow to the right of a div that is float: left is displaying below the floated div at full width, as though it was clear: left (which it is not). It also has the wrong height.
I downloaded the files from each and they are identical to my local version. Frustrated, I cleared my browser's cache, restarted my computer, checked it on a colleague's computer who also has IE 8. All the same issue. Staging server good. Production server bad.
Finally I uninstalled IE 8 and looked at it in IE 6. Both versions looked fine.
So, to recap. Two different servers. No server side scripting. Identical files. One browser agrees they are identical, the other does not. What could cause this?
Have you checked that IE8 isn't rendering it in compatibility view (IE7 rendering)? By default IE8 renders things in the "Intranet Zone" in compatibility view with everything else in normal mode.
You can change the mode with the little broken page button to the right of the URL bar.
Apart from the compatibility setting, other things that could differ from computer to computer for an identical page:
Font size. Windows allows system-wide font resizing, impacting layouts. It could account for the second div falling underneath the first one.
Resolution. Could it be a resolution issue? Could also account for the div problem.
I'm using the WebDevHelper toolbar for Internet Explorer to troubleshoot HTTP requests/roundtrips on my SSL site and noticed that IE re-downloads my CSS :hover images every time they are triggered. This causes a huge amount of roundtrips.
How can I prevent this from happening?
Edit: All static content is served with cache-control: public, so images, javascript etc. are cached in Firefox and Chrome. This problem is IE specific.
Serve static content via http, sure, but don't do separate images for :hover states. Proper css image sprites should be used. It's just good practice all around, via https or http. There are tons of resources available for creating sprites. Supposedly SpriteMe, [ http://spriteme.org/ ] is an attempt to automate css image sprite creation.
If the images are being delivered from a different hostname than your main page, then you're hitting the artifact described here:
http://blogs.msdn.com/ieinternals/archive/2010/04/21/Internet-Explorer-May-Bypass-Cache-for-Cross-Domain-HTTPS-Content.aspx
Well there are multiple issues according to other Stackoverflow posts. FireFox 2.x also has this problem. But FireFox 3.x doesn't.
Will web browsers cache content over https
Also in Internet Explorer, you go to Tools > Internet Options > Advanced tab > Security section > Do not save encrypted pages to disk. It appears to be unchecked by default in IE6, 7 and 8.
Content served via SSL will not be cached for security reasons. If you want something to be cached, serve it via HTTP.
Have you tried adding to the header for those type of static files.
P3P: CP="CAO PSA OUR"
I know this works with in IE to allow storage of cookies through framesets and stuff. Not sure if it works with static files under HTTPS.
I know it sounds weird...
try to put a url to something that isn't exists (404 error). after this, all the rest of the images will be cached.