I have an application running that is using the YUI js framwork (v3.0). The user can click a button within my app which will upgrade them to the latest version of the framework (3.4). The problem is that on ie8 I'm getting some strange javascript errors. After debugging it seems that an old version (3.0) of the loader-min.js file is retrieved from the browser cache as it still being used by the YUI object when it's instantiated. So during my upgrade I create a script node, add the location to the new loader file (3.4), and then insert it into the head section. Think we're all familiar with this technique. However, when the user navigates to the next page, the file that is loaded is lost and the old version (3.0) still remains in the cache. Have verified this by using developer tools and looking at all the javascript files the app has loaded.
I've tried lots of different things to get the new version (3.4) I'm loading to override the version currently in cache, which will fix the javascript issues. I've tried adding a unique string to the end of the file name that is being loaded which is typically how js files can be 'versioned'. I've made sure the Etag and Cache-Control headers for the new version I'm trying to load have been set. Nothing works and I'm banging my head against the wall.
One small restriction, I have to use javascript to try and load this new version of the loader-min file. I cannot add a simple script tag to my html because of how the upgrade process works. Any thoughts, ideas, pointers as to why IE8 will not cache the version I am loading dynamically?
Caching problems like this are normally solved by giving the new version of the script a different filename (often containing the version number) and changing the HTML that includes it to reference the new filename so that it can never be confused with the old version by a caching system.
In fact, this version system should probably be used on all external script files so when you upgrade them, you can make sure that viewers get the new version immediately and old/new versions of the scripts are never accidentally mixed by a caching system.
Related
I have a .js file that is being statically served in my application. This file will continue to change through the course of development-
I had made some changes to the file this morning as I normally do. Debugging the project, I discovered that the changes in the .js were not reflected- i.e. the browser was using an older version of the javascript file.
I have been working on this project for a few weeks and the changes in the .js file have always been reflected in the next debug until today. I have tried in both Chrome and Edge.
What gives? I'm puzzled about the change in behavior. I did receive a Windows update overnight, could it be there's a global setting for browser caching which was previously disabled on my system and was enabled by the update. I am aware of cache busting techniques but in the past, I've always just been able to update the a static .js file and the browser has always used the latest .js file.
Hopefully someone else might find this helpful. I was poking around Visual Studio and in the "play button" next to IIS Express, there is a menu option called "Script Debugging" that I happened upon and was set to disabled. I enabled the setting and things are back to working as previously.
I was able to confirm that by disabling the setting, Chrome and Edge use a cached version of the script file.
My guess is a Windows update disabled the setting. Can someone explain how changing this setting in Visual Studio affects caching in browsers?
I have a file that is dynamically loaded by sapui5 as a controller. I have altered my code so that I can leverage Typescript for Intellisense and fault detection.
My JS file is successfully created, and runs correctly in Chrome. The DevTools/Sources/Network window does not list my 'FinalAssembly.controller.js' file, nor does it list the similarly named 'FinalAssembly.controller.ts' file.
I have found that if I remove the '//# sourceMapURL=' line from the bottom of my file, Chrome will eventually list my JS file.
I had read that use of the '//# sourceURL=' line at the top of my file would cause my file to be listed, but it wasn't, further, I read that use of this directive should allow me to vary the name that is displayed in the Sources list, it doesn't. It appears that Chrome is ignoring this directive.
As of today, Chrome indicates that it is up to date at version 66. I have read lots of articles and Github issues over the last 4 hours that indicate that Source Maps tend to be problematic and can fail in some versions of Chrome.
The map file itself works in Internet Explorer, but I can't really see myself developing with that.
Has anybody debugged JS with a Source Map in Chrome 66? Can anybody suggest how I can debug my map file usage in Chrome?
I have placed a very simple test created via VSCode (tsc.exe) at my website: http://www.ia.uk.com/TypescriptTest/default.htm - on my Chrome 66 this one doesn't seem to download the map file at all (Fiddler didn't see any request for that). Doesn't show any TS view of the code. This is not a dynamically loaded library as per my original problem, but does show that there is a problem.
It turns out that DevTools has it's own set of settings. The preferences tab has a "Enable Javascript Source Maps", which was switched off in my copy. I don't recall ever being in that screen, but obviously this box got unchecked.
For normal JS files as in my small example, both JS and TS files are displayed. When the file is dynamic, only the TS file is displayed. This means that if maps are disabled, you get nothing (because the JS file isn't displayed).
Just open devTools and reset the browser.
Make sure your Angular app is up.
If your Angular app is not up, then you can't see the .ts file in Chrome. So you need to first run the Angular app.
I have an asp.net mvc 3 project that I am developing in Visual Studio 2010. In the scripts section I have a library that I wrote. I made a change to the library. However, I notice that the change does not show up when the program is run in the browser. When I look in the debugger of firefox it shows the old version loading. I have tried cleaning the project, rebuilding, building, closing firefox, ctrl f5 on the page. How can I get the current version of the script to load?
There are two commonly accepted ways of doing this:
Option 1
Best option, in my opinion. Give the script a version number. Must remember to change the version number with every release
<script src="mylib_v4.3.js"></script>.
Option 2
The other is nowhere near as good because it can kill caching. Some browsers will re-request the script each invocation. (I really don't know the which browsers have which behavior.)
<script src="mylib.js?version=4.3"></script>
Option 3
The other option is to keep your scripts in a version directory.
Actually, in my PHP code I have
<script src="/js/ver##VERSION##/mylib.js"></script>
and my php code does a replace of ##VERSION## with the release version. This way my build scripts create a directory tree to upload and set paths right. If you have server side support, this method works very well.
Add a "version parameter" to the script reference :
<script src="/scripts/myscript.js?version=0.2"></script>
That method has the advantage of also doing the job when the your application is being used by clients, and you want to force their browsers to get the newest version when you update your app.
Clear your browser cache and disable it.
I try to debug a javascript function called from Generate Thumbnails plugin in Wordpress. The function uses jquery. So the actual call that I want to debug occurs in jquery.
The problem is that default jquery.js inside Wordpress is minimized and therefore obscure. I changed that file with the uncompressed version of jquery.js file in wp-includes\js\jquery.
But when I debug that function with Firebug's debugger, Firebug still shows me the old, minimized version of jquery:
I copied the location of the script file shown in Firebug and opened it in browser: http://localhost/wordpress/wp-admin/load-scripts.php?c=1&load=jquery,utils,jquery-ui-core,jquery-ui-widget&ver=368b0ffbc13bc55b5ae45ad40a5368d9
This time, the true, uncompressed version of jquery.js was opened.
It seems like Firebug opens the old version of jquery. I restarted the Firefox but it wasn't resolved.
What might be the reason of this problem? Is this Firebug related or Wordpress related?
I'd agree with the people who commented on your question - it seems like a browser cache problem.
If it's a test system, one thing I'd suggest is setting the WP_DEBUG constant to true in your wp-config. That'll download the uncompressed versions of the javascript libraries. That has two advantages:
You don't have to copy different javascript files around, and
The file names differ from the standard ones (they have .dev in them, from memory), so you shouldn't hit any caching issues.
I'm assuming there's an uncompressed version of jquery in WordPress. Apologies if there isn't; I haven't checked. But in general I'd recommend this approach.
See Debugging in WordPress in the codex for more information.
I tried to use Firebug Lite (via the bookmarklet and also adding it to one of my web sites).
I seem to get the alert:
Unable to detect the following script "firebug-lite.js" ... if the
script has been renamed then please set the value of
firebug.env.liteFilename to reflect this change
Alot. Especially when I try to close the tab. This happens in Firefox, Camino and Safari.
What I'm wondering is, is this ready for use?, or do I need to copy the code, post it locally and hack it? I already checked the documentation, and it was pretty limited.
I was also looking at the mod dates and the site appears to have been relatively idle since mid-2008.
The javascript file rounds out at 77,305 bytes, so I would think you would not want to use it on a production site unless you were using a dynamic language and could output the script conditionally when you need to do debugging.
(i.e. http://www.somefakesite.com/page?debug=true)
As long as you're only including the file in the page when you are actually debugging, it probably doesn't matter where you pull the script from unless it doesn't work correctly, in which case you would have to modify and serve it yourself.