버튼의 위치를 안다고 실제 누를 수 있는 점을 아는 것은 아니었다. 줄바꿈된 링크의 사각형 가운데는 빈 곳일 수 있고 팝업이 버튼을 가릴 수도 있다. 나는 화면의 실제 그려진 조각과 그 점에서 잡히는 대상을 확인하게 했다.

큰 사각형과 실제 글자 조각은 다르다

여러 줄에 걸친 링크의 bounding rectangle은 각 줄 사이 공간까지 포함한다. 가운데를 누르면 다른 버튼이나 빈 영역일 수 있다. 현재 point 경로는 getClientRects의 실제 조각을 제한된 수로 살피고 화면과 클리핑 범위 안의 후보점을 찾는다.

큰 카드의 중앙에 형제 메뉴가 겹치는 경우도 있다. 그래서 한 중앙점만 고집하지 않고 정해진 내부 후보점을 살피되 매번 실제 hit-test를 통과해야 한다. 임의 좌표를 많이 찍어 그중 하나가 반응하길 기대하는 방식이 아니다. 전달 전 확인된 점만 행동 지점으로 사용한다.

스크롤 뒤에는 그려진 상태도 기다린다

요소를 화면 안으로 스크롤한 직후 DOM 좌표와 compositor의 hit-test가 잠시 다를 수 있다. point는 좌표가 안정된 프레임이나 제한된 대기 조건을 살핀다. 레이아웃이 계속 바뀌면 ELEMENT_OBSCURED 오류로 끝내며 무한히 기다리지 않는다.

대기 뒤에는 연결 상태와 signature, 표시 여부와 disabled를 다시 확인한다. 기다리는 동안 페이지가 바뀌었을 수 있기 때문이다. 나는 레이아웃 대기를 오래된 참조를 계속 믿어도 된다는 근거로 쓰지 않았다. 준비된 좌표도 전달 전까지 현재 노드에 속하는지 확인해야 했다.

클리핑 추정과 브라우저 판정을 함께 쓴다

스크롤 컨테이너의 overflow와 경계는 클릭 가능한 범위를 좁히는 단서다. 하지만 fixed나 absolute 자손은 중간 조상의 예상 범위를 벗어나 실제로 보일 수 있다. 현재 구현은 보수적인 clip 범위 뒤에도 실제 브라우저 hit-test로 노출된 점을 확인한다.

이것을 가린 요소를 무조건 허용하는 예외로 쓰지 않는다. 후보점의 실제 대상이나 그 조상이 원래 요소여야 한다. 진짜로 잘리거나 overlay에 덮인 경우는 통과하지 않는다. 스타일만 보고 불가능하다고 단정하는 오류와 가림을 무시하는 오류 사이에서 실제 그려진 결과를 기준으로 삼았다.

iframe의 부모에도 같은 질문을 이어 간다

안쪽 문서에서 유효한 점을 찾았어도 부모 iframe이 가려지면 실제 클릭은 다른 곳으로 간다. 프레임 경로는 부모 owner를 찾아 좌표를 변환하고 각 상위 hit-test를 확인한다. 변형·회전 때문에 좌표를 신뢰할 수 없으면 추측하지 않고 거절한다.

스크린샷에 보이는 위치를 에이전트가 외워 다음 화면에서 재사용하는 방식과도 다르다. 현재 노드와 프레임에서 구한 점을 현재 실행 조건으로 전달한다. 좌표를 사용한다는 사실만으로 모두 같은 자동화는 아니다. 좌표가 어디서 왔고 무엇을 확인했는지가 중요했다.

성공한 fixed 버튼과 가린 버튼을 함께 본다

fixed-control fixture는 작은 overflow 조상 밖에 실제로 그려진 버튼의 네이티브 클릭이 되는지 본다. 이어 transform과 clip으로 실제 잘린 구조를 만들면 거절되고 결과가 바뀌지 않는지 확인한다. 백그라운드 입력 시험도 overlay 뒤 클릭을 거절하고 처리 횟수가 늘지 않는지 본다.

이 글은 현재 지점 계산과 그 시험 코드를 읽었다. 사용자의 실제 창을 숨기거나 새 클릭을 보낸 검수가 아니다. 창이 백그라운드라는 것과 DOM 요소 자체가 숨김이라는 것도 다르다. 백그라운드 시험은 창 상태와 throttling 보존도 별도로 본다. fixture에서 나눈 노출·가림 사례가 모든 CSS 조합을 지원한다는 뜻도 아니다. 실패를 만났다면 같은 구조의 소유 재현 화면으로 원인을 좁혀야 한다.

에이전트에게도 실패의 지형을 알려 준다

가려졌다는 오류가 나면 버튼이 없다는 뜻과 구별해야 한다. 팝업을 확인하거나 현재 화면을 다시 읽을 수 있지만 무조건 DOM 클릭으로 바꿔 성공시키지는 않는다. 실제 사용자가 누를 수 없는 점을 우회하면 원래 실행 의미가 달라진다.

나는 좌표의 정밀도보다 좌표를 사용할 근거를 만들고 싶었다. 노드와 조각, 화면 상태와 부모 프레임을 확인한 다음 한 번 전달한다. 업무 자동화에서도 무엇을 눌렀는지뿐 아니라 왜 그 점이 맞다고 봤는지 설명할 수 있어야 실제 결과를 검증하고 유지보수할 수 있다.