Skip to content
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

reduce strictness of WebRTC support check #50

Closed
skysbird opened this issue Jun 23, 2020 · 3 comments · Fixed by #56
Closed

reduce strictness of WebRTC support check #50

skysbird opened this issue Jun 23, 2020 · 3 comments · Fixed by #56
Labels
exp/novice Someone with a little familiarity can pick up status/ready Ready to be worked

Comments

@skysbird
Copy link

Hi, I have read the code of the new ipfs-utils/src/support.js. I found a problem below:
7a5edc3a6c84a58bb3a4476d393d0b0f35c2a0ff

getUserMedia is not supported in Chrome on IOS, because of WkWebview in IOS. But in some case, we don’t use getUserMedia function, but just want to use WebRTC for text message. So if use the support.js, some application will not work on chrome in IOS. Maybe we should consider to relaxation of conditions for checking WebRTC support?

P.S there is a reply on stack overflow:

WebRTC has three main JavaScript APIs:

  • MediaStream (aka getUserMedia)
  • RTCPeerConnection
  • RTCDataChannel

For apps running inside Safari App, iOS11+, all WebRTC APIs are supported. That includes getUserMedia . Be sure to use adapter.js library for best compatibility, since each browser - including Safari - uses a different name for its implementation. For example, in Safari it's navigator.mediaDevices.getUserMedia() .

But, when using WKWebView or SFSafariViewController , it's a different story:

You can still stream video & audio from local storage or consume live media captured by a peer. Hopefully in iOS 12 we'll see some progress...

@skysbird skysbird added the need/triage Needs initial labeling and prioritization label Jun 23, 2020
@welcome
Copy link

welcome bot commented Jun 23, 2020

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

@skysbird
Copy link
Author

skysbird commented Jul 7, 2020

no one notice me?

@achingbrain
Copy link
Member

I guess it depends on what supportsWebRTC means to the caller. From an IPFS perspective we don't care about getUserMedia, only using WebRTC as a data channel so this check could probably be relaxed.

What do you think @hugomrdias?

@jacobheun jacobheun changed the title About the checking WebRTC support reduce strictness of WebRTC support check Jul 16, 2020
@jacobheun jacobheun added exp/novice Someone with a little familiarity can pick up status/ready Ready to be worked and removed need/triage Needs initial labeling and prioritization labels Jul 16, 2020
achingbrain added a commit that referenced this issue Aug 12, 2020
IPFS' use of WebRTC is only as a data channel, we don't use getUserMedia
and sometimes the user has restricted access to this API so add a
'supports' test that is just for data channels.

Fixes #50
achingbrain added a commit that referenced this issue Aug 12, 2020
The use of WebRTC in IPFS is only as a data channel, we don't use getUserMedia and sometimes the user has restricted access to this API so add a 'supports' test that is just for data channels.

Fixes #50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/novice Someone with a little familiarity can pick up status/ready Ready to be worked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants