CanIUse and MDN doesn;t seems to be agree on the support for service worker. In the midst of Chrome going to remove support for appcach, we are trying to ascertain the impact of moving to Service Worker. Are we reading the above two pages incorrectly?
We tried Google's own samples against device/browser combinations and results wore not encouraging. For example the 'custom offline page' demo failed in iOS Chrome (v80) where it worked in iOS Safari (12.4.5).
The 'Selective caching' and 'Read through caching' pages clearly show "service worker is not supported in the current browser" in Chrome 80. It is checking the if ('serviceWorker' in navigator) {, but other samples doesn't show such a message.
All and all it is confusing on the browser support for the Service worker. Is there there a universally tested sample which we can use as a benchmark for different device/browser combination.
I asked Jake Archibald of Google on this and he replied with the following SO post which must be still valid.
Chrome Service Worker iOS Support
Therefore apparently Safari is the only option at the moment. I am still wondering what Google is recommending developers to use once they remove support for AppCache.
Jake continued saying there is no way they can add support as Apple is not giving them full rights on iOS. But he mentioned appcache will continue to work as usual. His exact words are
"However, since Chrome on iOS is just a skin over Safari, appcache will continue to work while it works in Safari webview."
on iOS only Safari supports service workers. You can test browsers if it supports with this code
if ('serviceWorker' in navigator) { /*supported*/ }
Related
might be very basic question but just wanted to clear out my doubt, since I'm seeing PWA is like alternative for native application.
What if browser fail to read/understand manifest file?
what if user is having other/older browser? (most of the time I see e.g of chrome)
after installation what are the browser dependencies for PWA?
Please guide me with the above.
Thanks
One of the more important concepts in a PWA is that it is built following the principle of progressive enhancement, this means that the website would function ordinarily on older browsers (including Safari) and then gain PWA abilities if the user's browser supports them.
Therefore in answer to your three questions:
Website would function as normal without the option to "Add to HomeScreen"
Same.
The PWA runs using the browser, therefore any functionality supported by the browser will be included in your PWA.
I've read that Firefox has begun supporting a cache control extension value of immutable, which means that "the response body will not change over time." So even if a user requests a "full refresh" of a page or resource, the browser still only responds with the locally cached copy, thus avoiding unnecessary 304s or page refreshes, and making pages load faster since cached content is used, and decreasing load on servers, since a large number of requests are stopped before they even happen.
I'm trying to see how well this is supported, and am finding varying answers, as this mozilla page suggests that it's only supported in Firefox, but this resolved Chrome issue suggests it's been available since Chrome v54.
Which browsers support Cache-Control: immutable, and when did they start supporting it?
I first read about it here on this Hacker News discussion
Here's an ietf draft on it, the original mozilla post announcing this beta feature being used by Facebook and this related mozilla post, and a document discussing the different types of reloading requests from some Google chrome devs, it appears.
As of February 2017, Cache-Control: immutable is supported by
Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1267474) since Firefox 49
Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=611416) since Chrome 54 They aren't implementing this.
Safari (https://bugs.webkit.org/show_bug.cgi?id=167497) in Safari Technology Preview 24.
It is also listed on MDN and Can I Use ... ?.
As of April 2017 it is also supported in "classic" Edge
I am making an app which will support the "Add to Homescreen" features in Android Chrome and iOS Safari. Since I would like universal offline support for both of these features, but I only want to use the manifest file where I have to, in order increase my control. However, iOS Safari does not support service workers, so my question is how can I only instantiate a cache manifest file if support for Service Workers is not present, more specifically; I know I could add manifest='whatever.appcache' to the <html> tag with JavaScript, but will browsers, specifically iOS Safari, use that cache?
According to an answer by #Daniel Herr:
You could choose to use Service Workers and AppCache on the same web app. What happens in such a case is that browsers that don’t support Service Workers will use AppCache, and those that do will ignore the AppCache and let the Service Worker take over.
Sources: https://www.w3.org/TR/service-workers/#activation-algorithm, https://crbug.com/410665
Thanks for your answer!
I have a web app that implements WebRTC using adapter.js, and most cases work. Firefox to Firefox and Chrome to Chrome work fine, but:
When Chrome and Firefox connect, the video from the Firefox side doesn't show up on the Chrome side. Audio does work!, so the webrtc channel is good.
Computers are in the same network
(I do have STUN/TURN capabilities, but that's irrelevant I think)
It doesn't matter which one initiates the call
It's always Chrome that doesn't see Firefox, Firefox always does see Chrome
No errors, no warnings, all expected callbacks fire, handshake seems to be done
Alice sends Bob her ice candidates at 'the end' of onicecandidate. Bob does the same, but timing might be more important than I realize here.
Both video elements are created, with a blob src (using srcObject), and onloadedmetadata fires on both browsers
Happens on every computer (tried ~ 20 combinations on 5 computers)
Very occasionally other things fail, like ICE negotiation (even though it's always the same network), and createOffer or setRemoteDescription sometimes fails.
All problems I can find like this are from 2-3 years ago, but after that Firefox and Chrome seem to be good RTC buddies. What's going on with my video?
Related, but not the solution:
WebRTC Firefox to Chrome video call not working
WebRTC works in Chrome but not Firefox
Likely this is a problem with assumptions about things happening synchronously or not in the API. The API is heavily asynchronous, and what happens synchronously or not varies between the browsers (or between different versions of the same browser). You may want to carefully compare your code to other examples using adapter.js.
Without the code or the relevant snippets it's hard to say exactly what is wrong, however important things to check are about:webrtc (for Firefox, including the connection log at the bottom), the chrome webrtc internals page, and internal logging. Also add your own logging of what callbacks/promises happened and didn't. I suggest in firefox setting the env vars NSPR_LOG_MODULES=signaling:4,mtransport:4 and NSPR_LOG_FILE=whatever. You can also (especially with those logs or some sample code) ping Firefox developers in #media on irc.mozilla.org.
for example, growl flashes a message in the upper right corner regardless of which application is running. Skype makes the icon in the dock have a little red dot with a number of new messages. Is there anyway to write a chrome extension to have this type of functionality? that is, I want to write a chat system that works in the browser but also notifies users when they have closed my site's tab, or even when chrome is not running.
I could write a native client in addition to my browser based client, but that's double the work. (Tripple the work if you bother with a native window's client vs. just OSX but who would do that?)
Chrome can create "Desktop Notifications" See the Documentation
It's also possible to have the notifications visible when chrome is closed providing you create a "background process". this question/answer might point you in the right direction.
Chrome supports the text-only version of the W3C desktop notification standard. Chrome deprecated the HTML version about a year ago and will stop supporting it very soon. Any webpage viewed in Chrome and any Chrome extension can use this API.
The Rich Notifications API is available to Chrome extensions and packaged apps. As of today, it's dev-channel only and is iterating rapidly. It has implementations on ChromeOS and Windows, with Mac on the way. Linux currently delegates to the W3C implementation. The API is not a 1:1 replacement of W3C HTML desktop notifications, but it does provide many layout options for common use cases.