입력란을 찾지 못하는 오류를 고치려면 무엇을 쓰려던 사람의 원고까지 알아야 할까. 북극성에서는 입력 노드의 종류와 편집 가능 여부, 라벨의 존재, 크기와 조상 상태를 먼저 보았다. 원문을 더 모으는 대신 입력이 가능한 구조인지 설명할 자료를 좁히는 선택이었다.
화면 전체 대신 실제 입력 노드에서 시작한다
probeControls는 현재 관찰 뒤 문서 세대를 기억하고 프레임의 native AX tree에서 무시되지 않은 textbox·searchbox·combobox를 찾는다. backend node를 해당 실행 문맥에 연결한 뒤 고정 probeInput 함수를 호출한다. 에이전트가 보내 온 임의 JavaScript를 실행하는 진단 API가 아니다.
프레임의 입력 개수와 실제 상세로 돌려줄 노드 수는 다르다. 상세는 전체 여덟 개까지, 프레임은 열두 개까지라는 한도가 있다. 입력이 많다고 모든 원문과 속성을 가져오지 않는다. 일부 상세만 있다는 사실을 전체 화면의 모든 컨트롤을 조사했다는 말로 바꿔서는 안 된다. 제한된 진단에는 제한된 해석이 따라야 한다.
라벨 문구 대신 속성이 있는지만 본다
probeInput은 ownerDocument가 현재 문서인지 보고 비밀번호 입력과 민감한 autocomplete를 제외한다. 반환값은 tag·role·편집 가능·input type·크기와 라벨·placeholder 속성 존재 여부다. 라벨의 실제 이름이나 placeholder 문장, value와 textContent를 가져오는 함수가 아니다.
조상은 shadow host를 따라 제한된 수만 보고 display·visibility·opacity와 hidden·inert·aria-hidden을 남긴다. 입력을 막는 구조를 설명하기 위한 단서다. 비슷한 속성이 있다는 이유로 숨김 노드를 강제로 누를 권한은 생기지 않는다. 진단은 조작 검증을 보완할 자료이며 실제 입력의 문서·가림 검사를 대신하지 않는다.
읽기 도중 문서가 바뀌면 같은 보고서로 묶지 않는다
각 프레임의 저장 epoch가 시작과 맞는지 보고 조회 뒤에도 페이지 세대를 확인한다. AX 노드를 resolve한 임시 objectId는 finally에서 release를 요청한다. 진단을 여러 번 하면서 원격 객체 참조를 끝없이 남기는 일을 줄이려는 수명 관리다.
프레임 조회에 실패하면 unavailable 표시를 남기며 작업 check가 취소나 문맥 변경을 다시 판단할 수 있다. 실패한 프레임을 입력란이 없는 프레임으로 바꾸지 않는다. 입력 개수 0, 상세가 한도 때문에 없음, 진단 불가라는 상태는 서로 다르다. 구조를 작게 보냈더라도 이 차이가 있어야 다음 조사 위치를 고를 수 있다.
구조 검사의 바깥에는 아직 원문이 있을 수 있다
per-node 함수가 값과 이름을 반환하지 않아도 전체 ControlProbe에는 프레임 origin이 있다. 더 넓은 수리 문맥에는 오류 message나 page URL도 들어갈 수 있다. 그러므로 이 함수를 쓴 로그 전체를 그대로 블로그에 올려도 된다는 결론은 내리지 않았다.
공개 합성 모듈은 아예 다른 계약이다. 원문 필드가 없는 단계·오류·함수 별칭과 제한된 노드 상태만 받고 여분 필드는 거절한다. 실제 DOM을 읽거나 민감 필드를 자동 탐지하지 않으며 공개 안전 인증도 하지 않는다. 수집 단계에서 줄인 정보와 공개 전에 검토할 정보가 어디까지인지 구분해 두었다.
반례는 실제 원문이 결과에 없는지 확인한다
원래 소유 시험 페이지에는 label·value·textarea 본문·편집기 본문·비밀번호·OTP의 표식을 넣는다. 진단 JSON에 그 표식과 값, backend node ID 같은 내부 참조가 없는지 검사한다. 같은 시험은 뒤에 나타난 입력과 실제 문단 끝 입력, 불일치 결과의 구조 요약도 다룬다.
이번에는 그 시험을 읽었고 원래 브라우저에서 새 원고를 입력하지 않았다. 새 모듈의 독립 시험은 원문 필드 거절과 민감 선언 제외를 실제로 실행했다. 진단으로 원인을 확정하거나 수리가 끝났다고 부르는 기능도 없다. 나는 무엇을 덜 보내도 조사에 쓸 수 있었는지와 무엇이 여전히 미확인인지 함께 공유한다.