[Site Isolation] Per-frame walk replaces navigatedFrameID heuristic in back/forward routing
Site Isolation은 cross-origin iframe마다 별도의 WebContent process를 할당하고, UIProcess가 이를 조율합니다. Back/forward 탐색 시 UIProcess는 어떤 frame이 이동해야 하는지 파악하고, 각 owning process에 GoToBackForwardItem IPC를 전송해야 합니다. 기존 코드는 navigatedFrameID를 통해 단일 "primary" frame을 선택했습니다. 이 필드는 호출자가 이동하려는 frame이 아니라, 어떤 child frame의 탐색이 항목을 생성했는지를 인코딩한 값입니다. 그 결과 back 동작과는 일치했지만, forward에서는 어긋나는 문제가 있었습니다.
Source/WebKit/UIProcess/WebPageProxy.cpp
UIProcess는 이제 (current, target) WebBackForwardListFrameItem 트리를 쌍으로 순회하며, itemSequenceNumber가 다른 frame의 process에 독립적인 GoToBackForwardItem을 전송합니다. 재귀는 documentSequenceNumber가 동일한 경우에만 진입하며, cross-document subtree에서는 순회를 멈추고 기존 pull-at-commit 메커니즘에 위임합니다. 이 변경은 useUIProcessForBackForwardItemLoading 플래그 뒤에 위치하며, 플래그가 비활성화된 경우에는 기존 navigatedFrameID 경로가 그대로 유지됩니다.
Significance
이로써 back과 forward 양방향에서 multi-process iframe 순회가 올바르고 대칭적으로 동작하게 됩니다. 이는 security boundary에서 cross-origin frame 탐색의 정확성에 직접적인 영향을 미칩니다.
Audit directions
documentSequenceNumber가 다른 경우 재귀가 멈춥니다. 공격자가 빠른 same-document 탐색과 cross-document 탐색을 교차하는 방식으로 이 값에 영향을 줄 수 있다면, 순회가 과도하게 진행되어 이동해서는 안 되는 frame에 dispatch되거나, 반대로 일부 순회가 누락되어 silent drop될 가능성이 있습니다. silent drop 시 기록되는 새 error-log 경로가 페이지에서 도달 가능한지 확인이 필요합니다.
itemSequenceNumber가 다른 frame마다 별도로 dispatch가 이루어지며, transactional rollback은 존재하지 않습니다. 따라서 조작된 same/cross-origin 혼합 탐색 시퀀스를 사용하면, dispatch 도중 어느 한 process가 crash할 경우 여러 origin에 걸쳐 frame tree가 desync될 가능성이 있습니다.
플래그 게이트로 인해 두 code path가 동시에 유지되므로, 한 flag 모드에서 생성된 history entry가 다른 모드에서 재실행되는 경우를 점검해야 합니다. FrameState 스키마가 두 모드 간에 다를 수 있기 때문입니다. 마지막으로 재귀적 IPC dispatch 순회 중에 children() child map이 변경되지 않는지도 검증해야 합니다.