Webové stránky uvnitř nativní aplikace
Desktopová aplikace s vestavěným webovým enginem spouští své stránky v samostatném, izolovaném procesu. Nativní mechanismus pokryje aplikaci a na této hranici se zastaví - takže okno se přesune na datum, které jste chtěli, a panel uvnitř něj ne. Tohle tu mezeru zavírá.
Selhání, které vypadá jako úspěch
Spousta aplikací pro Windows je zvenku nativních a uvnitř je webová stránka. Obrazovka nastavení, dashboard, zobrazení sestavy, panel licence - postavené jednou v HTML a hostované v WebView2 nebo Qt WebEngine, místo aby se psaly dvakrát.
Engine spouští tyto stránky ve vlastním procesu a ten proces je izolovaný. Knihovna vložená do aplikace se do něj nedostane. Všechno, na co se aplikace zeptá Windows, se přesune na datum sezení, a všechno, na co se stránka zeptá JavaScriptu, ne:
- Záhlaví okna, logy a soubory říkají 2038.
- Panel uvnitř téhož okna říká dnes.
- Nic nehlásí chybu, nic nevaruje a obě poloviny vypadají stejně sebejistě.
To je ta drahá verze této chyby, protože se zdá, že test proběhl. Starší chování hlásilo takové sezení jako čistý úspěch, což bylo tvrzení, které nástroj nemohl podložit.
Co dělá sezení místo toho
Sezení spouští oba mechanismy najednou. Nativní hook vstoupí do aplikace jako vždy a ke stránkám se dostane jediným způsobem, jakým se cokoli dostane k izolovanému rendereru: zeptáním se samotného enginu.
Při spuštění zdědí aplikace dvě proměnné prostředí, které žádají její engine o otevření místního ladicího portu. Přidají se k přepínačům, které aplikace už předává, a nenahrazují je. Sezení pak sleduje vlastní procesy, dokud se ten port neobjeví, a když se objeví, každá stránka a každý worker za ním přejde na stejné hodiny jako aplikace.
Jeden start, jedna rychlost, jedna časová osa. Změna rychlosti nebo skok zasáhne aplikaci i její stránky společně a časovače stránek běží tempem aplikace, ne vlastním.
Je to zapnuto ve výchozím stavu a vypne se jedním přepínačem, který neotevře žádný port a nechá stránky na skutečných hodinách.
# Není co nastavovat - engine se najde, pokud tam je chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60 # Nebo stránky nechte na pokoji a neotevírejte žádný port chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded
Co zpráva říká o stránkách
Stránky se nezapočítávají do vlastních čísel aplikace. Počítají se jako samostatné jednotky, protože proces a stránka jsou různé věci a jejich sečtení by vymyslelo číslo, které nic neznamená:
- Hlavička počítá obojí -
processes: 4, contexts: 1. - Každá stránka dostane vlastní řádky, například
context 1: page Date.now (12 calls)na příkazovém řádku a page Date.now - fake clock v tabulce auditu v okně. - Engine, ke kterému se došlo, je pojmenován i s portem, takže můžete namířit vlastní DevTools přesně na stránky, které sezení řídí.
Zkušební běh (dry run) řekne, zda by se ke stránkám dostalo, dřív než se cokoli spustí. Co verdikty znamenají →
Tři omezení, která stojí za to znát předem
Ladicí port zůstává otevřený, dokud engine běží.
Naslouchá jen na tomto počítači, ale je otevřený jakémukoli programu na tomto počítači, dokud engine běží, a cokoli, co se k němu dostane, může ty stránky ovládat. Sezení na to upozorní pokaždé, když byl nějaký otevřen, a port pojmenuje, místo aby o něm mluvilo obecně. Na sdíleném nebo nedůvěryhodném počítači použijte přepínač, který neotevře nic.
Aplikace běžící se zvýšenými právy je mimo dosah.
Engine hostovaný aplikací se zvýšenými právy ignoruje proměnné, které sezení nastavuje, takže jeho stránky zůstávají na skutečných hodinách. Je to vlastní pravidlo enginu, ne nastavení, a zvenčí neexistuje způsob, jak ho obejít.
Takové sezení hlásí PARTIAL a je to upřímná odpověď.
Pomocné procesy enginu a nativní časová volání rendereru zůstávají na skutečných hodinách. Stránky jsou na hodinách sezení a zbytek té rodiny ne, takže verdikt říká částečný a pojmenuje, co zůstalo stranou, místo aby zaokrouhlil nahoru na úspěch.
Dvě menší, řečené otevřeně. Stránky čtou časové pásmo sezení jako pevný posun, takže ho
Intl pojmenuje posunem, například GMT+02:00, ne městem. A časovač
naplánovaný už předtím, než se sezení ke stránce dostalo, si ponechává svou starou
rychlost, stejně jako v čistém sezení Chromium - sezení na to upozorní, místo aby vás
nechalo dojít k závěru, že se nic nestalo.
Pokud je engine nakonfigurován zásadou argumentů prohlížeče v registru, proměnná sezení má po dobu sezení přednost a zpráva to říká - protože ladicí port, který tam nastavíte, by se neuplatnil.
Jak dobře je otestován
Experimentální, se stejným definovaným významem jako jinde na webu: funguje na cílech, proti kterým vznikl, nebyl široce testován a vestavěný audit je váš zdroj pravdy, ne tato stránka. Byl změřen ručně na hostiteli WebView2 a hostiteli Qt WebEngine na 64bitových Windows, ne automatickou sadou. V těchto bězích stránky četly rok sezení v rychlosti sezení a následovaly skok.
Na 32bitových Windows je záludnost, kterou je lepší znát než objevovat: běhové prostředí WebView2 je 64bitové i tehdy, když ho hostuje 32bitová aplikace, takže 32bitové sezení nemůže pojmenovat procesy enginu ani jejich role. Kanál ke stránkám přesto funguje. Zpráva je jen méně konkrétní v tom, co nedokázala určit, a říká, o který z obou případů jde.