Chrono Mock네이티브 앱 안의 웹 페이지
웹 엔진이 내장된 데스크톱 애플리케이션은 페이지를 별도의 샌드박스된 프로세스에서 실행합니다. 네이티브 메커니즘은 애플리케이션까지만 적용되고 그 경계에서 멈춥니다. 그래서 창은 요청한 날짜로 이동하지만 그 안의 패널은 그렇지 않습니다. 이 기능은 그 틈을 메웁니다.
성공처럼 보이는 실패
많은 Windows 애플리케이션은 바깥은 네이티브이고 안쪽은 웹 페이지입니다. 설정 화면, 대시보드, 보고서 보기, 라이선스 패널 등을 두 번 작성하는 대신 HTML로 한 번 만들어 WebView2나 Qt WebEngine에 호스팅합니다.
엔진은 이 페이지들을 자신의 프로세스에서 실행하고, 그 프로세스는 샌드박스되어 있습니다. 애플리케이션에 인젝션한 라이브러리는 그 안으로 들어가지 못합니다. 애플리케이션이 Windows에 요청하는 모든 것은 세션의 날짜로 옮겨 가지만, 페이지가 JavaScript에 요청하는 것은 그렇지 않습니다.
- 제목 표시줄, 로그, 파일은 2038이라고 말합니다.
- 같은 창 안의 패널은 오늘이라고 말합니다.
- 오류도 경고도 없고, 두 쪽 모두 똑같이 자신만만해 보입니다.
테스트가 실행된 것처럼 보이기 때문에 이것이 이 버그의 값비싼 형태입니다. 이전 동작은 그런 세션을 깔끔한 통과로 보고했는데, 도구가 뒷받침할 수 없는 주장이었습니다.
세션이 대신 하는 일
세션은 두 메커니즘을 동시에 실행합니다. 네이티브 훅은 평소처럼 애플리케이션에 들어가고, 페이지에는 샌드박스된 렌더러에 닿는 유일한 방법, 즉 엔진 자체에 요청하는 방법으로 접근합니다.
시작할 때 애플리케이션은 엔진에게 로컬 디버깅 포트를 열도록 요청하는 두 환경 변수를 상속받습니다. 이 변수들은 애플리케이션이 이미 전달하는 스위치를 대체하지 않고 뒤에 덧붙여집니다. 이후 세션은 자신의 프로세스를 감시하다가 그 포트가 나타나면, 그 뒤에 있는 모든 페이지와 모든 Worker를 애플리케이션과 같은 시계에 올립니다.
시작도 하나, 속도도 하나, 타임라인도 하나입니다. 속도 변경이나 점프는 애플리케이션과 그 페이지에 함께 닿으며, 페이지의 타이머도 자기 속도가 아니라 애플리케이션의 속도로 흐릅니다.
기본값은 켜짐이고, 스위치 하나로 끌 수 있습니다. 끄면 포트를 전혀 열지 않고 페이지는 실제 시계에 남습니다.
# 설정할 것이 없음 - 엔진이 있으면 찾아냄 chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60 # 또는 페이지는 그대로 두고 포트도 열지 않음 chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded
보고서가 페이지에 대해 말하는 것
페이지는 애플리케이션 자체의 숫자에 합쳐지지 않습니다. 프로세스와 페이지는 서로 다른 것이고 합산하면 아무 의미 없는 숫자를 지어내게 되므로, 별도의 단위로 셉니다.
- 머리말은 둘 다 셉니다 -
processes: 4, contexts: 1. - 각 페이지는 자신만의 줄을 가집니다. 명령줄에서는
context 1: page Date.now (12 calls), 창의 감사 표에서는 page Date.now - fake clock 같은 식입니다. - 도달한 엔진은 포트와 함께 이름이 표시되므로, 세션이 조작하는 바로 그 페이지에 자신의 DevTools를 연결할 수 있습니다.
드라이 런(dry run)은 무엇이든 시작하기 전에 페이지에 도달할 수 있는지 알려 줍니다. 판정의 의미 →
시작하기 전에 알아 둘 세 가지 제한
엔진이 실행되는 동안 디버깅 포트가 열려 있습니다.
이 컴퓨터에서만 수신하지만, 엔진이 실행되는 동안에는 이 컴퓨터의 모든 프로그램에 열려 있으며, 접근할 수 있는 것은 무엇이든 그 페이지들을 조작할 수 있습니다. 세션은 포트가 열릴 때마다 경고하며, 막연히 언급하는 대신 포트 번호를 밝힙니다. 공유되거나 신뢰할 수 없는 컴퓨터에서는 아무것도 열지 않는 스위치를 사용하세요.
상승된 권한으로 실행되는 앱은 닿지 않습니다.
상승된 권한의 애플리케이션이 호스팅하는 엔진은 세션이 설정한 변수를 무시하므로, 그 페이지는 실제 시계에 남습니다. 이는 설정이 아니라 엔진 자체의 규칙이며, 바깥에서 우회할 방법이 없습니다.
이런 세션은 PARTIAL로 보고하며, 그것이 솔직한 답입니다.
엔진의 보조 프로세스와 렌더러 자체의 네이티브 시간 호출은 실제 시계에 남습니다. 페이지는 세션 시계에 있고 그 패밀리의 나머지는 그렇지 않으므로, 판정은 일부라고 하고 올림해서 통과로 처리하는 대신 빠진 것의 이름을 밝힙니다.
더 작은 두 가지도 솔직히 말씀드립니다. 페이지는 세션 시간대를 고정 오프셋으로 읽으므로 Intl은 이를 도시가 아니라 GMT+02:00 같은 오프셋으로 부릅니다. 그리고 세션이 페이지에 도달하기 전에 예약된 타이머는 순수 Chromium 세션에서와 마찬가지로 원래 속도를 유지하며, 아무 일도 없었다고 결론짓지 않도록 세션이 경고합니다.
엔진이 레지스트리의 브라우저 인수 정책으로 구성되어 있다면, 세션 동안은 세션의 변수가 우선하며 보고서가 그 사실을 알립니다. 그곳에 설정한 디버깅 포트는 적용되지 않았을 것이기 때문입니다.
얼마나 잘 테스트되었나요
실험적이며, 여기서도 다른 곳과 같은 정해진 의미입니다. 만들어질 때 대상으로 삼은 앱에서는 동작하고, 폭넓게 테스트되지는 않았으며, 신뢰할 수 있는 출처는 이 페이지가 아니라 내장된 감사입니다. 자동화된 테스트 모음이 아니라 64비트 Windows의 WebView2 호스트와 Qt WebEngine 호스트를 대상으로 직접 측정했습니다. 그 실행에서 페이지는 세션의 연도를 세션의 속도로 읽었고 점프도 따라갔습니다.
32비트 Windows에는 나중에 발견하기보다 미리 알아 두는 편이 나은 주름이 있습니다. WebView2 런타임은 이를 호스팅하는 앱이 32비트여도 64비트이므로, 32비트 세션은 엔진의 프로세스나 그 역할의 이름을 밝힐 수 없습니다. 페이지로 가는 채널은 여전히 동작합니다. 보고서가 식별하지 못한 것에 대해 덜 구체적일 뿐이며, 둘 중 어느 경우인지는 밝힙니다.