When we activate a Twilio Client connection using Javascript library, every few seconds the hourglass icon shows up in the pointer. If we destroy the session via code and then reconnect it, the hourglass does not show any more. But a reload of the page brings the problem back. The periodic hourglass distracts the user. Is there any way to turn it off?
We have tried it in Chrome, Edge and Firefox under Windows, with similar results.
The problem does not occurr in OSX Chrome or Safari
Related
So I am trying to record my screen for a demo video. I am using Camtasia 2019 but I am also trying out Bandicam. I have it setup to record a web application on my google chrome web browser but for some reason when the web browser is refreshed it stops the recording. Both camtasia and bandicam have this issue so I am not sure what is causing that, and I am wondering if anybody else has ran into the same issue?
Well if anybody wants an answer to this, the issue was with the cpu of my virtual machine. I did not have enough resources allocated to handle the page refresh while recording. If you watch the performance of your machine while refreshing your web browser you will see it shoot the cpu up to the top of the processing power so when it would do that the video would stop recording. The fix was to allocate more resources to the virtual machine.
I'm using the RTCMulticonnection library for a webrtc video streaming platform. It functions pretty much like this: There's a list of users, each with a profile page that has a chat button. Upon clicking this chat button, the caller is taken into a chat room page (a new browser tab) where he issues a connection.open() to create the room.
Afterwards a chat request is send through the node server to the callee, which gets a confirmation popup. If he accepts he is taken in the chat room page (a new tab) where a connection.join(roomId) is called.
My problem is that on ipad/iphone both the audio AND video stream are added only on the first call, either if you are a caller or a callee. If you afterwards want to call someone else on the ipad only the audio stream is added to the chat view, but from the remote side you get the video stream just fine.
Is there a flag that gets set up somewhere, somehow that I'm missing?
Also there's some cases that causes iOS devices to freeze up pretty bad so that they need a hard reboot, but I haven't pinned down the culprit.
On desktops and android devices the flow seems to work fine... so far.
This is a bug in WebKit:
Safari on iOS11 Freezes when viewing a cropped remote video
Frequent situations where iOS device locks up, requiring a hard reboot when consuming webrtc streams on IOS
It's solved since iOS 11.2.
I'm making a small PWA where a user can type in a text box, and if they lose internet connection for some reason, they can continue typing, leave the page, and then once connection is restored, their latest typing will have synced.
I'm unsure of how I can actually test this on my devbox though. I'm using a node js server and developing using Chrome and Win10.
If I go offline using Chrome's offline toggle in the network tab, the requests are rejected straight away and not queued up (I verified this wasn't just my issue with by using the examples of background sync from the chrome developers page). Windows 10 also won't let me go off a wired connection very easily, and even if I did, the server is still running on localhost, so I would be able to make requests right?
Is the best thing to do deploy it to somewhere like GitHub pages and then remove my ethernet cable? A bit unsure about how I can actually test this.
Switching Network throttling to Offline doesn't have any effect either in Chrome or Chrome Mobile.
Chrome's network status monitor doesn't know about devtools throttling, sadly.
ref: Chromium Issue 609081
However since Chrome 63 it's possible to trigger sync event manually from DevTools > Application > Service Worker > Sync
ref: Chrome 63: Trigger background sync events with custom tags
I'm able test trigger service worker sync event only on Chrome Mobile (inside an emulator) and only by switching Airplane mode to on and later back to off.
For Windows 10 I've filled Issue 803803
I'm developing a site for a client and am stuck at this point, as both of us have been able to recreate this issue in Chrome on Android.
For whatever reason, when we load this page on Android in Chrome:
http://miso.gostppro.com
The video loader just keeps spinning and spinning and the video never plays.
And tapping it on it doesn't do anything either (doesn't start the play, doesn't open it in YouTube app, nothing).
It works just fine in other browsers (Firefox for Android loads it and plays it just fine), so I'm confused as to why this is happening.
What am I missing?
Is it some call in the API or something?
I'm lost.
In short, it won't work. Quoting the documentation:
The HTML5 element, in certain mobile browsers (such as Chrome
and Safari), only allows playback to take place if it's initiated by a
user interaction (such as tapping on the player). (...) Due to this
restriction, functions and parameters such as autoplay,
playVideo(), loadVideoById() won't work in all mobile environments.
You're calling event.target.playVideo(); in your onPlayerReady handler, which is not allowed in mobile environments and throws a warning in console (for future reference - I highly recommend using Remote Debugging in Chrome).
So, back to your problem - I'd just get rid of the onPlayerReady handler and use autoplay player variable instead. It should work on desktops and not break the player on mobile either.
I tested your webpage on my Nexus 5 running Android 5.1.1 and found a few issues:
First I was getting this error:
Failed to execute 'postMessage' on 'DOMWindow': https://www.youtube.com !== http://miso.gostppro.com
Which I thought was an http vs https error, but after I refreshed the page with error went away and I saw a new warning:
Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture.
As pointed out in jkondratowicz's answer, this is a byproduct of mobile browsers disallowing autoplay on HTML5 videos. The only think I can think of is remove any JavaScript related to the player and the autoplay parameter and allow the user to manually start video playback when they're ready.
I was also getting mixed results results with adding an listener to the page load event which calls play() on the iframe:
function callback () {
document.querySelector('ytplayer').play();
}
window.addEventListener("load", callback, false);
We have a website in Wordpress, using a home-made theme. Some weeks ago, we noticed some page load time issues of our website, reported in Google Analytics. If we check the website using speed tests as Pingdom, Webpagetest and GTMetrix, we don’t see any performance issues. We checked the Analytics data, the main issues (average load time) are in iOS – Safari browsers (iPhone, iPad, in-app). If we check the specific data we find that, for example, one page could have 30 seconds page load time, but is not always and it happens for a single user using Safari 9 browser in Apple mobile device.
One more thing, we tested using those devices, but nothing weird happened.
Any idea what could be happening.
It's not just about the mobile device but the carrier also.
Apparently your carrier is better than the other(s).
The second biggest issue with mobile carriers is the number of simultaneous requests allowed. A desktop will download about 6 page resources simultaneously. Mobile, one, maybe two.
The biggest issue is the tower will often drop the radio signal between the phone and the tower between request.
so with mobile it is very important to minimize the number of requests per page.