Chrome apparently stops updating a page when you go idle (i.e. when the screen saver comes up).
My problem is I've written an alarm app, and it doesn't work because the Javascript stops running when the computer goes idle. Is there any way around this?
Update: After testing a few different things, it seems that Chrome doesn't stop updating a page, it just stops rendering it. So for my problem (an alarm app), this is solved.
Are you using requestAnimationFrame? I know Chrome explicitly pauses those callbacks, but it may not also pause setTimeout.
Related
I would like to have a web page being able to act like a music player.
The user enqueues a list of audio files (hosted on the server) and they start playing. When the first audio is over, the second begins, etc, until the last one.
I was able to easily implement this functionality using an <AUDIO> element, and replacing its src attribute with Javascript by adding an event listener on the ended event.
The problem is that this does not work consistently on mobile, because once the screen is locked, the Javascript does not keep executing. It may work for one song or two, but at some point it stops "skipping" to the next audio track.
From my understanding, this behaviour is caused by the fact that mobile browsers stop the Javascript event loop after some time to save battery when the screen is locked. I am aware of the Screen Lock API, I assume keeping the screen always on would solve my problem, but I don't want to keep the screen always on.
I could delegate playing audio files to a web worker, which should theoretically keep running in the background. Still, I'm not sure it won't be stopped when the screen is locked, and most importantly I am not sure it can even play sounds.
Is there anything similar to the Screen Lock API that allows me to ask permission to keep scripts executing also when the screen is locked?
If not so, how could I overcome this problem?
After some research, I discovered that the act of killing the javascript event loop is highly browser-specific.
Chrome for Android seem to let the playback run indefintely.
Firefox for Android is stricter, and kills the event loop.
The System Wake Lock looks like a promising API for solving the above problem. At the moment, the W3C is still in process of collecting use cases in order to be able to define a new standard:
https://github.com/w3c/system-wake-lock/issues/4
I'm using an iPhone 11 Pro with iOS 15.3.1.
I'm trying to figure out why when visiting my website, Safari is freezing most of the time when the page loads. Sometimes the page loads the first time I visit it, but on reload it basically freezes with no interaction.
When I connect the iPhone to a Mac and use the Safari inspector to connect to the webpage on the iPhone, the inspector is basically blank on all screens. If I go to the "Elements" tab, nothing shows. If I go to the "Console" tab and try to execute some Javascript, nothing happens when I press enter.
On OSX, I can see similar behavior, except I can actually open the inspector before I visit the page. In this case, when it freezes I can see a few elements in the "Elements" tab, but that's about it. Any sort of interaction I try to do in the inspector results in nothing happening.
I'm at kind of a loss. How can the development experience for such a popular OS/Browser be so terrible, and how do I work around the inspector itself not working? I can't replicate this freezing on anything besides Safari.
To be absolutely clear on my question:
What is your process to debug a webpage in Safari when it is in a state where the inspector no longer interacts with the webpage?
I did a broad divide and conquer of my app, commenting out top level code and working my way down uncommenting until I found the exact line that causes the freeze.
It seems calling HTMLInputElement.setSelectionRange() inside an onfocus event handler function caused an infinite synchronous loop in Safari, perhaps Safari synchronously blurs the input and refocuses for some reason when that function is called. And on page reload Safari was trying to focus on an input with that code automatically. That is my guess at least, removing the setSelectionRange() resolves the freezing problem.
Luckily, the freezing was fairly consistent so the divide and conquer approach worked. Unluckily, the inspector really should have done its job and picked up on the fact that the page was hanging and told me which function code execution broke at when Javascript was forced to stop, like Chrome or Firefox would.
If anyone has any better ideas for debugging these kinds of issues in Safari besides the programming equivalent of a short circuit test, I'll gladly accept the answer.
The Pause script execution button in Chrome DevTools is great for figuring out what does what... EXCEPT when there's code that's just constantly running so it gets paused before you can do what you want it to do. This is very annoying and I was wondering if there's a way to get around it. (Doesn't have to be Chrome)
I'm using Canvas in html5 with EaselJS, and after playing with the interface for a while, the timer events in Easel started firing really slowly. These timer events should have been running at 20Hz, but were instead running at 1Hz. The odd part was I commented out the '_testMouseOver' function in easel, and the timer still ran slowly some of the time.
Things got weirder when I loaded the page and set up a console log in the _testMouseOver function. Sometimes it would run at 20Hz, printing out many statements, but other times it would run at 1Hz. The crazy part was: when I scrolled down on the page (not on the canvas), the timer returned to 20Hz!
This behavior remained when I commented out _testMouseOver, so that basically setInterval(fun, 50) was running 'fun' at 1Hz. This was reproduced roughly 50% of the time I refreshed the page. I also checked the cpu load via Activity Monitor and Chrome was only taking 10%.
Whats really strange is that when I closed that tab and opened a new one with the same page, the behavior disappeared.
What could have happened, and what other debugging steps might you explore?
Other details:
Chrome 52.0.2743.116 (64-bit)
OSX 10.10.5
Oftentimes my app will hang on the "trigger.io FORGE" splash screen and never display my UI.
I have this happening both in the simulator and on a real device. It's intermittent which leads me to think maybe it's a race condition somewhere (do I need to be waiting for forge to initialize?).
I have no idea how to debug this as the trigger console isn't spitting out an error even when showing the debug output.
Anything I should check? It's weird because if I put in a call like this:
setInterval(function() {
forge.logging.log('hi');
}, 1000);`
I can see that my JavaScript code is being executed (and continues to execute as this is successfully logged until I kill the app).. but it's still hung on the splash screen. Oftentimes hitting the home button and re-entering the app will work. But sometimes it takes a few rebuilds before it will get past the splash screen.
I've now seen this on 2 different dev environments, 2 different physical devices, and the iOS simulator.
This sounds like a rare issue on iOS that causes the DOM event Forge listens for to hide the splash screen not to fire.
The easiest way to fix this is to make sure the splash screen is hidden by calling forge.launchimage.hide() at the point your code is ready. See http://docs.trigger.io/en/v1.4/modules/launchimage.html#hide for more details.
If that doesn't help then let us know and we can try to track down what else it could be.