Windows 11 ha heredado la nueva interfaz WinUI, pero en el camino ha dejado atrás una función que lleva funcionando desde el año 2000: el atajo Shift+clic en la barra de desplazamiento, que permite saltar directamente a cualquier punto de un documento largo. El fallo afecta a aplicaciones nativas tan básicas como el Bloc de notas y contrasta con el soporte que mantienen frameworks antiguos como Win32 y WPF, e incluso las aplicaciones construidas con Electron.
Quien ha puesto el foco sobre esta carencia es Raymond Chen, ingeniero de Microsoft con más de tres décadas en la compañía y considerado el historiador no oficial de Windows. Según relató en su blog The Old New Thing, descubrió hace poco que Electron sí soporta el atajo, mientras que WinUI, el framework sobre el que se construyen las aplicaciones modernas de Windows 11, no lo hace. La anécdota resulta llamativa porque ni siquiera alguien con su experiencia conocía el truco hasta ahora, y porque pone en evidencia una fragmentación que lleva tiempo creciendo bajo la superficie del sistema.
Origen del atajo Shift + clic en la barra de desplazamiento
Durante las dos primeras décadas de Windows, la barra de desplazamiento ofrecía cinco zonas de interacción: las flechas de los extremos, que mueven el contenido línea a línea; los canales superior e inferior, que avanzan página a página; y el tirador central, que arrastramos para ir a cualquier parte. Windows 2000 añadió un menú contextual con siete opciones al hacer clic derecho sobre la barra.
Seis de esas opciones replicaban gestos ya existentes con el ratón o el teclado. La séptima, llamada Scroll Here, era nueva: hacer clic derecho sobre el punto deseado y saltar allí sin arrastrar el tirador. Junto a esta función llegó un atajo todavía más discreto. Mantener pulsada la tecla Shift mientras hacemos clic en cualquier parte del canal mueve el tirador directamente a ese punto, algo que Chen describe como un salvavidas en documentos largos donde el tirador apenas ocupa unos píxeles. Un clic normal en el hueco solo avanza una página; Shift+clic nos lleva exactamente donde queremos.
Qué conserva el atajo y cuáles lo han perdido
No todos los marcos de desarrollo han mantenido estas funciones heredadas al dar el salto a interfaces más modernas. Esto es lo que descubrió Chen al comprobar cada framework. Por ejemplo, las aplicaciones basadas en Chromium, como las construidas con Electron, conservan al menos el atajo de teclado aunque hayan prescindido del menú contextual. WPF, por su parte, mantiene ambas funciones a través de su ScrollHereCommand. WinUI es el único framework que no ofrece ninguna de las dos, pese a ser la apuesta de Microsoft para el futuro de las aplicaciones nativas de Windows.
Esta comparación nos permite entender por qué el mismo gesto responde en una ventana y no en otra: no es un problema puntual de una aplicación concreta, sino una diferencia estructural entre los framework. Si alternamos a diario entre el Bloc de notas, un navegador y alguna herramienta construida sobre Electron, notaremos que el comportamiento de la barra de desplazamiento cambia según qué tecnología hay detrás de cada ventana.
Por qué WinUI no hereda estos gestos del sistema clásico
La explicación técnica tiene que ver con la arquitectura de los controles. WinUI no reutiliza la barra de desplazamiento clásica de Win32: construye los suyos propios, llamados ScrollBar, ScrollViewer y ScrollView. Al tratarse de controles diseñados desde cero, los atajos y menús que llevaban décadas integrados en el sistema operativo no se trasladan de forma automática.
Para que estas funciones existan en una aplicación WinUI, alguien del equipo de Microsoft tiene que programarlas explícitamente. De momento no lo ha hecho, y el resultado es que las aplicaciones nativas de Windows 11 se sienten, en este aspecto concreto, menos capaces que sus equivalentes en Electron o que las ventanas clásicas de hace veinticinco años.
Para quienes seguimos de cerca la evolución de Windows, este tipo de carencias resulta familiar: cada vez que Microsoft reconstruye un control desde cero, corre el riesgo de dejar atrás pequeños gestos que los usuarios llevamos años dando por hechos. No se trata de un fallo grave que impida trabajar, pero sí de uno de esos detalles que notamos en el día a día si manejamos documentos extensos.
El Bloc de notas, protagonista del error
La comunidad ya había detectado el problema antes de que Chen le pusiera nombre. El pasado mes de junio se abrió en GitHub un issue titulado «Shift-clicking in scroll bar should jump to destination», usando como ejemplo el Bloc de notas de Windows 11, una de las aplicaciones que Microsoft ha migrado a WinUI.
Quien reportó el fallo lo describió como una inconsistencia frente al resto del sistema, ya que Win32, WPF y Chromium sí respetan el gesto. El issue está etiquetado como bug y sigue en el backlog de WinUI sin nadie asignado para resolverlo, lo que sugiere que, aunque Microsoft conoce el problema, no figura entre las prioridades inmediatas.
Este tipo de reportes es habitual entre quienes usan el Bloc de notas para repasar archivos de texto largos o registros de configuración, donde el tirador de la barra apenas ocupa unos píxeles. Mientras el issue siga sin resolverse, cualquiera que abra un documento extenso en esta aplicación notará que el salto directo simplemente no responde, por mucho que mantenga pulsada la tecla Shift.
Cómo movernos por documentos largos ahora
Hasta que WinUI incorpore el atajo, tenemos alternativas que nos ayudan a no depender solo de la rueda del ratón o de arrastrar un tirador diminuto con el dedo o el puntero.
- Las teclas Inicio y Fin suelen llevar directamente al principio o al final del documento en la mayoría de aplicaciones de Windows.
- Re Pág y Av Pág avanzan o retroceden una página completa de contenido, el mismo gesto que ofrecen los canales de la barra clásica.
- Arrastrar el tirador con cuidado sigue siendo el método visual más directo, aunque menos preciso que Shift+clic.
- En las aplicaciones construidas con Electron, el atajo Shift+clic sigue funcionando porque heredan la barra de desplazamiento de Chromium.
Ninguna de estas opciones sustituye por completo la precisión del salto directo que ofrecía Scroll Here, pero mientras el issue siga abierto en el backlog de WinUI, son las que tenemos a mano si trabajamos a diario con documentos largos en aplicaciones nativas de Windows 11.
Microsoft prioriza el rendimiento en WinUI para Windows
Este hueco llega en un momento en que WinUI está recibiendo atención, aunque centrada en otros frentes. En la Build 2026, Chris Anderson, del equipo de interfaz de Windows, afirmó que la prioridad pasa por el rendimiento, los fundamentos y la corrección de errores. El framework ha sumado recientemente controles como TableView y Chart, además de ajustes para reducir el consumo de memoria que arrastraba.
Al mismo tiempo, WinUI avanza hacia diálogos del sistema cada vez más visibles: el cuadro Ejecutar, las Propiedades de archivos, la gestión de impresión o el diálogo de Autoplay ya usan esta base. Cuanto más terreno gana WinUI dentro de Windows 11, más se notan huecos como este. Chen lo resumió con ironía en su propio blog: para cuando por fin aprendió un atajo de la barra de desplazamiento, el ecosistema se ha fragmentado tanto que ya no puede dar por hecho que funcione en todas partes.