이 문제는 몇 달째 지속되고 있으며, Meta에서 Android/Chrome 기기(둘 다 최신 버전)로 재현할 수 있습니다. 사실 지난 1월경부터 수개월간 이런 현상이 발생해 왔습니다.
메시지 편집기가 제안된 이모지를 선택할 때 간헐적으로 "크래시"가 나는 것처럼 보입니다.
를 탭합니다.편집기가 어떻게든 크래시되거나 다시 그려지는 것처럼 보입니다. 일반적으로 작성한 텍스트의 일부가 사라집니다.
100% 재현되지는 않지만, 약 1분 정도만 조작하면 쉽게 문제가 발생합니다.
사용 중인 Android/Chrome의 정확한 버전은 무엇인가요?
재현할 수 있습니다. 스택 트레이스는 다음과 같습니다:
_application-bfbda341c2eb6dd7d61c681e17bdccec057c30e045ddc332927a7363150e9b1b.js:16386 Uncaught TypeError: Cannot read property '0' of null
at HTMLLIElement.<anonymous> (application-bfbda341c2eb6dd7d61c681e17bdccec057c30e045ddc332927a7363150e9b1b.br.js:1)
at HTMLLIElement.dispatch (ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1)
at HTMLLIElement.d.handle (ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1)
(anonymous) @ application-bfbda341c2eb6dd7d61c681e17bdccec057c30e045ddc332927a7363150e9b1b.br.js:1
dispatch @ ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1
d.handle @ ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1
해당 라인은 이 부분입니다.
selectedOption이 0(단일 제안, 즉 첫 번째 항목)인 반면 autocompleteOptions가 어떤 이유로 null이기 때문에 에러가 발생합니다.
지금 원인을 조사하고 있습니다…
아직까지 확실한 원인은 파악되지 않았습니다. 처음에는 @Osama의 이 PR을 의심했습니다.
하지만 꽤 많은 브레이크포인트를 추가해 보았음에도 불구하고 autocompleteOptions를 변경하여 null로 설정하는 주체를 찾지 못하고 있습니다.
autocompleteOptions가 두 단계 위 부모 클로저의 스코프에서 가져와지는 것도 상당히 이상하며, 이로 인해 코드 파악 및 디버깅이 다소 어렵습니다.
Android 11/Chrome 89, 현재 설치 가능한 최신 버전입니다.
@ljpp / @falco 이 버그를 여전히 재현할 수 있나요? 이모지를 삽입하는 다양한 방법으로 시도해 보았지만, 한 번도 재현되지 않았습니다. 여전히 재현할 수 있다면 정확한 단계를 공유해 주시겠어요? 감사합니다!
네, 제 환경에서는 여전히 Chrome Android에서 크래시가 발생합니다. 재현하려면 지침을 100% 따라야 하는데, 매우 구체적인 상황이기 때문입니다.
방금 시도해 보았지만 쉽게 재현하지는 못했습니다. 다만, 지난 여름에 실제 게시글을 작성하다가 우연히 이 현상을 몇 번 목격한 적이 있어 꽤 확신이 듭니다.
수정: 더 광범위한 테스트 커버리지를 제공할 수 있는지 커뮤니티에 문의해 보겠습니다.
수정 2: 아, 네. 방금 제가 직접 재현했습니다. 커뮤니티에서 테스트를 진행 중이며, 일반 사용자들로부터도 추가 재현 사례가 보고되고 있는 것으로 보입니다.
우연히 재현해 봤는데, 아직 해결되지 않았습니다.
이 문제는 아직 목록에 남아 있습니다. 다만 재현과 디버깅이 정말로 어렵기 때문에 아직 해결하지 못한 상태입니다.
너무 난도가 높아 pr-welcome 태그를 붙이기 어렵습니다. 나중에 다시 검토할 예정이며, 6개월 타이머를 설정해 두었습니다.
이 문제가 여전히 발생하고 있나요?
네, 여전히 지속되고 있습니다. 개인적으로는 15분 동안 강하게 조작해 보았지만 재현하지 못했기 때문에 커뮤니티에 도움을 요청했습니다. 여러 사용자가 재현하는 데 성공했고, 그중 한 명은 스크린샷으로 이를 증명했습니다. 증상은 변하지 않았습니다. 선택기에서 엄지손가락 위로-이모지를 탭하면 키보드가 접히고, 편집기에서 작성된 일부 내용이 사라집니다.
과거에는 이 문제를 매우 쉽게 재현할 수 있었지만, 지금은 재현하는 데 어려움을 겪고 있습니다. 즉, 문제는 존재하지만 100% 재현되는 것은 아닙니다. 계속해서 조작해 보며 이 문제를 유발하는 특정 UI 단계가 있는지 파악해 보겠습니다.
재현이 가능한 사람에게 try.discourse.org에서도 재현해 볼 수 있는지 확인해 달라고 요청해 주시겠어요?
우연히 재현해 보았습니다.
Firefox 94.1.1 (Build #2015842491)
그리고 Chrome 95.0.4638.74
비네이티브 플랫폼의 이모지 선택기가 여기서 진짜 버그인 것 같아요. 
자명한 우회 방법은 원하는 OS의 네이티브 이모지 피커를 사용하는 거예요?
보통은 우회 방법이 있습니다. 항상 그런 것은 아니고, 예를 들어 Discourse에서 사용자 정의 이모지가 사용 중일 수도 있습니다.
어쨌든, 페이지를 새로고침하면 작성한 내용이 사라지는 것은 우리가 수정해야 할 부당한 동작입니다.
네, 오늘 다시 확인해 보았고, 스마트폰의 가상 키보드를 Gboard로 전환한 뒤 재현에 성공했습니다. Gboard는 가끔 키를 한 번 눌렀을 때 keydown와 keyup 이벤트를 두 번 발생시키는데, 오토완성에서 이모지를 선택하기 전에 마지막으로 누른 키에 대해 이런 일이 발생하면 크래시가 납니다.
Gboard가 이러한 이벤트를 두 번 발생시키는 원인은 정확히 알 수 없으나, 사용자가 입력한 내용과 Gboard 설정에 따라 달라지는 것 같습니다.
이 이중 이벤트는 오토완성 라이브러리의 설계 방식 때문에 크래시를 유발합니다. 라이브러리는 keydown와 keyup 이벤트 모두를 수신하며, keydown 시에는 오토완성 제안 목록을 비우고 keyup 시에는 새로운 오토완성 검색어에 기반한 새 제안을 제공합니다.
다만, 이전 제안 이후 검색어가 변경되지 않은 경우 중복 작업을 방지하기 위한 작은 가드/최적화 로직이 존재하며, 문제가 바로 이 부분에서 발생합니다. 첫 번째 keydown와 keyup 이벤트 쌍은 예상대로 기존 제안을 비우고 새 제안을 제공하지만, 두 번째로 오작동한 이벤트 쌍은 keydown 시 제안을 다시 비우지만, 오토완성 검색어가 변경되지 않았기 때문에 keyup 시 새 제안을 제공하지 않습니다.
생각할 수 있는 가장 덜 해킹적인 ‘수정’ 방법은 이 가드/최적화 로직을 제거하여 keyup 시 항상 새 제안을 제공하도록 하는 것입니다. 하지만 이것이 바람직한지, 혹은 그만한 가치가 있는지 확신이 서지 않습니다.
어느 시점에 오토완성 라이브러리를 재작성할 계획임을 알고 있습니다(코드베이스에서 가장 오래된 코드 중 하나이며 재작성이 절실히 필요합니다). 따라서 이 버그는 재작성 작업을 진행할 때까지 기다려도 괜찮을지도 모르겠습니다.
이 충돌은 일종의 "무한 루프"인가요? 피드백 루프에 도달했다는 사실을 단순히 추적하고, 관련 상태를 정리하는 방식으로 해결할 수 있을까요?
아니요, 크래시는 null 변수에 접근할 때 발생합니다. 제안 목록이 지워지면 autocompleteOptions 변수가 null로 설정되고, 이후에 렌더링된 제안 중 하나를 탭하면 autocompleteOptions가 배열이어야 하지만 실제로는 null 상태입니다.
이로 인해 또 다른 아이디어가 떠올랐습니다. 제안이 선택될 때 autocompleteOptions가 null인지 확인하고, 변수가 null이면 해당 검색어에 대해 제안을 다시 가져오는 것은 어떨까요?
네, 좋은 우회 해결책이네요.
이런 세부 사항을 보고하지 못해서 정말 바보 같다는 생각이 듭니다. 제 이전 폰은 깔끔한 Android One이었기 때문에 기본 키보드로 Gboard가 설정되어 있었고, 그 설정이 이후로 다음 기기(Sammy A42 5G)까지 그대로 이어졌습니다. 하지만 대부분의 현재 판매 중인 Android 기기는 기본적으로 제3자 키보드 앱을 사용합니다.
이러한 진전을 볼 수 있어서 정말 좋습니다.
이 버그에 대한 수정 사항을 병합했습니다:
해당 수정 사항은 Meta와 @ljpp 님의 사이트에 배포되었습니다. 사용자분들이 여전히 재현할 수 있는지 알려주세요.