Figma no abre en Firefox y el aviso de WebGL no explica por qué

Abro Firefox, abro un Figma y me encuentro con esto:

Uh oh… we can't open that file

We can't open this file because WebGL isn't supported, or is disabled, in your browser. If your browser supports WebGL, check out this help article to find out how to enable it.

Manda narices.

Llevo años abriendo Figmas en Firefox —en el Developer Edition, además, que es mi navegador de trabajo—, y hoy, sin haber tocado nada, se pone tonto.

Lo primero que hice fue lo que haría cualquiera: pinchar en ese «this help article» que el propio aviso ofrece. Lo segundo fue cerrarlo.

El artículo de Figma confirma que Firefox está entre los navegadores admitidos y que WebGL tiene que estar «instalado y habilitado». Y a continuación, en el apartado de Firefox, explica cómo ajustar el zoom y cómo comprobar si hay actualizaciones. Cómo habilitar WebGL, que es literalmente lo que te ha mandado a buscar, no lo dice.

Así que me lo miré en serio. Y da para artículo, porque el asunto tiene dos capas: el aviso esconde cuatro problemas distintos debajo de una sola frase, y las guías que salen primero cuando lo buscas llevan años arreglando uno que ya no existe.

El aviso miente un poco

«WebGL isn't supported, or is disabled» suena a una sola cosa con un matiz. Son cuatro situaciones que no se parecen en nada:

1. WebGL está apagado por preferencia. Hay un interruptor explícito, webgl.disabled, y si está puesto no hay más que hablar. Lo activan los perfiles endurecidos por privacidad —WebGL es una fuente de huella digital de primera— y lo arrastra cualquiera que se bajara un user.js de internet en su día y no se acuerde.
2. Firefox lo ha bloqueado por tu tarjeta o tu driver. Mozilla mantiene una lista de combinaciones de GPU y versión de driver que considera inestables. No hace falta tener un cacharro antiguo: basta con estar una versión por debajo del corte.
3. La aceleración por hardware no está disponible. Puede ser una casilla desmarcada. Puede ser el entorno: una sesión de escritorio remoto, una máquina virtual, un portátil híbrido que ha decidido que a Firefox le toca la integrada.
4. El perfil o alguna extensión interfiere. Una configuración endurecida, una política administrada o una extensión de privacidad pueden alterar o bloquear el acceso a WebGL. Es la menos frecuente de las cuatro, y también la más difícil de ver desde dentro del perfil en el que estás.

Figma no puede saber con certeza cuál de esas causas hay debajo. Solicita el contexto gráfico, el navegador no se lo entrega y muestra un mensaje común. De ahí el aviso comodín.

Detrás del aviso hay cuatro capas distintas: la preferencia apagada, la tarjeta y su driver, la aceleración por hardware y el perfil que interfiere. El mensaje es el mismo en los cuatro casos. Ilustración generada con IA para este artículo.

Es el mismo género de aviso que el clásico «no es DNS, no puede ser DNS, era DNS»: un síntoma único, un montón de causas, y un diagnóstico que va por descarte o no va.

Antes de tocar nada: about:support

Esto es lo que casi ninguna guía pone primero, y es lo único que de verdad importa.

Escribe about:support en la barra de direcciones y baja hasta la sección Gráficos. Tienes la respuesta antes de haber cambiado un solo ajuste:

• WebGL 2 Driver Renderer: si aparece el nombre del renderizador, Firefox ha conseguido inicializar WebGL, y eso descarta un fallo gráfico general —aunque todavía pueda quedar un bloqueo del perfil o de alguna extensión—. Si sale vacío, o pone que está bloqueado, ya sabes por dónde van los tiros.
• El registro de decisiones y el de fallos: es donde Firefox te dice por qué. Los códigos empiezan por FEATURE_FAILURE_ y son elocuentes: FEATURE_FAILURE_OLD_NVIDIA es un driver por debajo del corte; FEATURE_FAILURE_GLXTEST_FAILED, que ni siquiera pudo probar el contexto gráfico.
• Si aparece la palabra «blocked» junto a alguna característica, tienes un bloqueo de lista, no una preferencia apagada. Problemas distintos, soluciones distintas.

