커밋 08883cbdd1c39a0c15b97af44ddaefe14acdc21a가 구버전 Gecko 릴리스에서 Discourse 렌더링을 깨뜨렸습니다. Gecko는 74 버전 이전에는 선택 체이닝(optional chaining) 연산자를 지원하지 않습니다.
자세한 내용은 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining#browser_compatibility 를 참조하세요.
우리는 이걸 트랜스파일링하는 건가요? @pmusaraj / @eviltrout / @j.jaffeux ?
이 부분은 틀렸을 수도 있지만, 처음 짐작컨대 브라우저 목록을 정의하지 않아 기본값(아마도 @babel/preset-env · Babel)을 사용하고 있고, 이 버전을 지원 대상으로 간주하지 않아 트랜스파일링이 되지 않는 것 같습니다.
다만 Firefox 74가 불과 1년 전 버전이라 좀 이상하긴 한데, 현재 browserslist를 살펴보면 다음과 같습니다:
$ npx browserslist
...
firefox 89
firefox 88
firefox 78
...
자, 여기서 @sam, 이 버전을 지원할 의사가 있는지요? 불과 1년 전 버전이지만 현재 Firefox 버전은 89이므로, 15개 버전 뒤처져 있습니다. 이 부분은 @sam의 판단에 맡기겠습니다. 참고로 이 버전을 지원하게 되면 트랜스파일링이 기본적으로 폴리필과 유사하게 작동(해당 버전을 지원하기 위해 일부 함수를 추가하고 구문을 함수 호출로 대체)하므로, 모든 사용자의 페이로드 크기가 증가하게 된다는 점을 고려해야 합니다.
(안정 버전에서는 UX: Add auto focus to hamburger and user menu dropdowns (#13165) · discourse/discourse@45dca79 · GitHub 입니다)
호기심에 물어보는데, 기존 코드 스타일이 잘 작동하니까 당장은 그걸 유지하는 게 어떨까요? 
FIX: We can't use `?.` yet (#13168) · discourse/discourse@96fd202 · GitHub
이유는 많지만, 대부분 개발자가 더 쉽게 작업할 수 있도록 하기 위해서입니다. 어떤 것을 사용할 수 있고, 사용할 수 없는지 너무 많이 고민할 필요가 없고, 비교적 최신의 기반을 제공하기 때문입니다.
HTML 폴백이 준비되어 있다면 지원을 중단하는 것에 열려 있습니다.
절대 해서는 안 되는 것은 IE9에는 정상적으로 동작하는 정적 페이지를, 1년 전 버전의 Firefox에는 깨진 페이지를 보여주는 것입니다.
저는 2~3년 전 버전의 Firefox/Chrome까지 트랜스파일하는 것을 선호하지만, @eviltrout 님과 여러분이 결정하셔도 좋습니다. 더 공격적인 설정도 가능하지만, 깨진 페이지를 표시하는 것은 피해야 합니다.
수정: 백링크를 확인해 보시면, 브라우저 업데이트 주기가 매우 나쁜 안드로이드에서 이는 꽤 심각한 문제가 될 수 있습니다.
전적으로 동의하며, 최근 브라우저 호환성에 몇 가지 문제가 발생했기에 우려스럽습니다.
또한 iOS에서는 다음과 같은 문제가 있었습니다: Safari (iOS) shows blank pages on Discourse instances after beta 8 due to manually disable IntersectionObserver
네, 동의합니다. 최소한 browserlist 지원을 구현해서, 지원되지 않는 항목이 우리에게 예상치 못한 문제로 드러나는 일이 없도록 해야 합니다.
이 문제가 Google 인덱싱을 제한할 수 있나요?
이 인덱싱 차단이 다른 원인으로 인한 것인지 확인해 보기 위해서입니다.
감사합니다.
meta에서 OP를 재현할 수 없습니다. Browserstack을 사용하여 macOS의 Firefox 73과 Windows의 Firefox 68로 시도해 보았습니다. @vige, meta에서 문제를 재현할 수 있나요?
맞는 말씀인 것 같습니다. 실제로는 작동해야 할 텐데, 방금 브라우저에서 코드를 확인해 보았습니다:
toggleHamburger: function toggleHamburger() {
this.state.hamburgerVisible = !this.state.hamburgerVisible;
this.toggleBodyScrolling(this.state.hamburgerVisible); // 드롭다운의 첫 번째 링크에 자동 포커스
(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();
});
},
여기가 문제의 원인은 아닐지라도, 정확히 어떤 부분이 트랜스파일되고 어떤 부분이 그렇지 않은지 알아내는 것이 여전히 중요하다고 생각합니다.
제가 틀렸다면 @pmusaraj 님이 바로잡아 주세요. preset-env를 설정하지 않아 targets를 정의하지 않으므로, 포함하는 모든 플러그인이 사용된다고 생각합니다. 그 결과로 proposal-optional-chaining은 확실히 적용되고 있습니다.
이 부분은 괜찮은 것 같습니다. 매년 각 플러그인을 점검해서 여전히 필요한지 다시 고려해 보는 것만 하면 되지 않을까요?
찾았습니다. stable만 깨져 있습니다. proposal-optional-chaining이 그곳에서는 적용되지 않습니다.
tests-passed에서 ?. 변경 사항은 proposal-optional-chaining 변경 사항을 포함합니다: DEV: Enable optional chaining in all contexts (#13180) · discourse/discourse@855e854 · GitHub
그리고 stable에서는 ?.을 사용한 코드 변경만 이루어졌고 트랜스파일러 옵션은 조정되지 않았습니다: https://github.com/discourse/discourse/commit/45dca791b0cdd61a46533db5c86480d97a6cb8de
네, 좋은 지적입니다:
하지만 5일 전에는 플러그인 없이 원래 커밋만 백포트했습니다:
@pmusaraj 플러그인을 stable에도 백포트하는 것이 안전할 것 같습니다. 어떻게 생각하시나요?
네, 동의합니다. 백포트해야 합니다. 오늘 나중에 처리하겠습니다.
이 문제는 이제 안정 버전(v2.7.4)에서 수정되었습니다. 해당 버전에서 proposal-optional-chaining babel 플러그인이 활성화되어 문제가 해결되었습니다.
@RGJ @j.jaffeux (그리고 원본 보고를 해 주신 @vige) 감사합니다!
아, 이제 완전히 이해가네요! 코드는 안정화되었는데 트랜스파일러는 그렇지 않군요. 이렇게 조사해 주셔서 감사합니다.
이 문제를 이렇게 빠르게 수정해 주신 모든 개발자분들께 진심으로 감사드립니다.
참고로, 제 테스트 결과에 따르면 이 버그는 일부 경우 Android용 최신 버전의 Microsoft Edge(Gecko를 사용하지 않는 것으로 알고 있습니다)에도 영향을 미쳤습니다.
해당 릴리스에 실제 v2.7.4 태그를 추가해 주시겠어요?
git checkout v2.7.4를 시도했는데 존재하지 않는다는 것을 확인하는 데 30분이나 걸렸습니다 
죄송합니다. 이제 태그가 지정되었습니다.
