Permisos de cámara/micrófono: Cuando el usuario dice 'no'

Admito que, al principio de mi carrera, la gestión de permisos para la cámara o el micrófono con getUserMedia() era una caja negra. Yo solo lo llamaba, esperando que todo funcionara. Si el usuario denegaba el acceso, mi aplicación simplemente se quedaba ahí, sin hacer nada, y yo no tenía idea de cómo reaccionar. De hecho, más de una vez, un cliente me preguntó por qué la app no volvía a pedir permiso, y yo balbuceaba algo sobre la seguridad del navegador. No era una respuesta satisfactoria, ni para ellos ni para mí.

Recuerdo un PR que me rechazaron hace años porque mi manejo de permisos era prácticamente inexistente. El revisor, con toda la razón, me dijo: «Jorge, ¿qué pasa si el usuario hace clic en ‘Denegar’? ¿La aplicación deja de funcionar para siempre?». Ahí entendí que había un vacío importante en mi conocimiento, y me puse a investigar. Es una situación común en el desarrollo web interactivo: necesitas acceder al hardware del usuario, pides permiso, y el usuario simplemente dice que no. El problema es que, después de un primer ‘Denegar’, los navegadores modernos, como Chrome o Firefox, no vuelven a mostrar el prompt de permisos automáticamente. Cualquier llamada posterior a getUserMedia() se resuelve de inmediato con un error de denegación, sin avisar al usuario. Y claro, no quieres molestar al usuario pidiendo permisos en cada carga de página si ya los ha denegado.

Entendiendo los estados de los permisos

La clave para manejar esto de forma elegante es entender que el navegador mantiene un estado para cada tipo de permiso. No es que no puedas volver a intentar obtener el stream, es que el navegador ya decidió, y solo cambiará de opinión si el usuario lo hace manualmente. Para lidiar con esto de una manera más controlada, la especificación de la Permissions API, implementada por navigator.permissions, nos da una herramienta súper útil. Con ella, podemos consultar el estado de un permiso específico antes de siquiera intentar usar getUserMedia().

Puedes preguntar por el estado del micrófono o la cámara, por ejemplo, y el navegador te devolverá uno de tres estados:

• 'granted': El permiso ya fue concedido. Puedes usar getUserMedia() con tranquilidad.
• 'denied': El permiso fue denegado. El usuario o el sistema no lo permiten. En este caso, no tiene sentido llamar a getUserMedia() de nuevo, porque fallará.
• 'prompt': El permiso nunca se ha solicitado o la decisión fue revocada. Aquí sí puedes llamar a getUserMedia(), y el navegador mostrará el cuadro de diálogo al usuario.

Aquí te dejo un ejemplo de cómo podrías consultar estos estados:

navigator.permissions.query({name: 'camera'})
 .then((permissionObj) => {
  console.log('Estado de la cámara:', permissionObj.state);
  if (permissionObj.state === 'denied') {
    // Mostrar mensaje al usuario para que cambie el permiso manualmente
  }
 }) 
 .catch((error) => {
  console.error('Error al consultar permiso de cámara:', error);
 });

navigator.permissions.query({name: 'microphone'})
 .then((permissionObj) => {
  console.log('Estado del micrófono:', permissionObj.state);
  if (permissionObj.state === 'denied') {
    // Mostrar mensaje al usuario para que cambie el permiso manualmente
  }
 })
 .catch((error) => {
  console.error('Error al consultar permiso de micrófono:', error);
 });

Este enfoque me gusta mucho más que otros que vi, como el de medir el tiempo entre la llamada a getUserMedia() y su resolución para inferir el estado. Eso me parece un parche, una forma de sobreingeniería para algo que ya tiene una API dedicada. ¿Por qué complicarse cuando hay una solución más directa y declarativa?

La Experiencia de Usuario: El factor clave

Aunque navigator.permissions.query() es excelente para saber el estado actual, no te permite forzar un nuevo prompt si el usuario ya denegó el acceso. Y esto es crucial. Si el estado es 'denied', no hay código JavaScript que pueda hacer que el navegador muestre de nuevo la ventana de permisos. El control lo tiene el usuario en la configuración de su navegador.

Por eso, la segunda parte fundamental de este problema es la experiencia de usuario. Si el usuario deniega el permiso, tu aplicación debe ser clara, no solo sobre qué necesitas, sino por qué lo necesitas y cómo pueden cambiarlo. Por ejemplo:

navigator.mediaDevices.getUserMedia({ audio: true, video: true })
  .then(function(stream) {
    // Éxito: haz algo con el stream
    console.log('Stream obtenido con éxito.');
  })
  .catch(function(err) {
    console.error('Error al obtener stream:', err);
    if (err.name === 'NotAllowedError' || err.name === 'PermissionDeniedError') {
      // El usuario denegó el permiso
      // Ojo que los nombres de los errores pueden variar un poco entre navegadores
      document.getElementById('permission-message').innerHTML = `
        
Necesitamos acceso a tu cámara y micrófono para que puedas participar en la videollamada.
        
Parece que denegaste el permiso. Por favor, actívalos manualmente en la configuración de tu navegador para este sitio.
        
Normalmente, puedes hacerlo haciendo clic en el icono de la cámara o el candado en la barra de direcciones.
      `;
    } else if (err.name === 'NotFoundError') {
      // No hay cámara/micrófono disponible
      document.getElementById('permission-message').textContent = 'No se encontró cámara o micrófono en tu dispositivo.';
    } else {
      // Otros errores
      document.getElementById('permission-message').textContent = 'Ocurrió un error inesperado: ' + err.message;
    }
  });

Mostrar un mensaje claro, en lugar de dejar la app en un estado confuso o roto, es fundamental. Explica el beneficio, la necesidad y el camino a seguir.

Mi opinión final

Al final, por más magia que quieras hacer con código, el control lo tiene el usuario y el navegador. Intentar sortear esa seguridad es una batalla perdida y, francamente, una mala práctica. Mi filosofía es siempre ir por la solución más simple y robusta. En este caso, eso significa usar la Permissions API para saber dónde estás parado y, si el usuario denegó el acceso, respetarlo y guiarlo para que lo cambie por sí mismo si realmente quiere usar la funcionalidad.

Me costó un tiempo entender que, a veces, la solución no es más código, sino mejor comunicación. Ojalá hubiera sabido esto de los estados de los permisos y la importancia de la UX cuando empecé. Me habría ahorrado noches de frustración intentando que el navegador hiciera algo que, por diseño, nunca iba a hacer automáticamente.