เว็บเพจภายในแอปเนทีฟ

แอป 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 ของคุณเองไปที่หน้าที่เซสชันกำลังควบคุมอยู่ได้พอดี

การรันแบบทดลองบอกได้ว่าจะเข้าถึงหน้าเว็บหรือไม่ก่อนจะเริ่มอะไร ผลสรุปแต่ละแบบหมายความว่าอะไร →

อีกสองข้อเล็ก ๆ บอกตรง ๆ หน้าเว็บอ่านเขตเวลาของเซสชันเป็นค่าเหลื่อมคงที่ ดังนั้น Intl จึงเรียกมันด้วยค่าเหลื่อม เช่น GMT+02:00 ไม่ใช่ชื่อเมือง และตัวจับเวลาที่ตั้งไว้แล้วก่อนที่เซสชันจะไปถึงหน้าเว็บจะคงอัตราเดิม เช่นเดียวกับในเซสชัน Chromium ล้วน - เซสชันเตือนแทนที่จะปล่อยให้คุณสรุปว่าไม่มีอะไรเกิดขึ้น

หากเอนจินถูกตั้งค่าผ่านนโยบายอาร์กิวเมนต์ของเบราว์เซอร์ในรีจิสทรี ตัวแปรของเซสชันจะมีลำดับก่อนตลอดช่วงเซสชัน และรายงานจะบอกเรื่องนี้ - เพราะพอร์ตดีบักที่คุณตั้งไว้ที่นั่นจะไม่ถูกนำไปใช้

ทดลอง โดยมีความหมายที่กำหนดไว้เหมือนที่อื่นในที่นี้: มันทำงานได้กับเป้าหมายที่มันถูกสร้างมารองรับ ยังไม่ได้ทดสอบอย่างกว้างขวาง และการตรวจสอบในตัวคือแหล่งความจริงของคุณ ไม่ใช่หน้านี้ มันถูกวัดด้วยมือกับโฮสต์ WebView2 และโฮสต์ Qt WebEngine บน Windows 64 บิต ไม่ใช่ด้วยชุดทดสอบอัตโนมัติ ในการรันเหล่านั้น หน้าเว็บอ่านปีของเซสชันด้วยอัตราของเซสชันและตามการกระโดดได้

บน Windows 32 บิตมีเรื่องจุกจิกที่ควรรู้ไว้ก่อนแทนที่จะมาพบเอง: รันไทม์ WebView2 เป็น 64 บิตแม้แอปที่โฮสต์มันจะเป็น 32 บิต เซสชัน 32 บิตจึงระบุชื่อโพรเซสของเอนจินหรือบทบาทของมันไม่ได้ ช่องทางไปยังหน้าเว็บยังทำงานอยู่ รายงานเพียงแต่ระบุได้ไม่เจาะจงนักว่าอะไรที่มันระบุไม่ได้ และบอกว่าเป็นกรณีใดในสองกรณี