An external native application should communicate with browser extensions, e.g. send information to browsers what information to fill on web pages.
Those plugins or browser extensions are not yet developed, but I need to support at least Chrome, Firefox and Safari.
What kind of technology can be used to communicate external application with browser extensions? I checked Chrome and it has native messaging for these kind of cases, but I need generic solution what should work for other browsers as well. Any ideas?
There is no generic solution to compatible with all browsers at the moment. So you have to develop different extensions by using different ways for different browsers.
For Safari, you can see here
https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/CommunicatingwithyourOSXApplication/CommunicatingwithyourOSXApplication.html#//apple_ref/doc/uid/TP40009977-CH23-SW4
But unfortunately, it only supports from Safari 9.0 and OSX 10.10
For Chrome, you already know that Native Messaging is the right choice.
For Firefox, you can create a server socket, and listen to specific port. While your native application communicate with Firefox extension through the port. You can find an example here: TcpSocket listen on Firefox addon
Related
This is probably a silly question, however: from a Web Design/Development point of view (I mean support for web standards and web technologies), could Google Chrome and Chromium be considered equivalent?
I know that they are essentially the same browser, the former being the branded version of the latter, but they also have some functional differences, and Google Chrome features some additions not present in the base Chromium browser (detailed on the Chromium page on Wikipedia).
They use the Blink engine, which is in turn also used by other Chromium-based browsers like MS Edge and Opera; and all these browsers have an uneven support for many different web technologies, as detailed on https://caniuse.com.
I'm working on a Linux machine, and my distro ships Chromium by default, providing it from its standard repo; for the sake of simplicity and keeping things clean, I would prefer to avoid adding another external repo and install Chrome just for this task, if I can rely Chromium to behave exactly the same and not have any compatibility issue.
Like I said, this question is probably silly, but given the differences between other Chromium-based browsers, maybe this doubt of mine could be justified.
EDIT: Please note that I'm not interested in the differences between Google Chrome and Chromium from an user point of view or in details of their history and so on; I only wish to know if from a website development point of view, they are fully compatible or if they support the same set of features. In other words, if I test a site from Chromium, can I be sure that it will work also in Google Chrome? Do they support the same exact set of CSS, JS (and other web-related technologies) features?
Chromium is an open-source browser project that forms the basis for the Chrome web browser. It's maintained by the Chromium Project, while Chrome is maintained by Google. Aside from code-opennes, the main difference (for your concerning question) between the two browsers is that Google adds a number of proprietary features to Chrome like automatic updates and support for additional video formats. Also added is AAC, H.264, and MP3 support. Giving you acess to a wider variety of media content, like sites using HTML5 to stream H.264 videos. Both browsers include Opus, Theora, Vorbis, VP8, VP9, and WAV codecs. Chrome also includes a sandboxed Adobe Pepper API (PPAPI) Flash plug-in that updates along with.
From a programmatic side, both support Google DevTools protocol with all of the flexibility and possibilities this brings, like browser automation using the popular puppeteer Node.js runtime, allowing you to run automated tests either in head or headless environments. Both browsers use the Blink rendering engine and the V8 JavaScript engine, so both will give you same support for CSS, HTML and DOM parsing/rendering, and same JavaScript compatibility, functionality and performance. So the real difference is if you're developing media-content centric web apps, in that case you will benefit more from Chrome since it includes all of the above mentioned extra plugins and supported formats, all of this makes the web more accessible to it and provides a wider range of things you could do.
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 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'm trying to load http://m.zara.com from my desktop browser. I have tried with Chrome developer tools to change the user agent to mobile. I have also installed User-Agent Switcher plugin for Chrome without any success. For some reason it is always redirecting to the desktop version.
Why is this not working? How could I manage to do this?
Checkout the link here
Try to download user-agent extension in chrome browser and then you can use the online parsers available in this blog.
There by the simulation of browsers can happen for cross browser access.
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.