I'm trying to experiment with the getUserMedia API that should be enabled in the ios11 beta as this questions seems to suggest: question
I'm trying to setup the same on my iPad with the latest public beta (5) but I can't get it to work. The error I get is:
NotAllowedError (DOM Exception 35): The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
A popup that asked for permission never appears so I didn't deny this, I don't know what is going wrong. I tried enabling/disabling the experimental feature 'Remove Legacy WebRTC API' in the browser settings, but this has no effect either.
Do I need the developer beta to access this feature?
Thanks!
getUserMedia requires HTTPS unless you use the "allow media capture on insecure sites" shown in the first screenshot of this webkit blog post
You must be getting this error on Safari. iOS11 stops autoplay audio and Chrome will do the same in January, 2018.
How to enable autoplay on Safari?
- Go to Safari > Preferences > Auto-Play
- Instead of "Stop Media with Sound", pick "Allow all Auto-Play" option for your website and try again. The error will not pop-up on your machine.
How to permanently enable autoplay on Safari?
- Handle the case with a script and inform your user to allow your website
- Or change your interface.
Related
In a previous answer regarding Notification Delegation between Chrome and an Android TWA app it was said that:
"If the TWA has notifications disabled in Android Settings, we disable
them in Chrome instead. There's a little bit of latency with how this
gets propagated, but things should get updated on the next TWA launch
at latest.
How exactly Notification Delegation does work?
On my site I am sending the user to androids app notification settings when I find that notifications are not allowed in the browser.
But upon the users immediate return, the changes are not propagated to Chrome (to be expected from the comment above since the TWA is not launched again).
I wonder if there is anyway I can speed this up? Otherwise the user is forced to exit the page completely and restart the app before the permission is granted, which is not a very good user experience.
It seems the only workaround would be to force restarting the application, which is not a great user experience. I have filed an issue on Chromium bugs to track a fix for this: https://bugs.chromium.org/p/chromium/issues/detail?id=1064300
I recently updated to iPadOS 13.1 and I can't get "Beta by Crashlytics" to accept an iPad Pro 12" as a device that can install the required software from https://apps.crashlytics.com/register/...
I am met by a screen that says
Beta by Crashlytics
Open the invitation email on your device to begin registering for beta testing
Can I do anything to make Safari on iPadOS 13.1 accept my invitation, or do I have to wait for a bugfix for this?
Thanks.
Alternate answer
Thanks to iCediCe for showing me in the right direction. Following their advice made me realize there is an even easier way.
The easier way - instead of making all webpages conform to mobile - you can make a specific webpage conform to mobile.
Press aA on the leftmost point of the address bar in Safari, a menu pops up and there you can select "Request Mobile Website". After that Crashlytics/Beta will show up.
Goto Settings -> Safari -> Request Desktop Website -> All websites and disable it. This will cause it to use iOS user agent string not macOS user agent string thous making it work again.
I'm currently trying to set up a connection between my web client and my iOS app, but for some reason my iOS client only sees a black box when using Chrome (version 33). I can see the video just fine if I use Firefox (both in my app and when I put the browsers side-by-side, they can see each other).
This doesn't appear to be a documented known issue with the JavaScript SDK, and I can't see any recent discussion about this on the forums (last post was mine).
The iOS sample can be located here (samples/OpenTokHelloWorld) with the browser page in samples/OpenTokHelloWorld/browser_demo.html
I suggest cd'ing into samples/OpenTokHelloWorld and running python -m SimpleHTTPServer, as it can't be run from a file:/// path.
Here is what my iPad sees:
Chrome:
Firefox:
And Chrome/Firefox (respectively), both publishing video from the same camera
Edit: after testing on other machines, it may be something specific to my environment even though none of my extensions run in Incognito and I don't have any custom plugins installed.
It looks like the OpenTok mobile SDKs with the specific webcam I was using has issues. On Android the video stream will display for a brief moment then segfault, and on iOS there will be no video at all.
I have tested this many times and could not reproduce what you are seeing in your chrome.
Without seeing any console errors or iOS logs the best suggestion is to try clearing your cache, or maybe restarting your computer (longshot)
I have a site with an embedded YouTube Flash (AS3) player, and it's no longer working in Safari.
Check out this fiddle, the code for which is merely:
<object type="application/x-shockwave-flash"
data="http://www.youtube.com/apiplayer">
</object>
In Chrome, Firefox, and IE, the request to http://www.youtube.com/apiplayer returns normally (200). In Safari, the server returns a 303 to https://youtube.googleapis.com/apiplayer.
This player loads, but I am unable to interact with it in JavaScript. I assume that's because it's served over https — though I am explicitly requesting http — resulting in a mixed-mode security issue. Here's error I see when trying to do anything with the player (this is with the full chromeless player embed code):
>>> player.playVideo()
Error: Error calling method on NPObject.
If I change Safari's user agent to something else, or even just mangle the word "Safari", then the correct player is loaded. I also have no trouble loading the Vimeo and Viddler players (http://vimeo.com/moogaloop.swf and http://www.viddler.com/player/key).
I see this both in the stable Safari release and in the WebKit nightly. It also occurs with my extensions disabled and in Private Browsing mode.
I tried working around it by embedding http://youtube.googleapis.com, hoping that there would be no redirect and I'd get the player over http. But it still redirects to https, and it does so in all browsers.
I filed this YouTube API ticket last week, but there's been no response so far.
Seems like there's a playback issue with Safari and YouTube. There're multiple solutions suggested at MacRumours http://forums.macrumors.com/showthread.php?t=1098606, like switching to 32 bit browser, use non-HTML5 version, etc.
One that seems to work is below:
Select Safari > Preference > Privacy > Details
Search for Youtube
Delete the cookie called youtube-nocookie.com then click Done.
Restart Safari and try again.
The YT API bug report has been answered, and there is a workaround: appending the version to the URL:
<object type="application/x-shockwave-flash"
data="http://www.youtube.com/apiplayer?version=3">
</object>
Apparently when the version is not specified, they fall back to the AS2 player for Safari only. I'm not sure why that would force the switch to https, but regardless, this works.
When I visit the Spotify Play Button demo page (https://developer.spotify.com/technologies/spotify-play-button/) in Opera 11.62, clicking on the Play Button gives me the (mostly-expected) popup:
The application "Spotify" must be launched to open the link:
spotify:
Do you want to proceed?
If I click yes, the Spotify app then launches (if not already running) and gets focus, but does not play anything. I suspect the link is getting broken by Opera somehow (notice that it has the spotify: protocol name but nothing after that). The Play Button on my own site produces the same behavior. Works fine in Firefox on the same machine.
Has anyone else experienced this?
Yes, sadly, that's the case. There's a similar issue in Opera's bug tracker.
I think your particular issue could be related to Opera's lack of support for cross-origin resource sharing (CORS). CORS support is coming is available in Opera Next, but not Opera 11.62. If it doesn't work in Next, I encourage you to file a bug report.