Related
I have PWA web site with sw-precache with this sequence:
Reload the page
The service worker should update the cache in the background When its
done, you should see New or updated content is available. in the
console The actual visible changes should not be visible until the
next reload
Reload the page again
The browser will use the new cache this time around The changes
should be visible now! There shouldn't be any messages in the console
I need similar for this, but if file was updated - will be need visible in first load pages. Not after second load. Another (not updated) files - from cache.
This is possible?
Because double reload for see new changes uncomfortable.
you try use the runtimeCaching option to set up an appropriate URL pattern and strategy (networkFirst, cacheFirst, etc.) to match those requests.
"runtimeCaching": [{
"urlPattern": "",
"handler": "networkFirst"
}]
global.toolbox.router.default = global.toolbox.networkFirst; // for all routes
or
global.toolbox.router.get('/assets/(.*)', global.toolbox.networkFirst); // for some particular routes
First, I needed a way to force browser always load .css and .js files. I solved it by putting a sufix in the files:
Before:
<script type="text/javascript" src="file.js"></script>
After:
<script type="text/javascript" src="file.js?v=1"></script>
That aparently worked.
Now, I need to know if that really worked. Sure, I can edit the file and check the changes in my browser but I need a way more specific, something like an option in the browser that show "File loaded from the cache" / "New file loaded from the folder".
Can you help me?
In a Chromium/Chrome browser open the Developer tools (alt + cmd/ctrl + I, or right click the window and hit inspect element), and then click the Network Tab it is the Size and Status properties that tell you if the asset came from browser cache, and whether a request was made to the server to check if the asset was stale.
The reason people may mistake 304 for the ideal in browser caching is if you check the response by sending a request via refreshing, the browser adds a header that forces a check against the server.
So if the asset/resource is saved in your browser, you'll always check the server for staleness and thus get a 304.
If you open up developer tools beforehand, then instead of refresh just click the address bar and hit enter, you should get a status: 200 OK size: (from cache).
If for any reason you don't see a column with size then right click the window and select it from the list of properties.
** NOTE: newer versions of Chrome look like they no longer send the forced revalidate header, if you refresh during the same browser session. Instead you'll see a 200: from memory cache.
It is browser responsibility area to load resources from server or take it from cache. From client code you cannot determine the source that was actually used (if you don't load resources dynamically using ajax). Only you can is look at the Network tab in Developer Tools (or Firebug).
I'm working on a website that uses AJAX loading with some jQuery animations.
With JavaScript, I grab the href from a dynamically generated link to a PHP-based page, and then add that href to URL (after the inevitable #/) .
So far so good, except if a user bookmarks the page and tries to access it, that user will arrive to the home page, instead of the page he/she expected to access.
So, when a page is accessed directly, not by clicking on the internal link of the website, I want to remove #/ from the url, but keep everything after it, so that URL that was bookmarked like this:
http://www.mysite.com/#/somepage
gets rewritten as this:
http://www.mysite.com/somepage
THEN, after the proper page ( http://www.mysite.com/somepage ) finished loading, I want to stick #/ back into its former place in URL ( http://www.mysite.com/#/somepage ), without reloading the page (which, thanks to a clever snippet I'm using, will ensure that the rest of the navigation works the way it should.)
So:
Before page loads, check URL and if it has #/, remove it.
Load page located at hash-less url
Redisplay the url with #/, without reloading the page.
Is it even doable? If yes, I'd be grateful for a lesson.
What you are trying to do is doable but an utter PITA to maintain, and it will not be available on all browsers. That aside, the key resides in the history object relatively recently extended to add a new set of "tricks". Its full doc is available from MDN.
What you are after to do this is the replaceState command. Reads as follows:
Updates the most recent entry on the history stack to have the specified data, title, and, if provided, URL. The data is treated as opaque by the DOM; you may specify any JavaScript object that can be serialized. Note that Firefox currently ignores the title parameter; for more information, see manipulating the browser history.
This will allow you to replace your current page in the history of the browser, but not in the URL. The URL will be exactly as you have it - with the hash. No point changing it considering your solution.
However, you will have to make sure that your hashless page redirects to the hash-present page for clients with the history object, for consistency. That's the only requirement.
Before page loads, check URL and if it has #/, remove it.
Not possible. The fragment id is not sent to the server, so you can only access it with client side code and that requires the page to load (or at least to start loading).
Load page located at hash-less url
Redisplay the url with #/, without reloading the page
Use XMLHttpRequest to get the data, DOM to change the document to use it, and the history API to change the URL in the address bar.
As has been pointed out in one of the answers, you can't remove hash before your page loads.
However, once the page started loading, the manipulation described in the question is possible.
Here's one way to do it.
// Remove the hash and reload the page at url without hash
if (window.location.href.indexOf('/#/')>=0) {
window.location = window.location.href.replace(/\/#\//, '/');
}
Once the new page started loading, you can use history.pushState to update the URL display:
if ((window.location.href.indexOf('/#/')<1) && (location.pathname != "/")) {
history.pushState({}, "page x", location.protocol + '//' + location.host + '/#' + location.pathname);
}
You gotta keep in mind though that pushState is only available for browsers started with Gecko 2.0, so placing the hash back into the url will not work in older browsers, period.
This may lead to some unfortunate situations. For example, hypothetically, your url http://www.mywebsite.com/somepage gets indexed by a search engine. A user clicks on that link, accessing your website in an older browser that doesn't support pushState, and then clicks on some other link when browsing your AJAX-enabled website. That user is likely to arrive to
http://www.mysite.com/somepage/#/someotherpage
And then, as the user keeps clicking, it will only keep getting worse:
http://www.mysite.com/somepage/#/someotherpage/#/yetanotherpage/#/andsoon/#/andsoforth/
So what you probably need is something to make sure that your hashes don't keep propagating.
You can also wrap your hash removing / replacing code in a conditional:
if (history.pushState) {
// add hash
} else {
// provide some alternative
}
Finally, look into these two resources. You may not need the hash at all: History.js and jQuery Address.
Since 12 june 2012 11:20 TU, I see very weirds errors in my varnish/apache logs.
Sometimes, when a user has requested one page, several seconds later I see a similar request but the all string after the last / in the url has been replaced by "undefined".
Example:
http://example.com/foo/bar triggers a http://example.com/foo/undefined request.
Of course theses "undefined" pages does not exist and my 404 page is returned instead (which is a custom page with a standard layout, not a classic apache 404)
This happens with any pages (from the homepage to the deepest)
with various browsers, (mostly Chrome 19, but also firefox 3.5 to 12, IE 8/9...) but only 1% of the trafic.
The headers sent by these request are classic headers (and there is no ajax headers).
For a given ip, this seems occur randomly: sometimes at the first page visited, sometimes on a random page during the visit, sometimes several pages during the visit...
Of course it looks like a javascript problem (I'm using jquery 1.7.2 hosted by google), but I've absolutely nothing changed in the js/html or the server configuration since several days and I never saw this kind of error before. And of course, there is no such links in the html.
I also noticed some interesting facts:
the undefined requests are never found as referer of another pages, but instead the "real" pages were used as referer for the following request of the same IP (the user has the ability to use the classic menu on the 404 page)
I did not see any trace of these pages in Google Analytics, so I assume no javascript has been executed (tracker exists on all pages including 404)
nobody has contacted us about this, even when I invoked the problem in the social networks of the website
most of the users continue the visit after that
All theses facts make me think the problem occurs silently in the browers, probably triggered by a buggy add-on, antivirus, a browser bar or a crappy manufacturer soft integrated in browsers updated yesterday (but I didn't find any add-on released yesterday for chrome, firefox and IE).
Is anyone here has noticed the same issue, or have a more complete explanation?
There is no simple straight answer.
You are going to have to debug this and it is probably JavaScript due to the 'undefined' word in the URL. However it doesn't have to be AJAX, it could be JavaScript creating any URL that is automatically resolved by the browser (e.g. JavaScript that sets the src attribute on an image tag, setting a css-image attribute, etc). I use Firefox with Firebug installed most of the time, so my directions will be with that in mind.
Firebug Initial Setup
Skip this if you already know how to use Firebug.
After the installs and restarting Firefox for Firebug, you are going to have to enable most of Firebug's 'panels'. To open Firebug there will be a little fire bug/insect looking thing in the top right corner of your browser or you can press F12. Click through the Firebug tabs 'Console', 'Script', 'Net' and enable them by opening them up and reading the panel's information. You might have to refresh the page to get them working properly.
Debugging User Interaction
Navigate to one of the pages that has the issue with Firebug open and the Net panel active. In the Net panel there will be a few options: 'Clear', 'Persist', 'All', 'Html', etc. Make sure ALL is selected. Don't do anything on the page and try not to mouse over anything on it. Look through the requests. The request for the invalid URL will be red and probably have a status of 404 Not Found (or similar).
See it on load? Skip to the next part.
Don't see it on initial load? Start using your page and continue here.
Start clicking on every feature, mouse over everything, etc. Keep your eyes on the Net panel and watch for a requests that fail. You might have to be creative, but continue using your application till you see your browser make an invalid request. If the page makes many requests, feel free to hit the 'Clear' button on the top left of the Net panel to clear it up a bit.
If you submit the page and see a failed request go out really quick but then lose it because the next page loads, enable persistence by clicking 'Persist' in the top left of the Net panel.
Once it does, and it should, consider what you did to make that happen. See if you can make it happen again. After you figure out what user interaction is making it happen, dive into that code and start looking for things that are making invalid requests.
You can use the Script tab to setup breakpoints in your JavaScript and step through them. Investigate event handlers done via $(elemment).bind/click/focus/etc or from old school event attributes like onclick=""/onfocus="" etc.
If the request is happening as soon as the page loads
This is going to be a little harder to peg down. You will need to go to the Script tab and start adding break points to every script that runs on load. You do this by clicking on the left side of the line of JavaScript.
Reload your page and your break points should stop the browser from loading the page. Press the 'Continue' button on the script panel. Go to your net panel and see if your request was made, continue till it is found. You can use this to narrow down where the request is being made from by slowly adding more and more break points and then stepping into and out of functions.
What you are looking for in your code
Something that is similar to the following:
var url = workingUrl + someObject['someProperty'];
var url = workingUrl + someObject.someProperty;
Keep in mind that someObject might be an object {}, an array [], or any of the internal browser types. The point is that a property will be accessed that doesn't exist.
I don't see any 404/red requests
Then whatever is causing it isn't being triggered by your tests. Try using more things. The point is you should be able to make the request happen somehow. You just don't know yet. It has to show up in the Net panel. The only time it won't is when you aren't doing whatever triggers it.
Conclusion
There is no super easy way to peg down what exactly is going on. However using the methods I outlined you should be at least be able to get close. It is probably something you aren't even considering.
Based on this post, I reverse-engineered the "Complitly" Chrome Plugin/malware, and found that this extension is injecting an "improved autocomplete" feature that was throwing "undefined" requests at every site that has a input text field with NAME or ID of "search", "q" and many others.
I found also that the enable.js file (one of complitly files) were checking a global variable called "suggestmeyes_loaded" to see if it's already loaded (like a Singleton). So, setting this variable to false disables the plugin.
To disable the malware and stop "undefined" requests, apply this to every page with a search field on your site:
<script type="text/javascript">
window.suggestmeyes_loaded = true;
</script>
This malware also redirects your users to a "searchcompletion.com" site, sometimes showing competitors ADS. So, it should be taken seriously.
You have correctly established that the undefined relates to a JavaScript problem and if your site users haven't complained about seeing error pages, you could check the following.
If JavaScript is used to set or change image locations, it sometimes happens that an undefined makes its way into the URI.
When that happens, the browser will happily try to load the image (no AJAX headers), but it will leave hints: it sets a particular Accept: header; instead of text/html, text/xml, ... it will use image/jpeg, image/png, ....
Once such a header is confirmed, you have narrowed down the problem to images only. Finding the root cause will possibly take some time though :)
Update
To help debugging you could override $.fn.attr() and invoke the debugger when something is being assigned to undefined. Something like this:
(function($, undefined) {
var $attr = $.fn.attr;
$.fn.attr = function(attributeName, value) {
var v = attributeName === 'src' ? value : attributeName.src;
if (v === 'undefined') {
alert("Setting src to undefined");
}
return $attr(attributeName, value);
}
}(jQuery));
Some facts that have been established, especially in this thread: http://productforums.google.com/forum/#!msg/chrome/G1snYHaHSOc/p8RLCohxz2kJ
it happens on pages that have no javascript at all.
this proves that it is not an on-page programming error
the user is unaware of the issue and continues to browse quite happily.
it happens a few seconds after the person visits the page.
it doesn't happen to everybody.
happens on multiple browsers (Chrome, IE, Firefox, Mobile Safari, Opera)
happens on multiple operating systems (Linux, Android, NT)
happens on multiple web servers (IIS, Nginx, Apache)
I have one case of googlebot following the link and claiming the same referrer. They may just be trying to be clever and the browser communicated it to the mothership who then set out a bot to investigate.
I am fairly convinced by the proposal that it is caused by plugins. Complitly is one, but that doesn't support Opera. There many be others.
Though the mobile browsers weigh against the plugin theory.
Sysadmins have reported a major drop off by adding some javascript on the page to trick Complitly into thinking it is already initialized.
Here's my solution for nginx:
location ~ undefined/?$ {
return 204;
}
This returns "yeah okay, but no content for you".
If you are on website.com/some/page and you (somehow) navigate to website.com/some/page/undefined the browser will show the URL as changed but will not even do a page reload. The previous page will stay as it was in the window.
If for some reason this is something experienced by users then they will have a clean noop experience and it will not disturb whatever they were doing.
This sounds like a race condition where a variable is not getting properly initialized before getting used. Considering this is not an AJAX issue according to your comments, there will be a couple of ways of figuring this out, listed below.
Hookup a Javascript exception Logger: this will help you catch just about all random javascript exceptions in your log. Most of the time programmatic errors will bubble up here. Put it before any scripts. You will need to catch these on the server and print them to your logs for analysis later. This is your first line of defense. Here is an example:
window.onerror = function(m,f,l) {
var e = window.encodeURIComponent;
new Image().src = "/jslog?msg=" + e(m) + "&filename=" + e(f) + "&line=" + e(l) + "&url=" + e(window.location.href);
};
Search for window.location: for each of these instances you should add logging or check for undefined concats/appenders to your window.location. For example:
function myCode(loc) {
// window.location.href = loc; // old
typeof loc === 'undefined' && window.onerror(...); //new
window.location.href = loc; //new
}
or the slightly cleaner:
window.setLocation = function(url) {
/undefined/.test(url) ?
window.onerror(...) : window.location.href = url;
}
function myCode(loc) {
//window.location.href = loc; //old
window.setLocation(loc); //new
}
If you are interested in getting stacktraces at this stage take a look at: https://github.com/eriwen/javascript-stacktrace
Grab all unhandled undefined links: Besides window.location The only thing left are the DOM links themselves. The third step is to check all unhandeled DOM links for your invalid URL pattern (you can attach this right after jQuery finishes loading, earlier better):
$("body").on("click", "a[href$='undefined']", function() {
window.onerror('Bad link: ' + $(this).html()); //alert home base
});
Hope this is helpful. Happy debugging.
I'm wondering if this might be an adblocker issue. When I search through the logs by IP address it appears that every request by a particular user to /folder/page.html is followed by a request to /folder/undefined
I don't know if this helps, but my website is replacing one particular *.webp image file with undefined after it's loaded in multiple browsers. Is your site hosting webp images?
I had a similar problem (but with /null 404 errors in the console) that #andrew-martinez's answer helped me to resolve.
Turns out that I was using img tags with an empty src field:
<img src="" alt="My image" data-src="/images/my-image.jpg">
My idea was to prevent browser from loading the image at page load to manually load later by setting the src attribute from the data-src attribute with javascript (lazy loading). But when combined with iDangerous Swiper, that method caused the error.
What is the difference between JavaScript's
window.location.href = window.location.href
and
window.location.reload()
functions?
If I remember correctly, window.location.reload() reloads the current page with POST data, while window.location.href=window.location.href does not include the POST data.
As noted by #W3Max in the comments below, window.location.href=window.location.href will not reload the page if there's an anchor (#) in the URL - You must use window.location.reload() in this case.
Also, as noted by #Mic below, window.location.reload() takes an additional argument skipCache so that with using window.location.reload(true) the browser will skip the cache and reload the page from the server. window.location.reload(false) will do the opposite, and load the page from cache if possible.
If you say window.location.reload(true) the browser will skip the cache and reload the page from the server. window.location.reload(false) will do the opposite.
Note: default value for window.location.reload() is false
The difference is that
window.location = document.URL;
will not reload the page if there is a hash (#) in the URL (with or without something after it), whereas
window.location.reload();
will reload the page.
If you add the boolean true to the reload
window.location.reload(true) it will load from server.
It is not clear how supported this boolean is, W3Org mentions that NS used to support it
There MIGHT be a difference between the content of window.location.href and document.URL - there at least used to be a difference between location.href and the non-standard and deprecated document.location that had to do with redirection, but that is really last millennium.
For documentation purposes I would use window.location.reload() because that is what you want to do.
As said, modifying the href when there is a hash (#) in the url would not reload the page. Thus, I use this to reload it instead of regular expressions:
if (!window.location.hash) {
window.location.href = window.location.href;
} else {
window.location.reload();
}
Came across this question researching some aberrant behavior in IE, specifically IE9, didn't check older versions. It seems
window.location.reload();
results in a refresh that blanks out the entire screen for a second, where as
window.location = document.URL;
refreshes the page much more quickly, almost imperceptibly.
Doing a bit more research, and some experimentation with fiddler, it seems that window.location.reload() will bypass the cache and reload from the server regardless if you pass the boolean with it or not, this includes getting all of your assets (images, scripts, style sheets, etc) again. So if you just want the page to refresh the HTML, the window.location = document.URL will return much quicker and with less traffic.
A difference in behavior between browsers is that when IE9 uses the reload method it clears the visible page and seemingly rebuilds it from scratch, where FF and chrome wait till they get the new assets and rebuild them if they are different.
A difference in Firefox (12.0) is that on a page rendered from a POST, reload() will pop up a warning and do a re-post, while a URL assignment will do a GET.
Google Chrome does a GET for both.
Using JSF, I'm now having the issue with refresh after session is expired: PrimeFaces ViewExpiredException after page reload and with some investigation I have found one difference in FireFox:
Calling window.location.reload() works like clicking refresh icon on FF, it adds the line
Cache-Control max-age=0
while setting window.location.href works like pressing ENTER in URL line, it does not send that line.
Though both are sent as GET, the first (reload) is restoring the previous data and the application is in inconsistent state.
No, there shouldn't be. However, it's possible there is differences in some browsers, so either (or neither) may not work in some case.
from my experience of about 3 years, i could not find any difference...
edit : yes, as one of them here has said, only passing a boolean parameter to window.location.reload() is the difference.
if you pass true, then the browser loads a fresh page,
but if false, then the cache version is loaded...
In our case we just want to reload the page in webview and for some reasons we couldn't find out why!
We try almost every solution that has been on the web, but stuck with no reloading using location.reload() or alternative solutions like window.location.reload(),
location.reload(true), ...!
Here is our simple solution :
Just use a < a > tag with the empty "href" attribution value like this :
< a href="" ...>Click Me</a>
(in some cases you have to use "return true" on click of the target to trigger reload)
For more information check out this question :
Is an empty href valid?
window.location.href, this as saved my life in webview from Android 5.1. The page don't reload with location.reload() in this version from Android.