This has been a problem for a long time and I've never found a solution for it and while other questions on here are similar, they are not exactly what I'm seeing.
The problem is that the SOURCE used to step through the code does NOT refresh on every page load. Yes, I have disabled the cache - but it is not the browser cache that is the problem, it is the DEBUGGER SOURCE cache.
In my webapp (Struts2 and Tomcat), I have the main page with title bar and left the menu. The center content is an iframe that loads all the appropriate JSPs. I use one 'action' for most of my navigation with different results displaying different pages. The problem is that the NAME in the chrome debugger SOURCES pane does not change as I navigate. The actual page changes, but since the name doesn't change, Chrome does NOT bring the new source into the debugger window. So what happens is if I have 'debugger;' on line 200 in the page being loaded, it stops, and shows the 'source' - but its the OLD source at line 200, not the actual source that is running! If I right-click on the old source file in the SOURCES pane, and "Reveal in Network panel" the real source is shown here as it really was loaded from my server, BUT the debug source does NOT change.
Question: How do I get around this bug in Chrome and force the source to reload in the debugger display?
UPDATE: No, this is not the same as that other question. The answer by David Fahlander seems to fit what I'm saying. The ACTUAL javascript source IS refreshing and is shown correctly in the RESOURCES and NETWORK panes. But in the SOURCE pane where actual debugging is done, the new source is NOT refreshed. And its hard to debug code you cannot see!
Maybe try the old fashioned method of adding an URL query parameter with, say current time in ms? Something that your app will ignore, but Chrome will treat it as a new page? e.g. https://example.com?time=1594125425508
Related
I have a php page that hangs for 3-10 seconds after the page loads, you can't even scroll up or down, or close the tab when this happens. (the chrome loading gif still loops tho) Happens in Chrome and IE.
Chrome Timeline: http://imgur.com/wF5Pioz,KRbnxIm#0
Shows ContentVeil.js repeating over and over. I think it is client side(?), I did a grepWIN to search for ContentVeil, with no luck, and it doesn't show up in Chrome Network tab.
Chrome Profile: Second image, from above link.
I think this shows the issue at the anonymous function from meta-boxes.min.js, ln 1.
meta-boxes.min.js: http://pastebin.com/yqtJyqB1
Unfortunately line one is a function that encapsulates the whole script. I don't know js very well, I tried to just remove each function one by one but that just created more errors.
Any ideas on how I could find the source of the problem would be much appreciated.
It's part of the Evernote web clipping extension, and it's hooks DOM events, causing massive slowdowns if you are doing large amount of dom changes.
I'm working on some dashing widgets in a dashboard project.
Normally if I work on a coffeescript and I save it, I have to reload the page in the browser, and I can see the effect of my changes in the widget.
For some time the change won't do any effect in the browser. I thought, it may be a browser cache issue and I tried clear the cache, but nothing changed. I tried another browser, same issue.
I can see my changes in the browser only if I change the classname off the widget.
Is there any simpler method?
I encountered a similar issue. The widget would not refresh to reflect my html changes (new <h2> tag). Restarting / clear-cache were the first things I tried. I use Chrome and I found this note in the Dashing-Workshop :
Note: Chrome is sometimes weird, and it's possible that your browser isn't showing the number anymore in the widget. If that's the case load dashing in a brand new tab to clear the cache.
I resolved my issue by turning off caching "Developer Tools > Networking > Disable cache [x]"
It shall work, Use chrome developer tool to debug it
console.log to print to console
use inspect element to see the html/css
So, I have a script called "engine", and after much headbashing and (futile) debugging, I've found out that GC simply isn't reloading it!
This is how I include it in the webpage (inside the <head> element):
<script type="text/javascript" src="engine.js"></script>
When a put 10 console.log("asdf");'s at the start of the script, it's like they aren't there. When I went to the "resources" tab in the GC console, I saw that no changes are being applied whatsoever to that script! Hlep? Would putting a + "?" + new Date() at the end help?
The universal solution that works in Chrome, Firefox and IE is cleaning the cache via Ctrl+Shift+Del (on Mac ⌘+Shift+⌫).
Chrome solution #1
Open Developer Tools (F12 or ⌘+⌥+i, or right-click → Inspect).
Select the Network tab and tick the Disable cache checkbox.
Reload the page.
❗️Note: The cache will be disabled only when the devtools window is open.
Chrome solution #2
This only makes sense if #1 is not used.
Open Developer Tools.
Click the Settings cogwheel icon in the bottom right corner.
In the dialog that appears, select under the Network subsection the Disable cache checkbox: from now on the cache will be skipped when the devtools window is open. When the devtools windows is closed caching will work as usual.
Chrome solution #3: empty cache + hard reload
Open Developer Tools (otherwise the menu in the next step won't show).
Click and hold down the Refresh button, and then select from the dropdown Empty Cache and Hard Reload.
Modifying javascript code
A browser-agnostic solution which could be used for debugging is to append in your server-side code a randomly-generated version string as a query parameter, i.e. call your script as:
<script type="text/javascript" src="myscript.js?ver=12345"></script>
This trick will force the browser to reload the script when the value of the ver parameter changes. If you make ajax requests then you can append "?ver=" + new Date().getTime() to your URL.
NOTE: Don't forget to remove the parameter when you are finished debugging because in production you most likely do want the scripts to be cached. It is a common practice though to generate a new timestamp on each new build — this can be used in production, and will ensure that after a new deployment the clients will always get the updated scripts.
Unlike all the above solutions this one will work even when you have some sort of caching (e.g. redis, memcached, varnish) or CDN (e.g. akamai, cloudflare, cloudfront, etc) between the client and the server.
It is possible that the script is cached so the old version is loading from cache. If you want to make sure you get a new version, you can force a browser reload, clear your browser cache or change the name of the script or put a different query parameter on the end of the filename.
This bugged me as well; CTRL+F5 or SHIFT+F5 never worked...
The only things that works is opening your dev tools (hit F12), and right-click the reload icon next to the address bar and then selecting either "Hard Reload" or "Empty Cache and Hard Reload"
As I said in the comment I guess it's a cache problem, a CTRL+F5 should be enough, in case it is not go for CTRL+SHIFT+CANC and clear browsing data. However sometimes it's the server that has some kind of cache, I say that because with IBM WebSphere I often get cache problems that I can't resolve with a simple F5 on my browser. I just have to wait for my web server to "refresh" itself.
In the latest chrome stable 21st Oct 2016.
Open Developer Tools (F12 or right-click > Inspect or vertical ellipsis icon in address bar right corner > More Tools > Developer Tools).
Click the vertical ellipsis icon in the top right corner of Developer Tools navigation bar > settings.
In the Preferences section find the Network > Disable cache.
When you try this public page: http://slim.nl/shop/default.aspx (update: meanwhile this site has changed such that this question's behavior cannot be tested anymore there), you'll notice a menubar. If you hit F5, the menu in that bar disappears. Same when you come to that page via the Back-button in your browser. It only happens on Firefox (seen on versions 3-7). Using Ctrl-F5, the menubar reappears.
To the best of my knowledge, all JavaScript events that fire when loading a page, including any AJAX cycles, should also fire when refreshing a page with F5 or coming there via the Back-button. What's happening here?
I'd like to know from a programmer's standpoint what the difference is between F5 and Ctrl-F5, preferably more general than just this case. Unless it's a bug in Firefox, of course.
Ctrl+F5 clears the cached files in browsers where as F5 just refreshes the page but it uses cached files. Eg say you load a page make changes to a css file and upload it press refresh or F5. Page just refreshes and doesn't fetch the new revised css file hit ctrl+F5 it goes it clears the cache for the page and fetches the file again from the server. This would then load the new css file which would display the changes.
Firefox caches not only loaded files but changes made to page( user input and even changes to attributes made by JavaScript). Check this. So if your menu depends on some attributes you can just hard-refresh by clicking CTRL+F5.
ctrl+F5 will just force the cache to be ignored. Perhaps you have a subtle asynchronous-programming bug that is only surfaces when you have a faster page load (due to using the cache).
That issue was fixed by rolling-back \js\dnn.controls.dnnmenu.js file to previous version. Not sure what was wrong there(didn't have time to debug), but anyway now it works:)
I noticed that the source code shown in Firefox appears to be incomplete. I have the latest version. When using the Firebug plugin to look at a webpage, I am able to find elements which are simply not recognized by Firefox.
This is for a automated script I am working on.
I am wondering several things:
Why is a firefox plugin able to recognize elements Firefox is not?
Is there a way to pass the source from Firebug engine to Firefox, or any other viable workaround which would enable Firefox to recognize all of the elements on the page?
My guess is that these "hidden" elements have been created by javascript after the page load, but I'm not really sure.
I'd say Firebug is displaying what's in the DOM (i.e. what is in the page at the instant you are looking at it), while View Source is displaing the source that has been received from the server (i.e. what is in the page at the first instant it's displayed).
If you want to see the "source" from the DOM, maybe the Web Developper Toolbar Extension can help : from what I remember, it provides a "view generated source" option.
For No.2
Open Any Page, and Press Ctrl+A or Select All, and right click, click View Selection Source, You should able to see any html nodes as you see in Firebug.
Your guess is correct. "View source" reveals exactly what the server has passed down to the client. What Firebug shows you is the "rendered source code", which is taking the current DOM state, and rendering it back into a HTML representation, that may or may not look very much like the actual HTML code written.
Your question is unclear.
The View Source command displays the raw HTML that was downloaded from the server.
Firebug's HTML tab shows the elements that are currently on the page.
Any changes made by Javascript will show up in Firebug (which gives a live view), but not in View Source. (Because they weren't in the HTML that was downloaded from the server)
Firefox's View Selection Source command, which appears only when some text is selected, shows the live source from the DOM and should show exactly what you see in Firebug. (Except that it won't update after you click it, so if the DOM changes again, you'll need to click it again to see the change)
To see the source for the entire page, you can press Ctrl+A, then right-click and click View Selection Source.
If theis doesn't answer your question, please elaborate.
Firefox shows the source code as it comes from the server, any alterations to it via JavaScript will not show up. Firebug keeps track of the changes to the document and updates the source code.
Doing Ctrl-U or View | Source will just give you the static HTML document that is returned by the server.
What you probably want to look at - and what you are seeing in Firebug - is the rendered DOM. If you install a Firefox addin such as Web Developer you will be able to view the rendered DOM - i.e. the HTML dynamically rendered in javascript and the actual document the renders in the browser.