El commit 08883cbdd1c39a0c15b97af44ddaefe14acdc21a rompió la renderización de Discourse en versiones antiguas de Gecko. Gecko no admite el operador de encadenamiento opcional antes de la versión 74.
Para más información, consulte https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining#browser_compatibility .
¿Oh, se supone que debemos transpilar esto, @pmusaraj / @eviltrout / @j.jaffeux?
Puede que me equivoque, pero mi primera impresión es que no definimos la lista de navegadores y se está usando una predeterminada (probablemente @babel/preset-env · Babel), por lo que no considera esta versión como algo que soportamos y, en consecuencia, no se transpila.
Es extraño, sin embargo, que Firefox 74 tenga solo un año de antigüedad, pero sí, al observar actualmente browserlist:
$ npx browserslist
...
firefox 89
firefox 88
firefox 78
...
Ahora, la pregunta es, @sam, ¿queremos soportarlo? Aunque tenga solo un año de antigüedad, la versión actual de Firefox es la 89, por lo que esta versión está 15 versiones atrás. No estoy seguro de esto, es tu decisión. Es importante considerar que para soportarlo se añadirá peso a la carga útil de todos, ya que la transpilación funciona más o menos como un polyfill (agregando algunas funciones para dar soporte a esto y reemplazando la sintaxis por llamadas a funciones).
(En la versión estable esto es UX: Add auto focus to hamburger and user menu dropdowns (#13165) · discourse/discourse@45dca79 · GitHub)
Por curiosidad, el estilo de código antiguo funciona bien, ¿por qué no mantenerlo por ahora? 
FIX: We can't use `?.` yet (#13168) · discourse/discourse@96fd202 · GitHub
Hay muchas razones, pero principalmente hace que todo sea más fácil para el desarrollador: no tenemos que pensar demasiado en todo lo que podemos o no usar, y partimos de una base bastante moderna.
Estoy dispuesto a eliminar el soporte siempre que tengamos nuestra solución de respaldo en HTML.
Lo que definitivamente no podemos hacer es mostrar una página estática funcional en IE9 y una página rota en Firefox de hace un año.
Prefiero simplemente transpilar hasta Firefox/Chrome de hace 2-3 años, pero estoy encantado de dejar esa decisión en manos de @eviltrout y de ti. Supongo que podemos ser más agresivos, pero no podemos mostrar páginas rotas.
Edición: véase el enlace de retroceso; esto puede ser un problema bastante grave en Android, que tiende a tener una cadencia terrible para actualizar los navegadores.
No podría estar más de acuerdo, y me preocupa que la compatibilidad con los navegadores haya sufrido algunos golpes recientemente.
Además, en iOS hubo esto: Safari (iOS) shows blank pages on Discourse instances after beta 8 due to manually disable IntersectionObserver
sí, estoy de acuerdo; como mínimo deberíamos implementar el soporte de browserlist para que las cosas no compatibles no nos tomen por sorpresa.
¿Puede este problema limitar la indexación de Google?
Solo quiero averiguar si debo buscar en otro lugar la causa de este bloqueo de indexación.
Gracias.
No puedo reproducir el OP en meta. Lo intenté mediante Browserstack usando Firefox 73 en macOS y Firefox 68 en Windows. @vige, ¿puedes reproducir el problema en meta?
Creo que tienes razón, debería funcionar realmente. Acabo de revisar el código en el navegador:
toggleHamburger: function toggleHamburger() {
this.state.hamburgerVisible = !this.state.hamburgerVisible;
this.toggleBodyScrolling(this.state.hamburgerVisible); // enfoque automático en el primer enlace del menú desplegable
(0, _runloop.schedule)("afterRender", function () {
var _document$querySelect2;
(_document$querySelect2 = document.querySelector(".hamburger-panel .menu-links a")) === null || _document$querySelect2 === void 0 ? void 0 : _document$querySelect2.focus();
});
},
Ten en cuenta que aún deberíamos intentar saber exactamente qué se transpila y qué no, aunque eso quizás no sea el problema aquí.
Corrígeme si me equivoco, @pmusaraj, pero creo que, como no configuramos preset-env y, por lo tanto, no definimos objetivos, se utilizan todos los plugins que incluimos. En consecuencia, proposal-optional-chaining se aplica sin duda.
Estoy de acuerdo con esto; quizás solo necesitemos revisar cada plugin anualmente y reconsiderar si sigue siendo necesario.
Lo encontré. Solo stable está roto. proposal-optional-chaining no se está aplicando allí.
En tests-passed, el cambio de ?. incluye el cambio de proposal-optional-chaining: DEV: Enable optional chaining in all contexts (#13180) · discourse/discourse@855e854 · GitHub
y en stable solo se realizó el cambio de código con ?., pero no se ajustaron las opciones del transpilador: UX: Add auto focus to hamburger and user menu dropdowns (#13165) · discourse/discourse@45dca79 · GitHub
Sí, buena captura:
Sin embargo, hace 5 días hicimos un backport solo del commit original, sin el plugin:
@pmusaraj Creo que hacer el backport del plugin en la versión estable también sería seguro, ¿no crees?
Sí, estoy de acuerdo, deberíamos hacer un backport. Lo trabajaré más tarde hoy.
Esto ya está solucionado en la versión estable (v2.7.4); el plugin proposal-optional-chaining de Babel está ahora habilitado allí y corrige el problema.
¡Gracias a @RGJ, @j.jaffeux (y a @vige por el informe original)!
¡Ah, eso tiene mucho sentido! El código está en la versión estable, pero el transpilador no. Gracias por hacer el trabajo de detective.
¡Muchísimas gracias a todos los desarrolladores involucrados por solucionarlo tan rápido!
Para que conste, según mis pruebas, este error también afectaba, en algunos casos, a la última versión de Microsoft Edge para Android (que, que yo sepa, no ejecuta Gecko).
¿Podrías tener la amabilidad de agregar la etiqueta v2.7.4 real a esa versión?
Acabo de pasar media hora intentando hacer git checkout v2.7.4, lo que resultó no existir 
Lo sentimos. Ahora está etiquetado.
