I've tried on getting browser info from javascript - navigator.userAgent, but cannot find any related string with "Vivaldi".
Please help to suggest if there are any other programming method or javascript can be used to detect Vivaldi browser?
The correct syntax in JavaScript is navigator.userAgent.
You can check window size, but it may be incorrect.
Vivaldi has its own sidebar and bottom bar that the others not.
But remember, user can change the window size to prevent detection.
According to Vivaldi, the userAgent will not have Vivaldi in it for a better user experience and mimic Chrome in all sites except a few known ones.
For the next release of Vivaldi, we have decided to try something different. The problem with our current approach is that with the web being almost infinite, we can’t possibly discover all the websites who have blocks set against us. Thus maintaining a list of sites where we present a non-Vivaldi User Agent is difficult. Instead, we will try doing the reverse. For a handful of sites where we know the label Vivaldi (and our version number) is responsibly used, we will present our full User Agent. Those sites being our own and a handful of interesting alternative search engines: duckduckgo.com, ecosia.org, qwant.com, and startpage.com. Every other site will get a User Agent that appears to be identical to Chrome.
src: https://vivaldi.com/blog/user-agent-changes/
Since you haven't mentioned your use case, assuming you are building sites, the best solution would be to do what everyone does. I recommend building websites agnostic to browsers and devices, but responsive to resolutions and feature support. Almost all of the browsers are running on Chromium these days, except Safari and Firefox (to my knowledge). So they are all going to work consistently across the board. For any given feature, one could always refer to w3c or mdn docs for compatibility and build around that.
Browser detection is also not quite reliable, as there are extensions to spoof the information. Like this extension that mimics a TV agent so one can run youtube console version on it.
On the other hand, once again I don't know your use case, one might benefit from platform detection over browser detection, like catering to mobile and TV users. Even then, if you have a site responsive enough the platform becomes non-essential information.
Related
I love the firefox extension multi-account containers. I want to switch to brave browser but I can't find a good alternative. Is it a functionality that can only work in firefox due to API limitations or is it possible to implement it in chromium based browsers via an extension?
If I want to create this extension can I make it exactly the same as firefox's multi-account containers? I tried to load the extension into brave but it has many errors due to the differences in the APIs I think. So the only way to do this would be to program it for chromium. Is that possible?
I found this reddit thread https://www.reddit.com/r/brave_browser/comments/kw2cff/brave_alternative_to_firefoxs_multiaccount/ it appears to suggest that containers are firefox exclusive and sessionbox is an alternative suggested. I tried sessionbox though it appears to be limited to having to click on the extension and then select a session to start the website in while multi-account containers can do that automatically if you set it to always open in container.
Are there extension API features that such an extension makes use of and chromium based browsers don't have?
Maybe this feature can be implemented not through an extension but directly through the browser, as brave is open source it should be possible for me to add this feature or fork it and add it there.
[this question is a duplicate of another question I asked; an attempt to make it more clear; I removed the other question]
Multi-account containers functionality requires Contextual identities browser extension API and which is only supported in FireFox.
As for 2023, it's not possible to implement FF's multi-containers in Brave/Chrome.
But you can spread the word and vote for this feature here:
https://community.brave.com/t/equivalent-of-multi-account-containers-or-temporary-containers-extension-ff/135573
It's not a lost cause but this feature has been discussed by Brave's team since their launch, about 5 years ago:
https://github.com/brave/brave-browser/issues/34
Their conclusion is that is too much work. They say this feature has to be implemented by Chrome first, otherwise they have to patch too many things.
The problem is that Google won't ever implement something like that in Chrome, IMO. The whole idea goes against their core business: track users for targeted advertisement.
There are some plugins you can give a try, but they are not practical (in my opinion). Also, I wouldn't trust a plugin to access all my browser data (history, cookies, etc).
tldr; Can one get the browser version from the front end without using navigator strings or Client Hints?
So with Google's announcement about freezing the navigator.userAgent string, I've been tasked with going through a bunch of javascript libraries at work in an effort to replace browser sniffing (aka userAgent). I know, I know, we shouldn't use userAgent in the first place because it's a sack of confusion and lies, but I'm inheriting this code and not creating it. Luckily, a bunch of the use cases were dated (IE8-10, PhantomJS, Windows Phone) and I could remove them completely. Others I could figure out which features/intentions the original authors were using and I could swap their conditions for feature detection.
But some of the public facing logic is using navigator.userAgent to figure out the browser version and this has been more challenging to replace because everything I find on the interwebs related to this search points to using one of the navigator properties. I don't know how and why clients care which "version of Firefox a user is on" and I'm awaiting that answer, but in the meantime I'm trying to see if there is a solution out there that can detect browser version on the front end. I'm not restricting the answer to just javascript, if there is a CSS/HTML/JS combination, I'm all for it.
I'm also aware the Google says we should use Client Hints but that requires hitting the server which is out of scope for my task.
Freezing plan via the Google Announcement:
Different parts of the UA string have different compatibility
implications.
Some parts of it, such as the browser version and the OS version, can
be frozen without any backwards compatibility implications. Values
that worked in the past will continue to work in the future.
Other parts, such as the model (for mobile devices) and the OS
platform, can have implications on sites that tailor their UI to the
underlying OS or that target a very specific model in their layout. Such sites will need to migrate to use UA-CH.
If I am reading the second bullet here correctly, then the version parts of the navigator strings will be frozen and unreliable by Early June 2020.
Again, just so it's clear, I know this should be replace by feature detection, but I don't have full control over our clients and users and I'm just seeing if there is a solution out there. I have a feeling lots of folks will end up trying to solve this problem soon enough.
Is there any way to consistently detect PhantomJS/CasperJS? I've been dealing with a spat of malicious spambots built with it and have been able to mostly block them based on certain behaviours, but I'm curious if there's a rock-solid way to know if CasperJS is in use, as dealing with constant adaptations gets slightly annoying.
I don't believe in using Captchas. They are a negative user experience and ReCaptcha has never worked to block spam on my MediaWiki installations. As our site has no user registrations (anonymous discussion board), we'd need to have a Captcha entry for every post. We get several thousand legitimate posts a day and a Captcha would see that number divebomb.
I very much share your take on CAPTCHA. I'll list what I have been able to detect so far, for my own detection script, with similar goals. It's only partial, as they are many more headless browsers.
Fairly safe to use exposed window properties to detect/assume those particular headless browser:
window._phantom (or window.callPhantom) //phantomjs
window.__phantomas //PhantomJS-based web perf metrics + monitoring tool
window.Buffer //nodejs
window.emit //couchjs
window.spawn //rhino
The above is gathered from jslint doc and testing with phantom js.
Browser automation drivers (used by BrowserStack or other web capture services for snapshot):
window.webdriver //selenium
window.domAutomation (or window.domAutomationController) //chromium based automation driver
The properties are not always exposed and I am looking into other more robust ways to detect such bots, which I'll probably release as full blown script when done. But that mainly answers your question.
Here is another fairly sound method to detect JS capable headless browsers more broadly:
if (window.outerWidth === 0 && window.outerHeight === 0){ //headless browser }
This should work well because the properties are 0 by default even if a virtual viewport size is set by headless browsers, and by default it can't report a size of a browser window that doesn't exist. In particular, Phantom JS doesn't support outerWith or outerHeight.
ADDENDUM: There is however a Chrome/Blink bug with outer/innerDimensions. Chromium does not report those dimensions when a page loads in a hidden tab, such as when restored from previous session. Safari doesn't seem to have that issue..
Update: Turns out iOS Safari 8+ has a bug with outerWidth & outerHeight at 0, and a Sailfish webview can too. So while it's a signal, it can't be used alone without being mindful of these bugs. Hence, warning: Please don't use this raw snippet unless you really know what you are doing.
PS: If you know of other headless browser properties not listed here, please share in comments.
There is no rock-solid way: PhantomJS, and Selenium, are just software being used to control browser software, instead of a user controlling it.
With PhantomJS 1.x, in particular, I believe there is some JavaScript you can use to crash the browser that exploits a bug in the version of WebKit being used (it is equivalent to Chrome 13, so very few genuine users should be affected). (I remember this being mentioned on the Phantom mailing list a few months back, but I don't know if the exact JS to use was described.) More generally you could use a combination of user-agent matching up with feature detection. E.g. if a browser claims to be "Chrome 23" but does not have a feature that Chrome 23 has (and that Chrome 13 did not have), then get suspicious.
As a user, I hate CAPTCHAs too. But they are quite effective in that they increase the cost for the spammer: he has to write more software or hire humans to read them. (That is why I think easy CAPTCHAs are good enough: the ones that annoy users are those where you have no idea what it says and have to keep pressing reload to get something you recognize.)
One approach (which I believe Google uses) is to show the CAPTCHA conditionally. E.g. users who are logged-in never get shown it. Users who have already done one post this session are not shown it again. Users from IP addresses in a whitelist (which could be built from previous legitimate posts) are not shown them. Or conversely just show them to users from a blacklist of IP ranges.
I know none of those approaches are perfect, sorry.
You could detect phantom on the client-side by checking window.callPhantom property. The minimal script is on the client side is:
var isPhantom = !!window.callPhantom;
Here is a gist with proof of concept that this works.
A spammer could try to delete this property with page.evaluate and then it depends on who is faster. After you tried the detection you do a reload with the post form and a CAPTCHA or not depending on your detection result.
The problem is that you incur a redirect that might annoy your users. This will be necessary with every detection technique on the client. Which can be subverted and changed with onResourceRequested.
Generally, I don't think that this is possible, because you can only detect on the client and send the result to the server. Adding the CAPTCHA combined with the detection step with only one page load does not really add anything as it could be removed just as easily with phantomjs/casperjs. Defense based on user agent also doesn't make sense since it can be easily changed in phantomjs/casperjs.
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
I have a website,which is "currently" designed & tested to work only on firefox.If user tries to open it in other browser then I want to show a popup saying "This site works best with Mozilla Firefox. We're working hard to add support for your favorite browser. Meanwhile, do try it with Firefox."
Can we provide a buttion on clicking of which, one new window will be opened in firefox preloaded with some URL ? and also tells us in case firefox is not available at its default location ?
Thanks,
Sourabh
If you make your website standard-conformant, chances are pretty high it will work in Firefox, Opera and WebKit-based browsers (Safari, Chrome), without having to use much browser-specific code. Problem is, as usual, with IE. To achieve best results, write a website for standard-compliant browsers, then add hacks to make it work in IE.
You cannot detect installed applications on client computer, nor launch any of them - beacuse of security. All you can do is to do browser sniffing. You can do it on server side (by examining User-Agent header), or on client side (using JavaScript to check window.navigator object). It is quite complicated and error-prone though and certainly not forward-compatible (future browser versions may confuse your scripts). Moreover, users can change their browser's identification. When you detect unsupported browser, you could display some popup asking user to switch browser.
If you want to detect only IE, you can use IE's conditional comments, which is a most reliable way for detecting IE.
You can't test for Firefox being available nor start it using JavaScript. That would create big security holes...
You can try to figure out if the current browser is Firefox and output a message, although I really hate them (remember that not every visitor will be able to install/use another browser, e.g. within companies or public places).
If it only works on one browser, it isn't a website.
Sometimes we have to rush our work and compromise, but there is a cut-off point where more time is the only sensible option. Making your website multi-browser-compatible is one such example.
However, if you have to detect the user's browser, you could look at quirksmode. Mozilla have good article on browser detection, and the related issues.
A better alternative to browser detection, would be feature detection and Modernizr is very good at this.