I have a web app that uses wake lock (see below) - I have registered the origin trial and added the code to my index.html. - see https://lucid-franklin-4016c2.netlify.com/
When I load the page in the latest version of Android Chrome the phone stays awake, and the text-to-speech messages I use for this running app work fine.
I've also set it up as a PWA (service worker, manifest,... - all good in lighthouse). However, after "add page to home screen" and loading the PWA from there the phone does go to sleep. It continues to count time and can play sound files in the background but text-to-speech is deactivated.
Is this expected behaviour?
My key need is text-to-speech rather than to keep the phone awake as such, as geolocation seems to work while the phone is asleep anyway. Is there something else I could be doing?
// The wake lock sentinel.
let wakeLock = null;
// Function that attempts to request a wake lock.
export const requestWakeLock = async cb => {
try {
wakeLock = await navigator.wakeLock.request("screen");
wakeLock.addEventListener("release", () => {
console.log("Wake Lock was released");
});
console.log("Wake Lock is active");
} catch (err) {
console.error(`${err.name}, ${err.message}`);
cb({
tag: "error",
payload: "wakeLock not supported"
});
}
};
Chrome have recently promoted Wake Lock API out of origin trial in version 84 and seems to work well for Chrome on Android PWA.
Demo: https://reillyeon.github.io/scraps/wakelock.html
Related
Description/background
I had set up a script which opened a Google site of our company in Google Chrome (not headless) and did some automated work on that page. The login information had to be refreshed occasionally what for I manually logged in. That had been working perfectly the last couple of months until last week. Today I noticed that I get the above mentioned error message as a result of a server response with HTTP status 400 upon entering my Gmail address and clicking the Next button.
Steps to reproduce
Puppeteer version: 2.0.0
Platform / OS version: Windows 10
URLs (if applicable): https://sites.google.com/...
Node.js version: v12.13.0
What steps will reproduce the problem?
Run a Puppeteer script to open a Google Site which requires login.
(async () => {
try {
const browser = await puppeteer.launch({headless: false, userDataDir: "<ProfileDirectory>"});
const pageLogin = await browser.newPage();
await pageLogin.goto('https://sites.google.com/...', {waitUntil: 'networkidle2'});
...
await browser.close();
}
catch (error) {
console.log(error.stacktrace);
}
})();
Manually enter Gmail address and click Next.
Get error message "Sorry, something went wrong there. Try again." as a result of a server response with HTTP status code 400.
Update:
Manually opening Chrome (same userDataDir) and the respective Google site still works as usual.
Recommend to use playwright/puppeteer + Firefox. It seems like google adds something into chrome so they can detect the browser is automated or not
One of the comments on this post mentions that Google tries to block logins with Puppeteer, Selenium etc. this might be why you are getting a 400 error.
One of the recent comments on the aforementioned post, links a gist with some example code that might still work, haven't tried it though.
While I was doing research on Puppeteer for Firefox, I noticed that (1) Puppeteer downloads its own local Google Chrome binaries it is executing and (2) my installed Puppeteer version 2.0.0 was outdated. Meaning, the browser actually used by Puppeteer was probably also outdated. The solution was as easy as to update Puppeteer to the latest version 2.1.1.
we are trying to debug an issue with Chromium (happens in Chrome, Edge, Brave), where it sometimes gets to a state where it does not open a WebSocket to a specific host.
We can see in console logs that it is trying to open the socket, but it never opens the connection. It fails with 1006 error. The same happens in new tabs and in new windows. The behaviour disappears after the browser is restarted or when an incognito tab is used.
There are no HTTP upgrade requests on the server and also the connection does not show up as WebSocket in chrome dev tools. We do not have much else to go on. Any suggestions on what we could try to debug the problem?
I tried to test the web socket with the MS Edge (chromium) Version 83.0.478.58 and Google Chrome Version 83.0.4103.116
In my test, both the Chromium browser works well without 1006 error.
Here is the test code:
<!DOCTYPE html>
<meta charset="utf-8" />
<title>WebSocket Test</title>
<script language="javascript" type="text/javascript">
var wsUri = "wss://echo.websocket.org/";
var output;
function init()
{
output = document.getElementById("output");
testWebSocket();
}
function testWebSocket()
{
websocket = new WebSocket(wsUri);
websocket.onopen = function(evt) { onOpen(evt) };
websocket.onclose = function(evt) { onClose(evt) };
websocket.onmessage = function(evt) { onMessage(evt) };
websocket.onerror = function(evt) { onError(evt) };
}
function onOpen(evt)
{
writeToScreen("CONNECTED");
doSend("WebSocket rocks");
}
function onClose(evt)
{
writeToScreen("DISCONNECTED");
}
function onMessage(evt)
{
writeToScreen('<span style="color: blue;">RESPONSE: ' + evt.data+'</span>');
websocket.close();
}
function onError(evt)
{
writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data);
}
function doSend(message)
{
writeToScreen("SENT: " + message);
websocket.send(message);
}
function writeToScreen(message)
{
var pre = document.createElement("p");
pre.style.wordWrap = "break-word";
pre.innerHTML = message;
output.appendChild(pre);
}
window.addEventListener("load", init, false);
</script>
<body>
<h2>WebSocket Test</h2>
<div id="output"></div>
</body>
</html>
Reference:
Web socket echo test
Try to check the security settings of the browsers and also confirm that you are trying to connect using a secure connection.
I found that 1006 is a special code that means the connection was closed abnormally (locally) by the browser implementation.
I suggest you can check WebSocket.onerror(evt) to get more details about the error.
Helpful thread link:
getting the reason why WebSockets closed with close code 1006
If there is more information then you can try to provide us that may help to narrow down the issue.
I observed exactly the same symptom (not sure about the error code) in Brave (but not in Chrome) during 2020 ... it was a constant issue... but since then it didn't happen almost at all since JAN 2021... except last week (in APR 2021) it happened again (in Brave).
Did anyone else notice the issue still being present from time to time? Or maybe it's a new bug, similar but more rare...
Exactly the same behaviour, socket doesn't reconnect except in incognito or after browser restart.
We have been facing this exact issue where Websocket's upgrade requests never reach the server even though the network inspect tab shows that the request has been fired. No amount of refreshing or new tabs help until we switch over to Chrome. The issue is intermittent and has become impossible to debug but nonetheless our users keep reporting infinite loading bars due to the un-connected websocket.
I went through capturing network logs using chrome://net-exports and viewing it on the net-export viewer and the only time I could capture the logs for the issue, I noticed the browser only trying an IPv6 address and not the IPv4 address. (when our servers don't even have one)
Would it be prudent to engage Brave or Chromium team in this? Anyone ever found concrete repro steps for this?
Is there a way to start the performance profiling programmatically in Chrome?
I want to run a performance test of my web app several times to get a better estimate of the FPS but manually starting the performance profiling in Chrome is tricky because I'd have to manually align the frame models. (I am using this technique to extract the frames)
CMD + Shift + E reloads the page and immediately starts the profiling, which alleviates the alignment problem but it only runs for 3 seconds as explained here. So this doesn't work.
Ideally, I'd like to click on a button to start my test script and also starts the profiling. Is there a way to achieve that?
in case you're still interested, or someone else may find it helpful, there's an easy way to achieve this using Puppeteer's tracing class.
Puppeteer uses Chrome DevTools Protocol's Tracing Domain under the hood, and writes a JSON file to your system that can be loaded in the dev tools performance panel.
To get a profile trace of your page's loading time you can implement the following:
const puppeteer = require('puppeteer');
(async () => {
// launch puppeteer browser in headful mode
browser = await puppeteer.launch({
headless: false,
devtools: true
});
// start a page instance in the browser
page = await browser.newPage();
// start the profiling, with a path to the out file and screenshots collected
await page.tracing.start({
path: `tests/logs/trace-${new Date().getTime()}.json`,
screenshots: true
});
// go to the page
await page.goto('http://localhost:8080');
// wait for as long as you want
await page.waitFor(4000);
// or you can wait for an element to appear with:
// await page.waitForSelector('some-css-selector');
// stop the tracing
await page.tracing.stop();
// close the browser
await browser.close();
})();
Of course, you'll have to install Puppeteer first (npm i puppeteer). If you don't want to use Puppeteer you can interact with Chrome DevTools Protocol's API directly (see link above). I didn't investigate that option very much since Puppeteer delivers a high level and easy to use API over CDP's API. You can also interact directly with CDP via Puppeteer's CDPSession API.
Hope this helps. Good luck!
You can use the chrome devtools protocol and use any driver library from here https://github.com/ChromeDevTools/awesome-chrome-devtools#protocol-driver-libraries to programmatically create a profile.
Use this method - https://chromedevtools.github.io/devtools-protocol/tot/Profiler#method-start to start a profile.
I've written a web app for Firefox Mobile / Firefox OS. My app uses geolocation.
It worked well when I tested it with Firefox for Android and the FFOS simulator add-on by visiting the web address of the application. Recently I've passed the Firefox Marketplace review and my app is installable on FFOS and Firefox for Android. To my surprise, when I installed and ran it, geolocation didn't work.
Here's an excerpt from the .webapp file:
"permissions": {
"geolocation": {
"description": "Required for ....."
}
}
Here's the relevant part of JS:
if(navigator.geolocation) {
navigator.geolocation.getCurrentPosition(positionFound, positionNotFound, {
enableHighAccuracy: false,
maximumAge: 3600000
});
}
else {
$('#location').html('No geolocation support');
}
The else block is not executed, so JS detects that geolocation exists, but the callback is never called, and the GPS icon never blinks.
The app still works and positionFound() is called properly when accessed via its URL, not as an installed app.
How can I make it geolocate after installation?
The following code works for us, however GPS functionality is severely limited on the Geeksphone FFOS 1.2 nightly builds as well as aGPS on FFOS 1.0 (time to first fix ~ 5min). The geoLocation API requires frequent reboots on our devices. For us, FFOS 1.1 worked best so far. Try to use one of the existing GPS apps like "gpsDashboard" before starting your app. This way you know your phone is working.
function geo_success(position) {
alert(position.coords.longitude);
}
function geo_error() {
alert("Sorry, no position available.");
}
var geo_options = {
enableHighAccuracy: true,
maximumAge : 300000,
timeout : 270000
};
navigator.geolocation.watchPosition(geo_success, geo_error, geo_options);
Do your callback functions work properly with fake data?
Here's a post on the Mozilla Hacks Blog that discusses geolocation tips and tricks, as well as limitations with some of the developer devices:
https://hacks.mozilla.org/2013/10/who-moved-my-geolocation/
I am experimenting with azure mobile services and have implemented the authentication example here. This works on most devices ( iOs, IE9 and chrome on desktop, IE10 Surface RT, android ) but on a WP8 device ( a Nokia 920, to be precise ) it returns
"Cannot reach window opener. It may be on a different Internet Explorer zone"
after attempting to return from the authenication providers pop-up. This is mentioned briefly in the link above, but only wrt to connecting to the service from localhost. This is not the case here and other devices work fine. It does not seem to be a problem with any particular authentication provider - all ( facebook, google, twitter, windows connect ) return the same message. And as these other devices work, it seems unlikely that the service is mis-configured, but there could very well be something subtle that I'm missing.
The way I got the authentication to work is not to use Facebook JavaScript SDK, but another flow, described here https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/#step2
For handling the response when I get the redirect back from Facebook, I used the following code:
function handleLoginResponse() {
var frag = $.deparam.fragment();
if (frag.hasOwnProperty("access_token")) {
client.login("facebook", { access_token: frag.access_token }).then(
function () {
// do your thing when logged in
}, function (error) {
alert(error);
});
}
}
This code makes use of jQuery BBQ plugin, found here http://benalman.com/projects/jquery-bbq-plugin/.
This way I can get Facebook auth to work on WP8 and I'm able to pass the access token to Mobile Services login.
A slight problem is that now the access token sticks in my site URL, which I think is a problem if the user decides to share the URL, for example. I think I can get around this by e.g. putting the info in a cookie (or local storage) and then redirecting to the plain URL of my site.