Halaman web di dalam aplikasi native

Aplikasi desktop dengan web engine bawaan menjalankan halamannya di proses terpisah yang terisolasi. Mekanisme native mencakup aplikasinya dan berhenti di batas itu - sehingga jendela berpindah ke tanggal yang Anda minta, sedangkan panel di dalamnya tidak. Ini menutup celah tersebut.

Kegagalan yang tampak seperti keberhasilan

Banyak aplikasi Windows yang native di luar dan halaman web di dalam. Layar pengaturan, dasbor, tampilan laporan, panel lisensi - dibuat sekali dalam HTML dan di-host di WebView2 atau Qt WebEngine, bukan ditulis dua kali.

Engine menjalankan halaman-halaman itu di prosesnya sendiri, dan proses itu terisolasi. Pustaka yang disuntikkan ke aplikasi tidak dapat masuk ke dalamnya. Segala sesuatu yang diminta aplikasi dari Windows berpindah ke tanggal sesi, dan segala sesuatu yang diminta halaman dari JavaScript tidak:

Bilah judul, log, dan file menyatakan 2038.
Panel di dalam jendela yang sama menyatakan hari ini.
Tidak ada yang error, tidak ada yang memperingatkan, dan kedua belahnya tampak sama yakinnya.

Itulah versi mahal dari bug ini, karena pengujian tampak sudah berjalan. Perilaku yang lebih lama melaporkan sesi semacam itu sebagai lulus bersih, klaim yang tidak dapat didukung oleh alatnya.

Apa yang dilakukan sesi sebagai gantinya

Sesi menjalankan kedua mekanisme sekaligus. Hook native masuk ke aplikasi seperti biasa, dan halaman dijangkau dengan satu-satunya cara untuk menjangkau renderer terisolasi: dengan bertanya kepada engine itu sendiri.

Saat peluncuran, aplikasi mewarisi dua variabel lingkungan yang meminta engine-nya membuka port debug lokal. Keduanya ditambahkan ke switch apa pun yang sudah diteruskan aplikasi, bukan menggantikannya. Sesi lalu mengawasi proses-prosesnya sendiri hingga port itu muncul, dan ketika muncul, setiap halaman dan setiap worker di baliknya berpindah ke jam yang sama dengan aplikasi.

Satu awal, satu kecepatan, satu linimasa. Perubahan kecepatan atau lompatan mencapai aplikasi dan halamannya bersama-sama, dan timer halaman berjalan dengan laju aplikasi, bukan laju miliknya sendiri.

Ini aktif secara bawaan dan dimatikan dengan satu switch, yang tidak membuka port sama sekali dan membiarkan halaman pada jam nyata.

# Tidak ada yang perlu dikonfigurasi - engine ditemukan jika ada
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60

# Atau biarkan halaman apa adanya, dan jangan buka port
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded

Apa yang dikatakan laporan tentang halaman

Halaman tidak dilebur ke dalam angka milik aplikasi. Mereka dihitung sebagai unit tersendiri, karena proses dan halaman adalah hal yang berbeda dan menjumlahkannya akan mengarang angka yang tidak berarti:

Judul laporan menghitung keduanya - processes: 4, contexts: 1.
Setiap halaman mendapat barisnya sendiri, seperti context 1: page Date.now (12 calls) di baris perintah dan page Date.now - fake clock di tabel audit jendela.
Engine yang dijangkau disebutkan beserta portnya, sehingga Anda dapat mengarahkan DevTools Anda sendiri tepat ke halaman yang dikendalikan sesi.

Dry run menyatakan apakah halaman akan dijangkau sebelum apa pun dimulai. Arti setiap putusan →

Tiga batasan yang perlu diketahui sebelum Anda mulai

Port debug tetap terbuka selama engine berjalan.

Ia hanya mendengarkan di komputer ini, tetapi terbuka bagi program apa pun di komputer ini selama engine berjalan, dan apa pun yang dapat menjangkaunya dapat mengendalikan halaman-halaman itu. Sesi memperingatkannya setiap kali port dibuka, dan menyebutkan nomor port-nya, bukan sekadar menyinggungnya secara abstrak. Pada mesin bersama atau yang tidak tepercaya, pakai switch yang tidak membuka apa pun.

Aplikasi yang berjalan dengan hak tinggi berada di luar jangkauan.

Engine yang di-host oleh aplikasi dengan hak tinggi mengabaikan variabel yang disetel sesi, sehingga halamannya tetap pada jam nyata. Ini aturan engine itu sendiri, bukan pengaturan, dan tidak ada cara untuk menyiasatinya dari luar.

Sesi seperti itu melaporkan PARTIAL, dan itu jawaban yang jujur.

Proses pembantu engine, dan panggilan waktu native renderer sendiri, tetap pada jam nyata. Halaman ada di jam sesi dan sisa keluarga itu tidak, sehingga putusan menyatakan sebagian dan menyebutkan apa yang tertinggal, bukan membulatkan ke atas menjadi lulus.

Dua yang lebih kecil, disampaikan terus terang. Halaman membaca zona waktu sesi sebagai selisih tetap, sehingga Intl menamainya dengan selisihnya, seperti GMT+02:00, bukan dengan nama kota. Dan timer yang sudah dijadwalkan sebelum sesi menjangkau halaman mempertahankan laju lamanya, sama seperti pada sesi Chromium murni - sesi memperingatkan, bukan membiarkan Anda menyimpulkan tidak terjadi apa-apa.

Jika engine dikonfigurasi melalui kebijakan argumen peramban di registry, variabel sesi diutamakan selama sesi berlangsung, dan laporan menyatakannya - karena port debug yang Anda siapkan di sana tidak akan diterapkan.

Seberapa baik pengujiannya

Eksperimental, dengan arti yang ditetapkan sama seperti di tempat lain di sini: ia berfungsi pada target tempat ia dibangun, belum diuji secara luas, dan audit bawaan adalah sumber kebenaran Anda, bukan halaman ini. Ia diukur secara manual terhadap host WebView2 dan host Qt WebEngine di Windows 64-bit, bukan dengan rangkaian otomatis. Pada eksekusi itu, halaman membaca tahun sesi pada laju sesi dan mengikuti lompatan.

Pada Windows 32-bit ada satu kerumitan yang lebih baik diketahui daripada ditemukan sendiri: runtime WebView2 adalah 64-bit bahkan ketika aplikasi yang menjadi host-nya 32-bit, sehingga sesi 32-bit tidak dapat menyebutkan proses engine atau perannya. Kanal ke halaman tetap berfungsi. Laporannya hanya kurang spesifik tentang apa yang tidak dapat diidentifikasinya, dan menyatakan mana dari keduanya itu.

Cobalah

Unduh untuk Windows Baca FAQ