It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.
Related
Codekit 2 does seem to be refreshing in any browsers. I've literally just installed it and been setting it up to my own preferences.
I use my Mac's hosts file to point http://localhost.sites to localhost. I've never had an issue with this in the past (I just set Codekit to refresh on any URL including the word localhost).
Now in the new settings file I'm slightly lost as to where to put it... after a load of mucking about I think I'm in a real state and here are my current settings:
Can anyone shed any light on this? Codekit is not refreshing the browser (all files are compiling fine).
I was having the same issue, #Djave.
Now, while I won't assume you make the same mistakes I do, I found that some errors in my
were causing Chrome to ignore the refresh. Specifically, the closing tag was missing. Instead, I had
<script... />
instead of
</script>
Hope you found the issue on your end.
As Bryan from Incident 57 told me, the refreshing process in Codekit 2 is totally different to the refreshing process in Codekit 1.
Codekit comes with its own server which you are required to run. You can click it in the top right hand corner of the program and it will launch.
You need to have this running to get going. If you have PHP files (or other server side code) Codekit won't run it – so this is where you need your external server running but it is important that you still view the site you're testing at the address given i.e. http://djave.local:5757.
For a far better explanation of all of this you can watch Bryan the creator of Codekit walk you through this in this video here.
https://www.youtube.com/watch?v=YUgH0jlYur0
RESOLVED
Unbeknownst to me, Cloudflare defaults to caching all css/js files for 4 hours.
Scenario:
I add this to our front page:
<span class="test">hullo!</span>
and this to our css file:
.test { font-size:2.0em; }
I do a web deploy, OR full publish to Azure and the span appears on the front page, but not the styling. The css file for some reason does not get updated. FF, IE, Chrome and Safari all confirm it. However, after a seemingly arbitrary time, the css file get updated.
Even when I remote into the Azure VM and restart the app, the styling is unchanged. The app is running on one instance, one role. No Azure Caching is setup. Adding a querystring param to the css file link does not help. Seems like a caching issue but no clue how to resolve.
Any ideas?
"We are using Cloudflare which has a default set up to cache all CSS and JS files. It purges the cache every 4 hours which resulted in the arbitrary updates. So, even though I was adding a new query string to the end of the css file, Cloudflare still cached the old one"
Just a quick note that you should go to CloudFlare Development Mode when making changes to the static content files on your site. You can get to Development Mode to bypass the cache by going to: settings->Development Mode. You also have the option of purging your cache as an additional option, which we would only recommend if you really want to purge everything.
Looks like it's cached by your browser. Can you please try navigate to your site and press Ctrl+F5.
Maybe you can use Fiddler to see if the CSS had been cached, or not updated, or some error when download.
This issue is resolved.
We are using Cloudflare which has a default set up to cache all CSS and JS files. It purges the cache every 4 hours which resulted in the arbitrary updates. So, even though I was adding a new query string to the end of the css file, Cloudflare still cached the old one.
I have dealt with this and I will tell you that from my experience in Chrome you can set a setting that disables the cache in the developer tools, however, I've noticed that unless you have the dev tools window open when you hit Ctrl+F5 it doesn't reload the cache. In IE there is a global setting in the dev tools that will make it redownload everything every time. In Firefox there is also a setting in the dev tools that will require it to download and not use the cache.
One way that you can test this, and how I test this, is by running Fiddler and watching if it does a full download of all your files or if it's caching.
From what I've experienced is that this is truly a browser caching issue and not anything to do with Azure.
I'm running Selenium in singleWindow mode and IE8.
If i start IE8 manually the IE8 mode is set, but when i launch it with Selenium, the mode set is IE7 using the compatibility mode.
Anyone knows why the compatibility mode is not the IE8 view when launching the browser with Selenium?
Or, how can i disable totally the compatibility mode in IE and force it to use always the IE8 view?
I've given the question a +1 because it's a very good question -- it's not obvious how to do this, and if you need to test both modes, then it is a necessary thing to do.
You could get the site to serve <meta http-equiv="X-UA-Compatible" content="IE=7" /> within the page when running the tests. This should force the output mode.
Obviously, that's not ideal, because it means changing your code to produce the meta tag on demand. I'd normally consider it a bad thing if you're having to change the main codebase in to add code for the specific use of your test suite, but in this case I can't see any other solution.
Given that we've decided to go down this path, you could write your code to accept a specified argument in the URL that triggers the meta tag to be served. The IE7 tests could then be written to send that URL argument.
By the way, it's worth pointing out that IE8's IE7-compatibility mode is not 100% identical to IE7; it has its own quirks and bugs which are distinct from those of a real IE7 browser. For the most part it should be fine, but it's worth being aware of this if you're expecting your tests to confirm that the site works in IE7. See this blog post for more info
I have some workarond solution for this, I use it regularly:
In internet explorer goto:
1. Tools / Compatibility view settings.
2. At the Add website input textbox add your website url.
Hope that helps, best regards,
Peter Nadasi (HUN)
Back in the earlier days of the internet I remember that in certain browsers, every time you downloaded an image or a file, the URL of where that file was downloaded from would be written into that file's properties (I guess the summary tab?). I think Netscape v2 did this if I remember correctly.
I really miss that kind of functionality as every once in a while I'll run into a neat little program stored somewhere in the depths of my hard drive and wonder where I got it from originally.
I googled around but I'm not quite sure what terms to use to describe what I'm looking for. So I'm wondering if anyone knows of a Firefox plug-in or something similar that would do this?
If you use the DownThemAll! extension for Firefox, you can tell it to prepend the URL of the site to the downloaded file name...
thus you end up with files like:
download.com_utils_compression_ABCD32.exe
It also works really well when you want to download/queue a bunch of files.
You download http://example.com/foo to ~/Desktop/foo, and you want to see the originating URL in the properties of the local file foo?
Back when I used OS X, I remember Safari used to record the original URL in the resource fork of the downloaded file. Can't remember what the named fork is, well, named, but it'll show up in the properties panel from Finder. Since it's there, Spotlight will probably index it, too, but I haven't used OS X since 10.3.
If you use Opera, and haven't cleared the file out from your download manager, select the download and it'll show the original URL that the file is from in the properties pane.
Is this what you want? If so... well, I don't know of a similar Firefox extension, but it'll clarify the question.
For the IE Browser I use the hell out of Fidler to look at all traffic going across the wire.
For FireFox, you can use the FireBug plugin. There is a "Net" tab that will show you request information that is going across the wire.
Most of the time you can use one of these tools to see what URL was requested in order to start a download. You can also view all the get and post information that might need to be sent in order to have your request succeed.
Fidler is here: http://www.fiddlertool.com/fiddler/
FireBug is here: https://addons.mozilla.org/en-US/firefox/addon/1843
Best of Luck!
I'm trying to load an image from the Firefox cache as the title suggests. I'm running Ubuntu, so the location of my cache is /home/me/.mozilla/firefox/xxxxxx.default/Cache
However, in the Cache (and this is on Mac, too) the filenames are just ridiculous combinations of letters and numbers. Is there a way to pinpoint a certain file?
You should take a look at the source code of the CacheViewer Add-on.
Download the file instead of installing it (right click and save as) and then extract it (it's just a Zip file, even though it has a .xpi extension), then extract the cacheviewer.jar file inside the resulting chrome folder. Finally go into content and then cacheviewer to find the javascript and XUL files.
From my brief investigation, the useful routines are in the cacheviewer.js file, though if you were hoping there would be a simple javascript one liner for accessing cached items you're probably going to be disappointed. The XUL files (which are just XML) are helpful in working out which JS functions are called to perform particular tasks. I'm not too sure how all this maps into Greasemonkey, rather than the extension environment, but hopefully there's enough code to get you started.
Ummm, that really is an internal implementation detail. But I suggest looking at how about:cache?device=disk and about:cache-entry?client=HTTP&sb=1&key=https://stackoverflow.com/Content/img/wmd/blockquote.png are implemented.
Also, http://www.securityfocus.com/infocus/1832 gives details, too. Note that Firefox doesn't use a separate file for everything...
And of course, Firefox may change the format at any time.
Just give your img src= attribute the full URL. If the image happens to be cacheable (the server sends an appropriate Expires: or Cache-control: header, for example) and it's already in the cache, Firefox will not hit the network.
HTTP caching is supposed to be invisible. When you're generating content, you generally shouldn't worry about it.
You can point REDbot at a URL to see all sorts of delicious information about its cacheability.