We are having a problem where IE6 (the only browser we have noticed this happening on) seems to be caching an empty version of our main stylesheet. The only way to resolve the problem is to request the stylesheet directly by typing the its url directly into the browser, and then when you refresh the page, it will appear with the styles. About a week or so later, it will happen again.
This isn't happening to all users, but we can't figure out why it is happening.
We are running IIS on Server 2003, and this problem started happening a couple of months ago (never had any problems before that).
I appreciate any help you can offer.
Paul
*I have looked closer and now it is doing the same for certain Javascripts as well.
12-12-2008
Thanks for the help Grant, IE is fairly locked down, but have checked what can be changed and it is fine, and no extra plug-ins are installed.
If you Ctrl-F5 or kill the temp files it doesn't seem to do anything. It's not until you request the file directly that it actually it actually fixes the problem which does indicate that there is a problem with IE caching a broken or empty version. Unfortunately, I must now wait until it happens again and I'm going to check the log files on the server.
Again thanks for the help.
I can't give you a direct answer, but I would start by installing Fiddler and investigating the Content-type and last-modified response headers of the files that are causing you problems.
Also take note of the If-Modified-Since and Pragma request header values.
As well, I would check the Accessibility settings in IE (Tools > Internet Options... > Accessibility).
In addition, ensure they haven't installed any add-ons that might be causing this type of behaviour. An unrelated example: a couple of years ago, we had a problem where IE6 stopped sharing Session cookies between browser windows for one of our users. It turned out to be some cursor add-on to IE causing the problem.
Obviously if your users are using a locked down copy of IE, the above suggestions don't apply.
Lastly, what happens if the user holds CTRL and hits F5 to refresh the page unconditionally, do they get the latest copy of the stylesheet and JavaScript files then? And have you tried clearing the browser history completely and loading a fresh copy of the page (perhaps the cache itself is corrupt somehow)?
I also had the same behaviour once. However, I was using a php generated stylesheet, with the headers and every other information (client-side cache, server-side cache, compression) finely tuned in PHP for optimal performance.
Worked like a charm, but it seemed that IE6 did not load the stylesheets on some computers, in a non-reproducible way. I didn't have the time to investigate,and I didn't have access to the problematic computers, so we went back to plain-old simple stylesheets, and everything went back to normal. We said it was firewall-related, but I'm sure there's something nasty hiding inside IE6.
I beg to know what it is...
Related
I'm trying to create a web application for university. I've been doing fine with XAMPP, using Visual Studio Code and Sublime Text as my editors and so far so good. However, a couple of days ago, I ran into what seemed to be a bug.
While accessing "localhost" on Chrome, the website didn't seem to reflect the last changes to the HTML and CSS code. I also modified some Javascript and it didn't work either, the website stayed the same.
Not even simple things like changing a colour on CSS or adding an alert window on Javascript would appear on the actual web.
Inspecting the website in Chrome shows the old documents and source code, however, when going to the "htdocs" folder at XAMPP, the documents were successfully changed, and no matter what I did, relaunching XAMPP or Chrome didn't fix it either.
I decided to give up for the day and committed the changes to my GitHub repository. To my surprise, I refreshed the website afterwards and it worked.
I thought it was an isolated bug, but it seems like it is not, it happened today again while working on a completely different project.
What's more surprising, this behaviour doesn't seem to happen on Firefox or even Safari, I've tried both and it seems to be fine. However, I prefer the tools included in Chrome, so I'd rather use this one.
Has anyone else had the same issue? If so, how did you fix it? Or in case it is intended to work like that, why is it? I don't see any possible scenario where this could be useful.
Thank you in advance.
This is more of a workaround than a solution really, but you could just try ctrl+F5, this will clear your cache and you're good to go again.
This is probably the single worst Chrome bug when you're doing incremental small changes but Chrome loads it from the cache and not the original files.
What does Ctrl+F5 do?
This ignores the page saved in the cache and does a fresh GET. This should serve well enough as any changes made will be reflected in Chrome on doing so. Or you can manually clear the cache from the Chrome settings.
I'm doing some very simple web dev and using chrome's debugger. The included javascript never seems to update when I modify the source. I can delete the contents of the whole file and it still loads stale code (unless I restart chrome). If I remove permissions on the file, it notices and won't load the page but when replacing permissions the old code is back. This happens both when fetching via http and the local file directly. No amount of spamming reload or ctrl-F5 works. I've tried clearing and manually deleting the cache and even setting the don't cache option in the developer options. I don't think chrome's in local modifications mode but I can never tell (this "feature" is amazingly buggy if not sometimes quite desirable). I don't have this issue in firefox but specifically want to test chrome at the moment.
Has anyone seen this before? What are the common causes? What can I do to prevent this happening?
I'm running fedora 18 with google-chrome 31.0.1650.39-1 - and after noting a newer version - 32.0.1700.19-1. Both have the same issue.
I think ctl-shift-r does a "hard reload," ignoring any cache.
I normally get this problem with Dreamweaver, the new code refreshes fine in the dreamweaver window but when I wanna test on chrome it loads the old code. It generally just takes a couple refreshes for the code to catch up - I assumed the problem was because I was running the files off an appache server which could be causing the delay however it's still local
I have a feeling that our Sitecore install is messed up with the configuration but I can't point out where. Things happen at random in the Sitecore client. For example -
Clicks in the Sitecore client do nothing.
If I log out say after opening up Log Viewer and then log back in, I only see the log viewer and no other options.
Clicking on a link would log me out.
If I am logged in and another admin tries to log in with his/her credentials, sometimes they see my credentials.
IE 8 continuously throws 'scWin' related javascript errors.
The first 4 are consistent across firefox, chrome and IE. The last one is totally an IE occurrence.
An IIS reset fixes these issues but then these occurrences start happening again pretty quickly.
I've looked at log files but I don't see anything there. What else can I do here?
This sounds really strange. Are you sure you are not infected with some kind of malware or some virus?
Does it occur on every pc that is working with this solution?
You could try to remove the Sitecore files and copy fresh files from the install zip to see if that resolves the issue.
This does sound rather strange... First thing I would do is make sure you followed the IE setup guide exactly, to make sure it's not your browser causing problem. Javascript is definitely enabled, yes? The fact that it happens in Firefox also though means this probably isn't the real issue. Martijn might be on to something... have you tried using another machine entirely to access the site?
It turned out to be .NET caching - section - was turned on and was causing all sorts of issues. We removed this and it all worked.
I manage an e-commerce site running under SSL.
The problem is happening on the final page of my site's shopping cart that loads under SSL. The problem is that Internet Explorer 8.0 (including version 8.0.6001.18702 and other versions of IE8, but reportedly not all versions of IE8) complain about at least one non-secure element loading, which is scaring away some of my prospective customers. IE8 displays a dialogue box after the page has apparently fully loaded (with seemingly no missing images) that says:
"Security Warning: Do you want to view only the web page content that was
delivered securely? This webpage contains content that will not be delivered
using a secure HTTPS connection, which could compromise the security of the
entire web page. (YES/NO)"
I tried to track down all invalid images and links that may be loading via HTTP, but no to avail. Firebug Lite shows nothing non-secure. I'm starting to think this may be a bug within IE8 that was corrected in IE9, which does not complain.
TO REPRODUCE THIS ERROR: Click here using IE8 (or Chrome) to add an item to your shopping cart. On the resulting page, click on the GREEN button on the right that says, "Proceed to Secure Checkout." You will notice that you see the above "Security Warning" from IE8.
QUESTION: How can I determine what the browser is attempting to load non-securely, or how can I suppress the "Warning" message?
UPDATE: It seems the "Security Warning" is due to the suspended JavaScript execution on this page. But the same question still remains. How can the "Security Warning" message be suppressed or "debugged"?
Wireshark is usually pure overkill if its used to debug standard web browser based applications because it provides way to many information which are usually not required to exactly pinpoint the problem. A much better solution in this case would be to use Fiddler which is a simple yet a very powerful debugging proxy which is, aside from its many useful functionalities, also able to clearly distinguish between SSL and non-SSL traffic.
Its also able to simulate a "man in the middle" testing environment which effectively allows it to decipher SSL traffic. Of course the generated "on the fly" certificate is clearly marked as untrusted in all browsers to prevent misusing it.
EDIT: I followed the given instructions in order to provoke the problem yet I had no problems with any kind of security warnings in IE8. Also Fiddler is showing that all the resources are loaded through SSL.
I know this is an old post, but since there wasn't an answer posted that fixed my similar situation, I thought I'd shared what I found in case anyone else stumbles onto this page. If you use removeChild() to remove an HTML element that contains an inline style setting a background image, the warning occurs in older versions of IE8. You can get rid of the warning by moving the inline style setting the background image into a style class set in the HTML head or external style sheet.
See this Microsoft KB Page, which says the glitch only occurs in IE6 and IE7, but it happened to me on IE8 on XP, too, and the same fix worked.
I ran into a similar problem in the past with IE8, and what it appeared to be was an issue with cached items. I wasn't able to completely pin it down because, like you, I checked every asset and found nothing that was not loading via SSL. However, I noticed that if I prevented all caching and forced IE to load all assets from the server, the warning disappeared.
I don't know if there's a bug where certain items pulled from cache don't get recognized as secure, but it seemed to have something to do with it.
Disabling caching is obviously a bad way to solve a problem that only impacts a subset of browsers, but it might be a tip that could lead you in the right direction.
Click checkout at the top of the page?
Not in https anymore is it?
If you have SSL-backed pages, then every assets (js, css, images) should be served by HTTPS protocol too. It's the same behaviour for 90% browsers
As Jon stated:
If you use removeChild() to remove an HTML element that contains an inline style setting a background image, the warning occurs in older versions of IE8. You can get rid of the warning by moving the inline style setting the background image into a style class set in the HTML head or external style sheet.
While the Microsoft KB Page does provide the fix, the best solution is to implement it as follows (place in a script at the bottom of your page):
Ext.removeNode = Ext.isIE ? function(){
return function(n){
if(n && n.tagName != 'BODY'){
n.outerHTML = "";
}
}
}() : function(n){
if(n && n.parentNode && n.tagName != 'BODY'){
n.parentNode.removeChild(n);
}
}
Our website uses the superfish jQuery plug-in for our menus (http://users.tpg.com.au/j_birch/plugins/superfish/), and they work fine in Firefox, IE6, IE7, Safari, Chrome, etc. ... and even in MOST IE8 installations. The problem is, in some IE8 installations, the menus don't work (they highlight on mouseover but don't drop-down the menu).
This has me baffled. In addition to a couple customer complaints, I've got one (Windows XP) machine in-house that reproduces the issue. However, I also have another Win XP/IE8 machine in-house which doesn't experience the problem. I'm used to dealing with JS/CSS issues between different browsers, but this issue between two machines on the exact same OS and browser is a bit much.
Oh, and just to further obfuscate the matter, the machine that is reproducing the issue shows no errors, Javascript or otherwise (even when I go in to developer mode). So ... does anyone have any suggestions on what could be going on?
As far as I know neither of my two "test" machines have any special plug-ins or anything which would cause the problem, they're identical in terms of everything that matters, and there's no JS error occurring that I can check the stacktrace of or anything. But this isn't just some crazy problem that's unique to my test machine, because as I said some customers have reported it too.
Any help would be appreciated.
Can you try setting the IE7 compatibility mode and see whether the problem persists?
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
(into the head of the document, best would be directly after <head>)
If it works then, you'll definitely know that it is some IE8 specific rendering issue. My first bet would be that your menu uses CSS hacks to set certain IE specific settings, unaware that IE 8 (fortunately) behaves differently and more standards-compatibly than its predecessors. If that is the case, you would have to use an IE8 specific CSS hack (or, better, specific style sheet) to "re-fix" those settings.
But first, check whether this really is the problem using the compatibility view.
Try turning off compatibility view: Tools -> Compatibility View -> Uncheck. I too struggled with this for the better part of an afternoon until I just tried this on a whim and it worked!
Try clearing Internet Explorers cache. Go to Tools -> Internet Options -> Browsing History section -> Delete ... -> Temporary Internet Files -> Delete.
For reasons unbeknownst to me, I've seen all IE versions start behaving strangely when the cache has been full or not cleared for a long time.
I have a Windows 7 64bit Home premium. The laptop encountered an issue called SupperFish.
First I tried resetting home page to different URL’s. IE8 kept returning to SuperFish.com.
Look in Add and remove programs, was not there, Not in startup or MSCONFIG (startup).
Third cleared Cookies then History. No help. Forth ran Microsoft Security Essentials, SpyBot S&D, Norton Constant Guard , Ad Aware. Problem is still there, Looked in C:\Program Files and found a folder called SuperFish, in that folder there was an Uninstall executable. I ran the Uninstall using a administrator account, and the problem is no longer showing up, after several hours of use.
not sure if it is a solution and that this is what you meant by not knowing how to fix it... but I cleared all my cache/history/cookies etc. from IE8 and if immediately worked (looking the same as other browsers).
maybe a fix for now but that worked...
This issue wound up going away without us ever figuring out what caused it, so now even if we did want to figure it out we can't (as we can't replicate). Therefore I can't really mark any of the above answers as correct, but since they exist I can't delete this issue either. So, I guess the best I can do is file this answer, but it's a rather unsatisfying one; sorry.