Cheondi
개발 · Unity

모바일 로그인 입력 포커스

모바일 키보드와 입력 포커스가 엇갈리는 문제를 이벤트 순서부터 다시 살펴본 기록입니다.

  • #unity
  • #mobile
  • #input-field

PC 에디터에서 잘 되던 로그인 입력창이 모바일에서는 말을 듣지 않았다. 아이디를 입력한 뒤 비밀번호 칸을 눌렀는데 키보드가 닫히거나, 입력 커서는 옮겨갔지만 글자가 이전 칸에 들어가는 경우가 있었다. 엔터 키로 다음 칸을 선택하는 기능까지 더해지니 재현 순서도 매번 달라 보였다.

처음에는 Select()를 한 번 더 호출하면 해결될 것 같았다. 호출 횟수를 늘릴수록 잠깐 좋아지는 기기도 있었지만 화면이 열리는 타이밍에 따라 다시 실패했다. 포커스를 값 하나가 아니라 이벤트의 순서로 봐야 했다.

선택 상태와 입력 활성화의 구분

Unity UI에서 오브젝트가 선택된 것과 모바일 키보드 입력을 받는 상태는 미묘하게 달랐다. 화면이 활성화되는 프레임에 바로 포커스를 주면 다른 UI 이벤트가 뒤에서 선택을 빼앗기도 했다.

private IEnumerator FocusNextFrame(TMP_InputField field)
{
    yield return null;
    field.Select();
    field.ActivateInputField();
}

무조건 한 프레임 기다리는 게 모든 상황의 답은 아니지만, 레이아웃과 화면 전환이 끝난 뒤 실행돼야 하는 이유를 확인할 수 있었다.

이벤트 중복 연결 검증

프리팹을 복사하거나 화면을 다시 열 때 리스너를 계속 추가하면 한 번의 완료 이벤트에서 다음 칸 선택과 로그인 요청이 함께 실행될 수 있었다. 초기화할 때 기존 리스너를 제거하고 화면이 닫힐 때 정리했다.

idField.onSubmit.RemoveListener(OnIdSubmit);
idField.onSubmit.AddListener(OnIdSubmit);

void OnIdSubmit(string _)
{
    StartCoroutine(FocusNextFrame(passwordField));
}

로그에는 현재 선택된 오브젝트와 입력 필드의 활성 상태를 같이 남겨 순서를 확인했다.

실제 키보드 기반 검증

마우스로 클릭하는 것만으로는 모바일 문제를 재현하기 어려웠다. 화면 첫 진입, 아이디 입력 후 다음 버튼, 비밀번호 표시 토글, 뒤로 가기로 키보드 닫기, 앱을 잠깐 백그라운드로 보낸 뒤 복귀하는 순서를 나눠 확인했다.

기기 키보드마다 완료 버튼의 이름과 동작이 조금 달랐다. 에디터 성공을 모바일 입력 완료로 볼 수 없다는 걸 다시 느꼈다.

입력창의 복합 상태

로그인 폼은 필드 두 개와 버튼 하나라 단순해 보였다. 하지만 선택된 UI, 활성 입력 필드, 가상 키보드, 화면 전환 상태가 함께 움직였다. 이 중 하나만 보고 수정하면 다른 기기에서 다시 어긋났다.

이 작업 뒤로 모바일 UI 문제를 볼 때 “클릭이 됐나?”만 확인하지 않는다. 어떤 이벤트가 어떤 순서로 포커스를 바꿨는지, 화면이 그때 입력 가능한 상태였는지를 살핀다. 눈에 보이는 커서 하나 뒤에도 여러 상태가 있다는 걸 배운 꽤 오래 걸린 수정이었다.

추가 구현 기준

이 문제를 고친 뒤 관련 공식 자료를 찾아 읽으면서, 당시 코드에서 우연히 맞았던 부분과 규칙으로 남겨야 할 부분을 나눠 봤다.

HTML 문서의 focus, form, history 동작은 브라우저가 관리하는 상태다. 앱 코드가 보이는 컴포넌트만 바꿔도 현재 focus와 history entry가 자동으로 의도대로 정리된다고 볼 수 없다. 모바일 키보드나 Safari 외부 이동에서 차이가 커지는 이유도 이 경계에 있다.

사용자 조작을 재현할 때는 클릭 결과만 보지 않고 focus가 어디에 남았는지, history가 한 번 추가됐는지, 복귀 시 문서가 새로 만들어졌는지까지 확인하는 편이 낫다.

다음에 모바일 로그인 입력 포커스 같은 문제를 보면 아래 순서부터 확인하려고 한다.

  • focus 획득·해제 이벤트 순서
  • 키보드 표시 전후 viewport 높이
  • selection·cursor 위치 보존
  • 자동 완성과 수동 입력의 구분

브라우저·WebView·설치형 PWA를 같은 환경으로 묶지 말고 지원 범위별 fallback을 둬야 한다.

공식 참고 자료

  • W3C HTML 5.2 — 폼·포커스·autocomplete·탐색 동작
  • W3C WCAG 2.1 — 확대·reflow·orientation·입력 접근성