Ojo con lo que eso significa exactamente: about:support te dice qué ha conseguido inicializar Firefox, no que Figma vaya a poder usarlo en esa sesión concreta. Pero con eso ya sabes por dónde empezar, que es justo lo que faltaba. Ahora sí se puede tocar algo.

La receta caducada

Si buscas esto en español, te vas a encontrar la misma receta clonada en cincuenta sitios: entra en about:config, pon webgl.force-enabled a true, pon layers.acceleration.force-enabled a true, reinicia.

La primera mitad sigue sirviendo. La segunda no.

layers.acceleration.force-enabled era el interruptor del compositor antiguo de Firefox. Ese compositor ya no está: hace años que el navegador pinta con WebRender, y la preferencia se quedó sin nada que encender. Puedes ponerla a true, reiniciar y tener la sensación de haber hecho algo. No has hecho nada.

Y ahí está lo que me interesa de verdad, más allá del Figma: el soporte técnico escrito no caduca solo. El artículo que explicaba esto correctamente en su momento sigue publicado, sigue posicionando, sigue saliendo el primero, y la mitad de sus instrucciones apuntan a un navegador que ya no existe.

Nadie lo escribió con mala intención. Simplemente lo escribió y se fue, que es lo que le pasa a cualquier cosa que se publica y no se mantiene.

Lo que sí se toca, y en qué orden

Primero, lo que no obliga a entrar en about:config: Ajustes → General → Rendimiento. Desmarca «Usar la configuración de rendimiento recomendada» y comprueba que «Usar aceleración por hardware cuando esté disponible» está marcada.

Aquí se acaban unos cuantos casos, porque esa casilla se desmarca sola cuando alguien tuvo un problema de vídeo hace dos años y buscó una solución rápida.

Si eso no basta, about:config, aceptar el aviso, y dos preferencias. Dos:

Un aviso sobre la segunda: webgl.disabled en false es lo normal; webgl.force-enabled en true no.

Esa no habilita nada que faltara: anula un bloqueo que alguien puso por un motivo. Si tu driver está en esa lista porque cuelga el navegador, forzarlo no lo arregla: consigues que Figma abra y que Firefox se caiga a los diez minutos. Actualiza el driver antes. Si después del driver el bloqueo sigue, entonces sí.

Y hay algo que no está en esa tabla, aunque salga en casi todas las recetas: el grupo gfx.webrender.*. WebRender es el compositor de Firefox, el que pinta la página. WebGL es la API gráfica que una web pide para dibujar en un lienzo. Están en la misma pila y se rozan, pero no son la misma pieza: puedes tener WebRender funcionando perfectamente y que no te entreguen el contexto WebGL que pide Figma. Forzar el compositor por software con gfx.webrender.software, en particular, no convierte el motor gráfico de Figma en un renderizador por software: es otra capa. Esas preferencias existen y tienen sus motivos para tocarse, pero no son la forma de habilitar WebGL —y colarlas aquí es exactamente cómo un diagnóstico se degrada en una lista de interruptores que se prueban a ver.

La trampa del Modo de resolución de problemas

Este es el detalle más útil de todo el artículo, porque es donde se pierde media tarde.

El reflejo natural, cuando sospechas de una extensión, es arrancar Firefox en Modo de resolución de problemas —lo que toda la vida fue el modo seguro— y ver si el fallo persiste.

Con este fallo concreto no sirve. Ese modo desactiva las extensiones, sí, pero también desactiva la aceleración por hardware. En modo de resolución de problemas, Figma va a fallar igual aunque tus extensiones no tengan nada que ver. Y de ahí sales convencido de que el problema es más gordo de lo que es.

Para descartar extensiones y preferencias de golpe hay que hacer otra cosa: about:profiles, crear un perfil nuevo, abrir Figma ahí. Perfil limpio, aceleración normal, cero extensiones. Si en el perfil nuevo funciona, el problema está en tu perfil de siempre y es cuestión de ir quitando cosas. Si tampoco funciona, el problema está por debajo de Firefox.

