Guías
Compatibilidad de navegadores y dispositivos basada en pruebas reales
La validación del 7 de agosto de 2026 cubre Chromium 150 en Debian Linux, dos perfiles independientes, transferencia real de texto y archivo, y vistas de 1280×800 y 390×844.
Actualizada el 2026-08-07 · aproximadamente 736 palabras
Resultado probado en esta versión
El pase automatizado de esta entrega se ejecutó con Chromium 150.0.7871.124 sobre Debian GNU/Linux 12. Se iniciaron dos perfiles de navegador independientes contra una vista local del Worker de producción. Un perfil creó un Pase, el segundo entró con el código, ambos abrieron el DataChannel y se envió un texto único. Después se subió un archivo de prueba y el segundo perfil reconstruyó su nombre y contenido.
También se revisaron las páginas públicas en 1280×800 y en un viewport de 390×844. El segundo caso demuestra la respuesta del diseño y los controles en dimensiones móviles dentro de Chromium; no convierte el equipo en un teléfono real ni prueba cámara, suspensión del sistema, red celular o WebView. Esa diferencia se conserva deliberadamente en vez de etiquetar la emulación como prueba de dispositivo.
Qué capacidades necesita un navegador
El flujo depende de WebSocket, RTCPeerConnection, RTCDataChannel, Blob, URL de objetos, TextEncoder y APIs habituales de archivos. El QR se puede mostrar sin cámara; para escanear desde la propia interfaz, el navegador necesita acceso compatible a cámara y el usuario debe conceder permiso. Copiar o compartir puede depender de permisos, contexto seguro y soporte del sistema.
Una página que carga correctamente no demuestra por sí sola que WebRTC vaya a negociar en esa red. La compatibilidad es una combinación de motor, versión, políticas, dispositivo y conectividad. Extensiones de privacidad, navegadores administrados y modos integrados dentro de otras aplicaciones pueden cambiar capacidades aunque usen un motor parecido a otro navegador conocido.
Qué no se ha probado en este pase
No se ejecutaron pruebas reales en Safari, Firefox, Edge con su distribución oficial, iPhone, iPad, Android físico, Windows ni macOS. Tampoco se validaron navegadores integrados de redes sociales, lectores electrónicos o televisores. Sería razonable esperar WebRTC en muchos navegadores modernos, pero esa expectativa no se presenta aquí como un resultado confirmado de Mándamele.
No se probó cada combinación cruzada, por ejemplo Safari móvil contra Firefox de escritorio, ni cámara QR en hardware. Si una organización depende de una combinación concreta, debe realizar una transferencia de texto y un archivo no sensible antes de adoptar el flujo. Una lista de nombres de navegador sin versión, red y caso de uso ofrece una seguridad engañosa.
Cómo hacer una prueba de compatibilidad útil
Actualiza ambos navegadores, abre mandamele.com directamente y evita WebViews. Crea un Pase nuevo, conecta el segundo navegador y envía una frase identificable. Después usa un archivo pequeño de texto, comprueba el nombre, descárgalo y compara su contenido. Finalmente prueba un archivo representativo, siempre dentro del límite de 50 MB, manteniendo ambos dispositivos despiertos.
Repite en la red que se utilizará de verdad. Una prueba con dos perfiles en el mismo equipo valida la aplicación y el transporte local, pero no reproduce NAT corporativo, una VPN o una red móvil. Si el caso requiere esas redes, la matriz de aceptación debe incluirlas explícitamente. Documenta versión exacta y fecha porque el navegador puede cambiar con una actualización.
Diferenciar interfaz, conexión y archivo
La compatibilidad visual incluye que el menú, el selector de archivo, el campo de código y la conversación sean utilizables sin desbordes. La compatibilidad de conexión exige que WebSocket y WebRTC funcionen. La compatibilidad de archivo añade memoria, selección, creación de Blob y descarga. Un navegador puede superar una de estas capas y fallar en otra.
En móvil, la aplicación mantiene visible un selector de archivo; en escritorio añade arrastrar y soltar. Esas rutas llegan al mismo envío. La cámara QR es opcional porque siempre se puede escribir el código. Del mismo modo, una previsualización no es requisito para recibir: el formato puede descargarse aunque el navegador no sepa mostrarlo.
Política de afirmaciones de soporte
Esta guía se actualizará cuando existan nuevas pruebas reproducibles. Un resultado positivo confirma la versión y el escenario anotados, no todas las versiones futuras. Un fallo en una red restrictiva tampoco demuestra que el motor sea incompatible; puede ser una consecuencia de la ausencia de TURN o de una política local.
Al informar de un problema, incluye navegador completo, versión, sistema, dispositivo, tipo de red y etapa. No compartas contenidos transferidos. Con esa evidencia se puede distinguir un defecto de interfaz, señalización, negociación o manejo de archivo y ampliar la matriz sin inventar cobertura.
- Probado: Chromium 150 en Debian, dos perfiles, texto y archivo.
- Revisado visualmente: escritorio 1280×800 y viewport móvil 390×844.
- No confirmado: otros motores y dispositivos físicos en este pase.