I've red in many articles that service worker automatically detects if there's a change in its js (mine is 'service-worker.js')
http://www.html5rocks.com/en/tutorials/service-worker/introduction/
I already registered and see the status in chrome://serviceworker-internals/.
The problem is whenever i change the service-worker.js, it doesn't detect the change when I go to the scope url (mine is 'localhost/dashboard').
The weird thing is when I visit the service-worker.js (localhost/service-worker.js) , then visit the scope url, it now detects the change and I see 2 service workers in chrome://serviceworker-internals/. One has running status and the other one has 'installed' status. I presume that this is correct but why do i still need to go to the js file?
Is this a server side problem or cache problem? I tried clearing the cache but the problem keeps getting back.
If you make a change to your service worker, then reloading the page won't kill the old one and activate the new one.
You need to go to the Service Workers section in the dev tool, and checking 'Update on reload'.
Or go to about:blank and then hard refresh with cmd+r
I suggest you to use Chrome Canary for debugging service workers.
Hope it helps.
Related
My website is refreshing randomly by itself with an additional unknown URL parameter ?mn followed by a Hash. Example:
?mn=l4ehjinilk0ids2leotmtyrmttfuq4oqedu.eebubnay47ddfhvd
I really don't know where it comes from. It happened even in Incognito mode.
Website is on Sitecore.
Any ideas?
If the page is loading correctly from the server but then refreshes with additional parameters in your browser, it must be triggered by JavaScript code. It can be caused by your own JavaScript, scripts injected by a third-party snippet, scripts executed by your browser extensions and so on.
Follow the steps below to find what triggers this refresh:
Open Developer Tools in your browser and navigate to the Network tab
Select the Preserve log checkbox
Reload your web page to replicate the issue
Find the request with parameter ?mn= and select it
Go to the Initiator tab, it will show the request call stack or request initiator chain similar to this:
This can help you understand what in your browser triggered the web page refresh.
Thank you.
I finally found out.
It was due to the Zoom application, a Post-attendee URL was set, as soon as a meeting is done, Zoom triggers the default browser and redirects to a website.
The setup for this will be a Chrome instance on a VM I control (and thus can install anything I need onto it) for the purposes of monitoring changes to a web page that were not made by the web code itself. I will be testing a web site (on a Linux build, in Apache using a Tomcat or Jetty instance) which displays data from a backend database (I won't bore anyone with the details). That data once displayed can of course be edited by anyone who knows how to use dev tools and inspect element features in certain browsers, and while the changes made won't propagate back to the backend and can be wiped out with a refresh, I would like to monitor to see if those changes were nonetheless attempted.
I have already managed to find a way to monitor if the Dev Console has been opened using Chrome by using an extension that specifically hooks into its' toggle. Coupled with some JS code, I can then act upon when it is opened, closed or both, and for example, force a refresh of the page in the event that someone used the inspect element to make changes to the rendering of the page.
I would like to then check to see if any of the client-side elements have been altered, capture the changed values, and then retrieve the original data from the back-end to compare against (I can manage the back-end stuff). I've seen a few examples of the use of InnerText and InnerHTML as a means of checking, and will try it out later, but wanted to know if anyone had any experience with anything similar.
I was trying to make an offline web app using ServiceWorker to cache the web requests. But I included sw.js in the cached file list.
Have I just broken my web app for all time for those who loaded my app already, or is there any way to recover? If I release a fixed sw.js file, I'm worried that my my users aren't getting the updated version, because they are using the cached sw.js...
Yes and no. You have broken it for some time but not forever.
Both Chrome and Firefox have implemented an automatic refresh interval of ~24 hours. You may read more about it from here.
This is still tricky, though, since some users might be using an older browser that doesn't automatically check for SW.js updates from the network. What could be done in that situation is not completely clear to me. If someone knows, please comment and I'll update this answer to include all the information.
When I upload any changes in javascript files to my deployed site on Google cloud compute engine, the changes do not show up right away, if I load the js files in browser. The changes are physically there, validated by RDPing to the server. B
These changes sometime take 6 to 8 hours to show up in browser, and sometimes show up sporadically. What can I do to ensure that my changed js files take effect immediately on load?
I dont face this problem when I upload on my test server, which is not under cloud. Happens only on the google cloud server.
Try opening your builtin browser debugger (for example right-click on your page, if using Chrome, and click "Inspect"). Now select the Network tab. Now reload. Now look at the sizes of the files. If they are very small, then probably the browser loaded cached copies. You can verify this by checking the "Disable cache" option in the Inspector.
If it works correctly and the file updates right away when you have the browser cache disabled, then you need to investigate with your web server software to see how to cause it to invalidate caches. One mechanism you can look into is called "ETags."
What worked was invalidating the cloud cache for the file. Lesson learnt: always add version numbers to your js files.
I've created a web app that caches all necessary code and data for use offline through applicationCache. However, every time the app starts up, it immediately tries to check for updates. This blocks the browser for a significant chunk of time, even if it doesn't find anything to update. This behavior is highly disruptive to the app (shouldn't updates be done in the background, anyway?). Just the checking stage takes a lot of time on a mobile device, and if it find updates all bets are off as to how long downloading will take (b/c it has to redownload all files) - which also freezes up the browser.
So, I am wondering:
Is there a way to delegate applicationCache updates to a shared Web Worker? OR
Is there a way to block all applicationCache updates until the user specifically wants to check for updates and presses a button that will initiate updates through applicationCache.update()? OR
Are there other ways to mitigate the time spent on checking for updates?
Shouldn't application cache updates run asynchronously in the background?
edit: perhaps a carefully-constructed cache-control header on the manifest file is the answer? I'll be investigating this, but I hope somebody can give me more info on these updates. Thanks.
UPDATE
Ok, I've played with headers, and nothing has helped. I'm starting a bounty. If you can help, please do!
If you want to give the user more control over the actual update, you could parameterise the manifest URL with something specific to that user. Then when the user wants to update, you fire off a request to the server which rolls that particular user's manifest file, and then reload the page client-side to force a reload of the manifest.
I've since been doing some reading and came across this article which seems to be a much more elegant solution if the user is already on the cached page -
http://www.html5rocks.com/tutorials/appcache/beginner/#toc-updating-cache
As for the load time involved in the manifest up-to-date check, that's not something I've ever had a problem with. My understanding was that it happens in the background, are you just concerned about the browser showing loading hints?
The abort() method may be the answer...someday, but I haven't come across any browsers that implement it yet.
I had a similar problem, and tried everything, including the wild idea of putting the manifest inside itself to see if it would cache itself. So I could do the updates manually with ajax requests and eval'ing javascript stuffed into localStorage...yikes.
Finally, I created a very simple html page with a simple manifest. When I tested it, the UI didn't lock up. Slowly I started to add things into the page, and play around with the manifest contents to see what things might cause it to freeze during the applicationCache check. I finally got failure when I added an image to the page, but left it out of the manifest -- that's when the UI started to lock up again. I went back to my original project, and found a few images that needed to be in the manifest, and that fixed the locking UI issue there too.
The checking phase of the applicationCache tries to be asynchronous (at least on the devices I've tested). However, if there are any files missing from the manifest, then everything must wait for the applicationCache to finish checking.
It appears that when the browser needs a file that has not been cached, it waits for the applicationCache to complete the update before it will make a request for the file -- which kind of makes sense, since other resources may rely on the missing file. This puts the brakes on the rendering and makes the UI freeze up. If the manifest is unreachable (e.g. on a different network), the UI can be locked up for about a minute.
To find the files that need to be added to the manifest, watch the server logs as you refresh the app a few times. The suspects will be any GET requests for files other than the manifest.