Y siendo honesto: si te dedicas a esto, hay bastantes papeletas de que esté en tu perfil. El mío es un Developer Edition con años encima y con preferencias que toqué por motivos que ya no recuerdo. Quien se preocupa por la privacidad de su navegador —y hace bien— es justo quien más números tiene de haber apagado WebGL sin acordarse, porque es una de las señales más golosas que existen para identificar un equipo.

Es una decisión legítima. Lo que no lo es tanto es dar por hecho que las cosas siguen como las dejaste.

Cuando la culpa no es de Firefox

Si el perfil limpio tampoco abre Figma, la lista se acorta:

• Firefox tiene una actualización a medio aplicar. Se instaló de fondo y el proceso que está corriendo se ha quedado descolgado. Suena a excusa, pero es una causa real de este fallo exacto y explica muy bien el «ayer funcionaba». Cerrar el navegador del todo —no la ventana: el proceso— y volver a abrirlo.
• El driver de la gráfica. Actualizado por Windows Update esta semana, o sin actualizar desde hace tres años. Los dos extremos dan problemas, y el segundo te mete en la lista de bloqueo.
• No hay GPU que valga. Escritorio remoto, máquina virtual, servidor sin tarjeta. Aquí no hay preferencia que te salve: o el entorno expone algo que sirva como aceleración, o cambias de sitio.
• Portátil con gráfica híbrida. El sistema le ha asignado a Firefox la integrada, o ninguna. Se arregla en el panel de la tarjeta, forzando el ejecutable de Firefox a la dedicada.

Por qué Figma no tiene «modo sin gráficos»

Merece la pena entender por qué esto es todo o nada, porque explica que no exista una versión degradada del editor.

Figma no construye el documento como una página convencional. No hay miles de elementos HTML colocados con CSS que se puedan pintar más despacio si hace falta. Hay un lienzo y un motor de render propio montado sobre las APIs gráficas que expone el navegador: usa WebGL o WebGPU para delegar buena parte del render en la GPU, que es la única forma de que un archivo con miles de capas se mueva con fluidez mientras haces zoom.

Es la misma idea que lleva décadas rigiendo el render en tiempo real: el trabajo no lo hace el procesador general, lo hace el hardware especializado, y si no está disponible no hay plan B.

Y hay una vuelta de tuerca. Desde 2023, Figma migró su renderizador a WebGPU, el sucesor de WebGL, precisamente para librarse del estado global de WebGL y de su forma de reportar errores. Firefox activó WebGPU por defecto en Windows en la versión 141, en julio de 2025, y en la 147, este enero, lo extendió a todos los Mac con Apple Silicon.

Y que el aviso siga hablando únicamente de «WebGL» demuestra otra cosa: los mensajes de error también envejecen. Por debajo, la pila gráfica de Figma y la de los navegadores ya han cambiado; el texto que recibe el usuario, no al mismo ritmo. Lo cual, a estas alturas del artículo, ya sabes cómo acaba: el aviso seguirá diciendo poco, y las guías para arreglarlo envejecerán exactamente igual de mal.

En resumen

El aviso de Figma es genérico porque no puede ser otra cosa. Las cuatro causas se resuelven de maneras distintas, y el orden correcto es siempre el mismo:

1. Mirar about:support antes de tocar nada.
2. Probar la casilla de aceleración por hardware.
3. Solo entonces, about:config —y sabiendo qué estás forzando y por qué—.
4. Si sigue, perfil nuevo desde about:profiles. El modo de resolución de problemas, para este fallo, no vale.

Lo mío se arregló, y el navegador sigue siendo Firefox. Que quede claro.

(No voy a decir cuál de las cuatro era, entre otras cosas porque no me paré a confirmarlo. Arreglé, abrí el Figma y seguí trabajando, que es exactamente lo que hacemos todos y por lo que luego pasa lo que pasa.)

Las preferencias y comportamientos descritos están comprobados contra la documentación de Mozilla sobre aceleración por hardware y WebGL y las notas de la versión 147 de Firefox. El detalle del renderizador de Figma sale de su artículo sobre la migración a WebGPU, y el artículo de ayuda al que enlaza el aviso es «How do I configure my browser for Figma», que sobre esto no dice nada.