-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
onReady not called on iOS Safari #340
Comments
I notice the same issue on http://cookpete.com/react-player/. To reproduce:
Expected (from OS X Safari): Actual (iOS): Note that |
Yup, can confirm I have the same issue on Mobile Chrome as well - the onReady event is not called. @rijk Have you tested on Android? |
My guess is that because iOS tends to prevent any loading etc before the user has interacted, the I guess a possible fix would be to manually call |
Yup, this seems to be the problem. In my case, this created a serious usability issue, as I display a loading spinner overlay until I get the I worked around it now by checking the user agent for iOS, and disabling the page's loading state manually in that case. If we can't do anything to fix this, I do think it would be a good idea to add this to the documentation, under PS: The problem was not related to the order of the calls — at least not for me. So, personally, I see no need to apply a fix there. |
So what was the problem in the end? |
Right, so the problem was that the page just kept 'loading' when you opened it on an iPhone. Because the loading overlay blocked the user from interacting with the video. I think it would be good to add this to the |
Ah I see. Your loader was preventing user interaction, which was preventing There must be a combination that works. I wonder if |
You got it.
Maybe, but I'm not sure. When I test with your demo, no handler is called until you actually tap a button. Autoplay doesn't do anything either; iOS just doesn't allow playing unless the user has explicitly requested it (to save data, I suppose). |
Yep, this is a popular issue that people are constantly battling against. |
I hope my patch could help anyone landing here: componentDidMount() {
// on iOS we need to force the load event
// to get the onReady event firing properly
// where of course this.refs.video is so rendered: <ReactPlayer ref='video'>
const videoElement = this.refs.video.getInternalPlayer()
videoElement.load()
} |
Awesome! |
Calling `load()` manually fires onReady before `onPlay`, instead of after Fixes cookpete/react-player#340
This is great, but the IOS 13 on tablets has changed the useragent for Safari. I have rolled a quick fix which is to test for Safari and also touch device and call the player.load() something like:
There is probably a better way of doing it a touch detection is not too reliable. |
Calling `load()` manually fires onReady before `onPlay`, instead of after Fixes cookpete/react-player#340
Checking on Safari, it works fine for the initial load, but not when you seek (OnSeek) it does not work, should it be monkey patched elsewhere for IOS? |
@scottmcdonnell this is probably no longer relevant to you but #1004 and the fix in #1005 may be of interest. |
Calling `load()` manually fires onReady before `onPlay`, instead of after Fixes cookpete/react-player#340
Calling `load()` manually fires onReady before `onPlay`, instead of after Fixes cookpete/react-player#340
This worked well. Adding some more cases to avoid multiple calls.
|
Calling `load()` manually fires onReady before `onPlay`, instead of after Fixes cookpete/react-player#340
@rijk |
Calling `load()` manually fires onReady before `onPlay`, instead of after Fixes cookpete/react-player#340
I am loading an .mp4 file from AWS. On OSX Safari it is working fine, no problems, but on iOS the
onReady
function is never called. This happens both on v0.25.3, and the latest (v1.2.1) so it's not a recent bug. I did not find any info about this in the "Mobile considerations" section, however.Is this a known issue? Are there any workarounds?
The text was updated successfully, but these errors were encountered: