De webpagina's binnen een native app

Een desktopapplicatie met een ingebouwde webengine draait haar pagina's in een apart, afgeschermd proces. Het native mechanisme dekt de applicatie en stopt bij die grens - dus het venster gaat naar de datum die je vroeg en het paneel erin niet. Dit dicht die kloof.

Het falen dat op succes lijkt

Veel Windows-applicaties zijn aan de buitenkant native en aan de binnenkant een webpagina. Een instellingenscherm, een dashboard, een rapportweergave, een licentiepaneel - eenmaal als HTML gebouwd en gehost in WebView2 of Qt WebEngine in plaats van tweemaal geschreven.

De engine draait die pagina's in een eigen proces, en dat proces is afgeschermd. Een in de applicatie geïnjecteerde bibliotheek komt er niet in. Alles wat de applicatie aan Windows vraagt, gaat naar de datum van de sessie, en alles wat de pagina aan JavaScript vraagt niet:

De titelbalk, de logboeken en de bestanden zeggen 2038.
Het paneel in hetzelfde venster zegt vandaag.
Niets geeft een fout, niets waarschuwt, en beide helften lijken even zelfverzekerd.

Dat is de dure variant van deze bug, omdat de test lijkt te zijn uitgevoerd. Het oudere gedrag meldde zo'n sessie als een schoon slagen, een bewering die het gereedschap niet kon onderbouwen.

Wat de sessie in plaats daarvan doet

De sessie draait beide mechanismen tegelijk. De native hook gaat zoals altijd in de applicatie, en de pagina's worden bereikt op de enige manier waarop je een afgeschermde renderer bereikt: door de engine zelf te vragen.

Bij het starten erft de applicatie twee omgevingsvariabelen die haar engine vragen een lokale debugpoort te openen. Ze worden toegevoegd aan de schakelaars die de applicatie al doorgeeft in plaats van ze te vervangen. De sessie let vervolgens op haar eigen processen tot die poort verschijnt, en wanneer dat gebeurt, gaan elke pagina en elke worker erachter op dezelfde klok als de applicatie.

Eén start, één snelheid, één tijdlijn. Een snelheidswijziging of een sprong bereikt de applicatie en haar pagina's samen, en de timers van de pagina's lopen op het tempo van de applicatie in plaats van op een eigen tempo.

Het staat standaard aan en gaat uit met één schakelaar, die helemaal geen poort opent en de pagina's op de echte klok laat.

# Niets te configureren - de engine wordt gevonden als hij er is
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60

# Of de pagina's met rust laten en geen poort openen
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded

Wat het rapport over de pagina's zegt

De pagina's worden niet opgenomen in de eigen cijfers van de applicatie. Ze worden als aparte eenheden geteld, omdat een proces en een pagina verschillende dingen zijn en ze optellen een getal zou verzinnen dat niets betekent:

De kop telt beide - processes: 4, contexts: 1.
Elke pagina krijgt eigen rijen, zoals context 1: page Date.now (12 calls) op de opdrachtregel en page Date.now - fake clock in de audittabel van het venster.
De bereikte engine wordt met zijn poort genoemd, zodat je je eigen DevTools precies kunt richten op de pagina's die de sessie aanstuurt.

Een proefrun zegt of de pagina's bereikt zouden worden voordat er iets wordt gestart. Wat de oordelen betekenen →

Drie beperkingen om te kennen voordat je begint

Er staat een debugpoort open zolang de engine draait.

Hij luistert alleen op deze computer, maar staat open voor elk programma op deze computer zolang de engine draait, en alles wat hem kan bereiken kan die pagina's aansturen. De sessie waarschuwt er elke keer voor dat er een is geopend, en noemt de poort in plaats van hem in het abstracte te vermelden. Gebruik op een gedeelde of onbetrouwbare machine de schakelaar die niets opent.

Een applicatie die met verhoogde rechten draait, is buiten bereik.

Een engine die door een verhoogde applicatie wordt gehost, negeert de variabelen die de sessie instelt, dus haar pagina's blijven op de echte klok. Dit is de eigen regel van de engine, geen instelling, en er is van buitenaf geen manier omheen.

Zo'n sessie meldt PARTIAL, en dat is het eerlijke antwoord.

De hulpprocessen van de engine, en de eigen native tijdaanroepen van de renderer, blijven op de echte klok. De pagina's zitten op de sessieklok en de rest van die familie niet, dus het oordeel zegt gedeeltelijk en noemt wat is weggelaten in plaats van naar een slagen af te ronden.

Twee kleinere, duidelijk gezegd. De pagina's lezen de sessiezone als een vaste afwijking, dus Intl noemt hem bij zijn afwijking, zoals GMT+02:00, en niet bij een stad. En een timer die al was ingepland voordat de sessie de pagina bereikte, behoudt zijn oude tempo, op dezelfde manier als in een zuivere Chromium-sessie - de sessie waarschuwt in plaats van je te laten concluderen dat er niets gebeurde.

Als de engine is geconfigureerd via een browserargumentenbeleid in het register, heeft de variabele van de sessie voor de duur ervan voorrang, en het rapport zegt dat - omdat een debugpoort die je daar had ingesteld niet zou zijn toegepast.

Hoe goed is het getest

Experimenteel, met dezelfde vaste betekenis als elders hier: het werkt op de doelen waarvoor het is gebouwd, het is niet breed getest, en de ingebouwde audit is jouw bron van waarheid, niet deze pagina. Het is met de hand gemeten tegen een WebView2-host en een Qt-WebEngine-host op 64-bits Windows, niet met de geautomatiseerde suite. In die runs lazen de pagina's het jaar van de sessie in het tempo van de sessie en volgden ze een sprong.

Op 32-bits Windows is er een kronkel die je beter kunt kennen dan ontdekken: de WebView2-runtime is 64-bits, ook als de applicatie die hem host 32-bits is, dus een 32-bits sessie kan de processen van de engine en hun rollen niet benoemen. Het kanaal naar de pagina's werkt nog steeds. Het rapport is alleen minder specifiek over wat het niet kon identificeren, en zegt welk van de twee gevallen het is.

Probeer het

Downloaden voor Windows Lees de FAQ