Resumen

  • El primer borrador público de Web Locks, publicado por el W3C el 5 de enero de 2023, describió cerraduras con nombre que permiten coordinar ventanas y workers de una aplicación en el mismo ámbito de almacenamiento. El borrador del 24 de septiembre de 2025 mantuvo la secuencia de solicitar, trabajar y liberar al terminar la tarea.
  • El modo exclusivo reserva un nombre para un solo titular; el compartido admite varios titulares compatibles. steal adelanta de forma excepcional a una solicitud, pero el código del titular anterior puede seguir ejecutándose.

La carrera empieza sin ruido. Una pestaña prepara un cambio en un documento; otra decide sincronizarlo. Ambas muestran botones normales, ambas responden al usuario y ambas pueden operar sobre el mismo estado. Cuando descubren que el trabajo se duplicó, ya es tarde para fingir que solo había una ventanilla abierta. Las aplicaciones del navegador necesitaban un modo de coordinar a sus propios contextos antes de enviar sus decisiones al resto del mundo.

El primer borrador público del W3C, de 5 de enero de 2023, propuso un cierre asíncrono sobre un recurso con nombre. Mientras un script lo mantiene, otros scripts comprendidos en su ámbito no reciben un cierre incompatible sobre ese mismo nombre. Las ventanas, las pestañas y los workers que comparten un espacio de almacenamiento pueden cooperar por medio de un administrador de cierres. El nombre lo inventa la aplicación para una tarea abstracta: guardar-documento es una convención entre sus partes, no una orden al sistema de archivos.

La historia de publicaciones del W3C sitúa el primer texto en 2023 y el siguiente borrador en septiembre de 2025. En el borrador del 24 de septiembre de 2025, la receta ocupa tres pasos: pedir el cierre, ejecutar la tarea asíncrona mientras se tiene, liberarlo cuando acaba. Un ejemplo muestra el mismo documento abierto en dos pestañas; sus cambios locales y la sincronización deben turnarse. Otro plantea una pestaña principal que realiza tareas de mantenimiento y cuyo puesto queda disponible cuando desaparece.

El modo define quién puede entrar. Un cierre exclusivo deja fuera a los demás solicitantes de ese nombre. Varios cierres compartidos pueden coexistir, como lectores que consultan a la vez, mientras un escritor exclusivo espera su turno. El navegador administra la fila; la aplicación decide qué nombres representan realmente un mismo recurso. Si dos pestañas llaman caja-1 y caja-2 a la misma caja, han construido dos puertas y perdido el beneficio de la coordinación.

El texto explicativo del grupo W3C detalla el trabajo dentro de una función. La promesa de la solicitud sigue el resultado de esa función y el cierre se libera al salir. Hay una consulta diagnóstica sobre titulares y peticiones pendientes, pero es una foto de un instante, inútil como garantía sobre el siguiente. El mismo documento enseña una trampa más antigua que la web: un proceso guarda A y espera B; otro guarda B y espera A. La fila está perfectamente ordenada. Nadie avanza.

La salida de emergencia también tiene dientes. El borrador de 2025 permite steal: quitar cierres ya concedidos bajo un nombre y colocar la nueva solicitud delante de la fila. El explicador advierte que el script desplazado puede seguir trabajando, convencido de que aún tiene exclusividad. Romper el candado en la puerta no borra lo que el empleado está haciendo dentro. Una aplicación que invoque esta opción tiene que preparar su propia recuperación ante esa superposición.

El ámbito importa tanto como la llave. La coordinación se aplica a agentes que comparten un espacio de almacenamiento dentro de un mismo navegador; otros perfiles, sesiones privadas y dispositivos tienen administradores separados. Los documentos originales establecen la mecánica y su cronología, no una tasa de adopción ni la prueba de que una actualización llegó intacta al servidor. Web Locks ordena la entrada al trabajo. La aplicación responde por el trabajo terminado.