using https://github.com/einaros/ws
Server:
var WebSocketServer=require('ws').Server,wss=new WebSocketServer({port:8004});
wss.on('connection',function(s) {
s.on('message',function(_){console.log('received: '+_);});
});
Client:
var s=new WebSocket('ws://mysite.com:8004');
//android default browser dies here <---------------?
s.onopen=function(){
$('body').css({'background':'green'});
s.send('hi');
};
I have to ask why android default browser does not open the connection?
I visit www.websocket.org/echo.html on the default android browser and it says This browser supports websocket. so what is the problem?
This simple code works on iphone safari, windows chrome, android mobile chrome no problem.
On android default browser I can also console.dir(window.WebSocket); and it shows the WebSocket Object no differently than other browsers.
If someone knows why, please tell.
Thanks
UPDATE
if (!window.WebSocket && window.MozWebSocket) {
window.WebSocket = window.MozWebSocket;
alert('MozWebSocket');
}
else if (!window.WebSocket) {
alert("WebSocket not supported by this browser");
}
else{
alert('wtf!? '+window.WebSocket);
}
This gives me a console log of:
wtf!? function WebSocket(){[native code]}
The Android stock browser does not, in fact, support WebSocket.
Some work was apparently done in preparation for adding support, so the API in the browser is there, i.e. you can create a WebSocket object. It's just that this doesn't actually do anything behind the scenes.
This results in a simple feature support check, which just attempts to create the socket object, showing WebSocket support. Check the readyState for a created WebSocket object instead, and you'll see that this never changes from "0".
Starting with Android 4.4, there is no stock browser anymore. The Web view component has been switched to Chrome for Android - and this does support WebSocket.
Related
I have a Chrome extension, and I am currently writing a website to advertise it.
I know that a Chrome extension can be installed in all Chromium-based browsers (Chrome, Opera, etc.).
Is it possible to check if a browser can download the extension from the web store or is chromium-based?
I found code to detect if it was Google Chrome here. Correct me if I'm wrong, but I think window.chrome doesn't return in all Chromium-based browsers.
window.chrome
As of now, window.chrome works in all chromium based browsers
var isChromium = !!window.chrome;
console.log(isChromium)
Resources
https://browserstrangeness.github.io/css_hacks.html
http://browserhacks.com/
navigator.userAgentData
User-Agent Client Hints API returns information about the browser and operating system of a user. (Introduced in chrome 90)
var isChromium = !!navigator.userAgentData && navigator.userAgentData.brands.some(data => data.brand == 'Chromium');
console.log(isChromium)
Resources
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgentData
https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData
https://web.dev/migrate-to-ua-ch/
Considering that you just want to get to know whether browser is chromium based or not ,
Method 1: ( Server Side Detection)
-- Get Browser name from client request itself and serving the webpage accordingly. For example, If backend is based on Nodejs, You can get browser name as answered in this answer.
Method 2: ( Client Side Detection)
-- On client Side ,You can first get the Browser Name as answered in this answer , and then check it from HARD-CODED Chromium-based browsers Array.
Try this. This check shows true for Chrome, Safari, Edge, Samsung browser… etc
The -webkit-appearance property is used by WebKit-based (e.g., Safari) and Blink-based (e.g., Chrome, Opera) browsers to achieve the same thing.
function isChromium(){
return window.CSS && window.CSS.supports && window.CSS.supports('(-webkit-appearance:none)');
}
Try using the following expression
navigator.userAgent.includes("Chrome")
I guess:
var isChrome = navigator.userAgent.match(/Chrome\/\d+/) !== null;
I want to use navigator.vibrate on my page.
This is my code:
var canVibrate = "vibrate" in navigator || "mozVibrate" in navigator;
if (canVibrate && !("vibrate" in navigator))
{
navigator.vibrate = navigator.mozVibrate;
}
$(document).on('click', '.answer', function (eve) {
$this = $(this);
navigator.vibrate(222);
// some other code ...
This works on Android devices but on iOS (I tested on Firfox, Chrome and Safari on some iOS devices) the code will be broken at this line.
Why is that?
Apple's mobile web browser simply does not have support for it.
Firefox and Chrome for iOS are wrappers around Safari's rendering engine.
Quentin is correct that Apple devices do not support the API.
The given code fails to check for vibration support when actually calling the method. To avoid the vibrate function being caught undefined:
const canVibrate = window.navigator.vibrate
if (canVibrate) window.navigator.vibrate(100)
We don't want our app to break down and be unusable on iOS devices.
But we really want to use navigator.vibrate() on Android or wherever possible.
One thing you can do is you can create your own policy over browser policies. Ask "Can we make iOS devices ignore navigator.vibrate()"?
The answer is "Well, yes you can do that by using a user agent parser."
(Such as Faisal Salman's UAParser to detect if the user's device was an iOS or Mac OS device.)
In your code, wrap all the navigator.vibrate() calls inside conditions like,
if(nameOfUsersOS != "iOS" && nameOfUsersOS != "Mac OS") { navigator.vibrate(); }
Note: You must replace nameOfUsersOS with your own variable name.
Note: This is only one possible approach. Policy makers of Apple can and sometimes do change their minds. That means in the future they could allow the good Vibration API just like they allowed the Web Speech API recently. You must use the solution in kotavy's answer unless your policy is like "no vibration for Apple users forever".
I am receiving the error when trying to load my web app on iOS Safari and iOS Chrome. No errors on private browsing on desktop.
I added the following:
if (window.indexedDB) {
console.log('IDB supported');
var db = new Dexie('Stir');
//Dexie stuff
}
Using the Safari dev tools, "IDB supported" is being logged - but then the error/alert pops up and is impeding actions.
I have all of my dexie code wrapped inside if (window.indexedDB) - to make sure it is only run if IDB is available in the browser.
My full repo is available at https://github.com/georgecook92/Stir. If looking at this code, the calls to dexie are in the actions index.js and the main index.js for React.
Dexie can throw that error when the call to indexedDB.open (dB name, version) returns null. A null check was added in the dexie source code in response to the following issue:
https://github.com/dfahlander/Dexie.js/issues/134.
Maybe it would cause less confusion if another error had been used to distinguish it from the real absence of window.indexedDB.
Only Safari has the behavior to ever return null from indexedDB.open (). Reason you see it on ios chrome is because that browser runs on safari underhood due to Apple's license restrictions that forbids any other browser engine else than Safari to run on ios.
We're using the webkitSpeechRecognition API in Chrome. Since this is a prototype application, we're quite happy to support only Chrome, so we detect support for the API by doing a window.hasOwnProperty('webkitSpeechRecognition') check (as suggested by Google). This happily fails in Firefox, but the new Opera (being webkit-based) reports it does have the property. And, indeed, all code runs as intended, except... none of the events are ever fired, no voice is ever recorded.
So, my question is: can I make it work somehow? Does it require some special permissions or settings?
Alternatively, is there a way (aside good old browser-sniffing) to detect proper, working support for the webkitSpeechRecognition?
Right now only google chrome have API to speech recognition by stream (they have google sppeech API).
If you will use https://www.google.com/intl/en/chrome/demos/speech.html on Opera it will tell you that you need Chrome25+ to do this.
Acording to http://caniuse.com/#feat=speech-recognition Opera webkit have support for this functionality but right now it is not working. Opera does not have any API service that would translate it on the fly. Right now there have only placeholders function in their browser, maybe in the future they will make it, right no it is not working.
* EDITED *
Example by google how to determinte if it working or not.
// checking by google
if (!('webkitSpeechRecognition' in window)) {
console.log('GOOGLE: not working on this browser');
} else {
console.log('GOOGLE: working');
}
//your way
if (window.hasOwnProperty('webkitSpeechRecognition')) {
console.log('YOUR: working');
} else {
console.log('YOUR: not working on this browser');
}
The following Google sample uses a timestamp to detect that Opera did not trigger the start event: https://www.google.com/intl/en/chrome/demos/speech.html
This is the code from my chrome extension, as far as i am aware it should return all targets that i can attach a debugger to:
chrome.browserAction.onClicked.addListener(function(tab) {
console.log('launching extention');
chrome.debugger.getTargets(function(result){
console.log('Result!');
console.log("count: "+result.length);
for (index = 0; index < result.length; index++) {
console.log(index+": "+result[index].url);
}
});
});
This is my console output from the above extension:
This shows only tabs open in the chrome browser returned as debuggable targets.
I have my device connected and setup correctly so i can debug android chrome tabs.
Is the method i am using to try to attach to the devices debugger correct?
Related Docs Links;
remote-debugging, debugger, debugger-protocol, debugging-clients.
Whoops. Seems like this API does not allow to attach to device pages. Worse, I can't find any feature requests to enable it to do so.
Therefore, you will need to go low-level, and use the "legacy workflow" to expose the debugger for raw access on the phone you're connecting.
Essentially, the important part is running ADB command
adb forward tcp:9222 localabstract:chrome_devtools_remote
that exposes the debugging interface of Android Chrome at localhost:9222, after which you can use XHR / WebSockets to relay raw protocol messages.
I'm afraid that's the only way; if you need the ADB step to be done automatically, you can use a Native Host script. Note that you still can't bypass the "pairing" part that needs to be done on the phone.