I am building an intreactive information kiosk for public use. Making it a web app in Chrome. It need to work offline. My solution is using the browsers application cache. Problem: Chrome looses all content in the application cache at crash/power failure. Is this normal behaviour?! Is there a way to hold the content in the event of system failure?
Edit 2012-12-19:
The content of the appcache is not lost, it is still there. But Chrome lost the reference to the data. If I start Chrome with the "--restore-last-session" flag it has the connection to the cached data. This is not a "pretty" solution though...
Clarification: The real problem is when Windows and Chrome starts after a power failure and the network connection is absent. Chrome acts as if there is nothing in the appcache and you get the "No network connection" error. I can't se why it works this way?
Related
My copy of Google Chrome, on my laptop, fails to register all service workers. If I load any website that has offline functionality, devtools console outputs:
Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://googlechrome.github.io/samples/service-worker/basic/') with script ('https://googlechrome.github.io/samples/service-worker/basic/service-worker.js'): An unknown error occurred when fetching the script.
Note that the above error is from https://googlechrome.github.io/samples/service-worker/basic/, which is a technology demonstration made by google, specifically about service workers, specifically for chrome, not something I created. One other interesting thing is that service workers fetched from localhost can be registered with no problem. This would suggest an SSL issue (I think), but then again the host of the above website is github pages (is there any way my browser could be not trusting github pages? I haven't found any evidence to support that).
I get the same error if I directly type navigator.serviceWorker.register("https://googlechrome.github.io/samples/service-worker/basic/service-worker.js"); into the console on the same site.
It's not just a console message: if I load the website, then disconnect from the internet, then refresh the page, the browser reports "no internet" and does not load the website. The same thing happens if I use devtools>Application>Service Workers offline mode. This indicates that the service worker is failing to register. However, the Service Workers devtools tab does show service workers present – it just lists them as "redundant" instead of "active and running". Bizarrely, the "time received" is 1970-01-01.
I'm using Google Chrome Version 89.0.4389.114 (Official Build) (x86_64) on MacOS Big Sur. On other browsers (Safari, Firefox, and any browser on any other computer/mobile device), this error does not occur. I have restarted my Chrome multiple times since I first noticed the error, and updated it once since then. Neither fixed it.
I'm aware of a couple similar SO questions (here and here for example), but all of them have accepted answers about how the website creators can fix bugs in their site. This bug is appearing on websites I did not create, and seems specific to my browser (which I haven't tampered with in any way). The main reason this is driving me nuts is that I really really like Chrome's devtools, and I would like to use them for a current PWA project.
If anyone familiar with Chrome's inner workings knows what could be causing this, or if anyone has solved this in the past, I will be forever in your debt.
We have an in-house (.Net) application that runs on our corporate desktops. It runs a small web server listening on for HTTP requests on a specific port on localhost. We have a separate HTTPS website that communicates with this application by setting the ImageUrl of a hidden image to the URL of the - this invokes an HTTP request to localhost, which the application picks up on and actions. For example, the site will set the URL of the image to:
http://127.0.0.1:5000/?command=dostuff
This was to work around any kind of "mixed content" messages from the site, as images seemed to be exempt from mixed-content rules. A bit of a hack but it worked well.
I'd seen that Chrome was making moves towards completely blocking mixed content on pages, and sure enough Chrome 87 (currently on the beta channel) now shows these warnings in the Console:
Mixed Content: The page at 'https://oursite.company.com/' was loaded
over HTTPS, but requested an insecure element
'http://127.0.0.1:5000/?command=dostuff'. This request was
automatically upgraded to HTTPS, For more information see
https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
However, despite the warning saying the request is being automatically upgraded, it hasn't been - the application still gets a plain HTTP request and continues to work normally.
I can't find any clear guidance on whether this warning is a "soft fail", and whether future versions of Chrome will enforce the auto-upgrade to HTTPS (which would break things). We have plans to replace the application in the longer term, but I'd like to be ahead of anything that will suddenly stop the application from working before then.
Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
This answer will focus on your main question: Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
The answer is yes.
The blog post you linked to says:
Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.
That status entry says:
In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03
So this feature has been delayed, but it is coming.
Going through your question and all comments - and putting myself in your shoes, I would do the following:
Not messing with either the currently working .Net app/localhost server (HTTP), nor the user-facing (HTTPS) front-end.
Write a simple/cheap cloud function (GCP Cloud Function or AWS Lambda) to completely abstract away your .Net app from the front-end. Your current HTTPS app would only call the cloud function (HTTPS to HTTPS - not having to pray anymore that Google will not shut-down mixed traffic, which will happen eventually, although nobody knows when).
The cloud function would simply temporarily copy the image/data coming from the (insecure) .Net app to cloud storage and then serve it straight away through HTTPS to your client-side.
Would appreciated help on a gap in comprehension. Sending push notifications to Chrome running on a Windows 10 machine (tried on older Windows also) results in the notifications popping up only when the Chrome browser is open (similarly for installing the page as a PWA). On numerous sites and posts it says that Chrome can run a background process even when the browser is closed and still receive notifications that will kick off the browser or the PWA.
Have reviewed a number of posts from back in 2015/2016 which don't appear relevant based on current state of service workers, PWAs. Have also looked at the W3C spec and Chromium post on design and architecture which don't really seem to cover how the host OS (e.g., Windows) invokes the browser.
The Chrome browser is set to run in the background (setting->advanced->Continue running background apps when Google Chrome is closed) but on closing Chrome and looking at the running processes on the system, there does not seem to a Chrome background thread running (i.e., it does not seem that Chrome inherently runs some background process). Push notifications (e.g., sent via OneSignal) which result in the appropriate page being opened when Chrome is already open or the PWA receiving the notification (we are currently using GCM not FCM if that makes a difference) if it is open, do not seem to kick off the chrome browser if it is not already running. Otherwise the notifications are processed correctly.
From the google developer site and OneSignal documentation, etc, I had somewhat assumed (apparently incorrectly) that having a service worker for push notification would somehow create a background process environment.
So, the question is, what is required to keep Chrome running in the background to be able to receive the push notifications? Can it be done with a service worker? If the code is in a PWA is that different? Is a Chrome extension required? though having to create an extension would seem contrary to the point of creating the service workers and making the app a PWA.
I note also that it posts indicate that with Firefox this is not possible as Firefox completely exits on close with no background processes.
Any thoughts would be appreciated.
We have a web application that runs within a VPN. It has a self signed cert on it and is accessed through the server's IP address.
Part of the functionality of this app are some legacy Java apps (that no longer run in Chrome). Our initial work around for our Chrome users was to run Shell In A Box within an iframe of the web app to run those. All was good until the latest version of Chrome, v45.
What we’re seeing is that appears to be blocking the iframed content (maybe because of the self-signed cert?). If we grab the ShellinABox URL and drop it in a new tab, it works as it used to in the iframe. If we go back to the iframe, it now works. If we close Chrome and open it back up, it still works.
I should also note that we tried the canary builds as well. It's up to v47.x and we still see the same behavior there. We were reading through some of the Chrome group/bug lists and saw some reports that were similar but the "fixes" supposedly going through canary still didn't resolve it.
So, it appears that an exception is being logged somewhere. Does anyone have an explanation for this behavior and is there a way to set this exception without jumping through those hoops?
It turned out it was due to a permissions issue with ShellInABox that didn't reveal itself until v45 of Chrome, for some odd reason.
I have a web app developed with application cache. I am testing it on Windows Phone 8.1 running IE 11 mobile. When the internet connection is turned off the web app loads as expected. My problem is that if I hit the refresh button on the browser when the web app is in offline mode the browser tries to check for an updated manifest file. Since there is no connection it cannot find it and then the cache is rendered in an obsolete state and the browser invalidates the cache. The browser refreshes the web app and then tries to pull the page from the network which fails since I am offline. To summarize, what can I do to prevent the browser from invalidating the application cache on refresh when running in offline mode?
That sounds like a bug to me. Per spec, the applicationCache should only be invalidated (become obsolete) if the request to the *.appcache file returns a 404 or a 410 status. If you are offline, it should instead fail with a status of 0.
I'd suggest to test it with other browsers devices and eventually report it as bug to the IE11 team
Not an answer but my reputation isn't high enough to comment, sorry.
Other people have noticed this too (Why offline web application doesn't work?), so as mentioned already here, it looks like a bug.
Are you testing in the 8.1 release that is available from the Developer Preview app? Or a phone running an official release of 8.1?
I ran into the same problem. I haven't got a solution yet. But i want to list what did NOT work!
Adding IIS Mime Types, as discussed here
Changing .manifest to .appcache, as discussed here
Adding the meta header "cache-control: public" as described here
Also did not work to add the header manually in the webbrowser control of the wp 8.1 cordova web app (in the navigate method).
Deleting the Browser History and local storage in windows phone setting is making the problem even worser
Strangely using developer options in IE and change under the tab emulation to windows phone, the appcache loads succesfull
I hope this list will help other people not to find other solutions.