#safari #webrtc #getusermedia
Вопрос:
я думаю, что у меня неожиданное поведение getUserMedia в Safari, и я хотел бы знать, не пропустил ли я что-то.
В Chrome/Firefox, если я не разрешу первое getUserMedia({audio: true, video: true})
приглашение, каждый следующий вызов к нему завершится ошибкой: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
и это кажется прекрасным.
Однако в safari, если я не разрешу первому вызову getUserMedia, второй вызов с теми же ограничениями будет запрашиваться снова, любые другие ограничения не будут выполнены с предыдущей ошибкой.
Я создал здесь простое хранилище воспроизведения, которое вы можете запускать в каждом браузере для сравнения (вы должны отказаться от первого запроса, чтобы воспроизвести ошибку). Странно, что один и тот же код работает каждый раз на jsfiddle только для safari и сохраняет то же поведение для другого браузера (я думаю, из-за iframe, в котором выполняется код)
Вот запись того, как я воспроизводил свою проблему, чтобы лучше понять.
Заказ вызова getUserMedia:
// 1: press "Not allow"
getUserMedia({ video: true, audio: true });
// 2: will prompt again (that's the bug) and press "Allow"
getUserMedia({ video: true, audio: true });
// 3: will fail (that's the expected behaviour)
getUserMedia({ video: true, audio: true });
// 3bis: will fail too (that's the expected behaviour)
getUserMedia({ video: {deviceId: {exact: 'aValidDeviceId' }}, audio: {deviceId: {exact: 'aValidDeviceId' }} });
Я что-то пропустил или это действительно ошибка в safari ?
С уважением
Комментарии:
1. В чем здесь проблема? Почему ваш код заботится о том, когда Safari терпит неудачу
"NotAllowedError"
?
Ответ №1:
В Сафари здесь нет ничего плохого. Браузер-это «агент пользователя« в глазах спецификаций, которые говорят:
Это намеренно расплывчато описывает детали пользовательского интерфейса разрешений и то, как UA определяет намерения пользователя. UAS должны иметь возможность исследовать множество пользовательских интерфейсов в рамках этой структуры.
В Интернете нет единой модели разрешений. Это хорошая вещь.
Если вы обнаружите, что пишете код, который зависит от того, как работает один браузер в отношении разрешений, остановитесь и переосмыслите.
Любой код, который зависит от предсказуемого ответа Safari "NotAllowedError"
, скорее всего, пытается социально спроектировать результат, возможно, чтобы помочь пользователям с помощью кнопок браузера, которые нужно нажать, чтобы обеспечить доступ к вашему сайту, необходимый для правильной работы.
Но браузеры не могут отличить ваши действия от действий вредоносного веб-сайта, и им нужна некоторая слабина для защиты пользователей.
Поэтому правильный способ отреагировать на a "NotAllowedError"
-предположить, что он исходил от пользователя. В тех случаях, когда это исходит от агента пользователя, предположим, что агент действует в интересах своего пользователя.
Если вы подозреваете, что агент пользователя ошибается, пожалуйста, сообщите об ошибке в этом конкретном агенте пользователя, чтобы его можно было улучшить.
Разрешения — это сложно.
Веб уникален тем, что позволяет безопасно просматривать неочищенные, даже вредоносные сайты.
Браузер («агент пользователя») является единственной доверенной стороной, которая, как считается, действует в наилучших интересах своего пользователя, когда дело доходит до разрешений. Сайтам нельзя доверять управление ими.
Но браузеры довольно сильно отличаются тем, как они управляют разрешениями своих пользователей. Это включает в себя то, как они реагируют, когда пользователь, по их мнению, был достаточно обеспокоен. Это связано с тем, что идеальный компромисс между удобством и конфиденциальностью еще не найден. Таким образом, дифференциация и инновации в этой области хороши, и еще слишком рано ее обызвествлять.
Отказ от ответственности: Разрешения развиваются
Браузеры не идеальны. Веб-разработчики несут основную тяжесть этого несовершенства и дифференциации, и их нельзя винить в том, что они хотели, чтобы все было проще. В конце концов, большинство из нас работает на не вредоносных сайтах.
Поэтому, возможно, бывают случаи, когда социальная инженерия вокруг какого-либо браузера оправдана (после того, как вы зарегистрировали в нем ошибки). Но в stackoverflow я думаю, что мы сначала должны дать «правильный» ответ и предварить все остальное в качестве обходных путей.
Ответ №2:
Это не совсем ошибка. Это ожидаемое поведение. Safari, в отличие от Chrome(ium) и Firefox, не настаивает на принятии или отклонении пользователями разрешения на доступ к мультимедиа.
Он спрашивает снова в следующий раз, когда пользователь говорит «да», а также когда она говорит «нет».
Было бы неплохо, если бы медиа-материалы Safari были предсказуемы для разработчиков, привыкших к другим браузерам, но это не так.
Комментарии:
1. Спасибо за ваш ответ 🙂 я тоже понял, что это не предсказуемо, но меня удивляет, что при отказе от первого запроса только второй вызов getUserMedia снова вызовет запрос, все остальные будут завершены с ошибкой NotAllowedError независимо от ответа, который вы дали
2. Однажды я попал в такую ситуацию, когда у меня не было времени. У меня не было времени, чтобы разобраться в этом. Я думаю , что переход в Настройки / Конфиденциальность / Safari и очистка разрешений камеры приведет к сбросу настроек. Но вы никак не можете разумно попросить пользователя веб-сайта сделать это.
3. Да, определенно не жизнеспособное решение (даже если проблема, о которой я упоминаю, появляется на странице первого посещения), мечтал бы, чтобы после отказа все последующие вызовы, такие как Chrome или Firefox, по крайней мере, были согласованными. Я добавил видео с воспроизведением, чтобы лучше понять ситуацию в исходном вопросе