XbpHtmlViewer2 Neue Probleme

[Werner_Bayern]

Servus,

spätestens seit heute gibt es ein weiteres Problem (Absturz bei 1. Benutzung über einen Terminal-Server): Der Aufbau ist auf einigen PCs extrem langsam, auf anderen nicht.

Ich hab mich jetzt ca. 4 Stunden damit beschäftigt, sehr vieles probiert, unzählige Neustarts und De- und Installationen hinter mir. Fakt bei uns ist:

- Die aktuelle Runtime, die mit Edge mitgeliefert wird, ist der Verursacher
- Deinstallieren der Runtime ist nicht möglich
- Mit der Version 116 besteht das Problem nicht.

Ihr könnt hier die alte Version downloaden: https://developer.microsoft.com/de-de/m ... /webview2/

test.png (34.81 KiB) 3120 mal betrachtet

Dann den Inhalt im Ordner C:\Program Files (x86)\Microsoft\EdgeWebView\Application\117.0.2045.31 komplett wegsichern, löschen und mit der älteren Version ersetzen.

Ein Ausliefern der Runtime im EXE-Ordner hilft nicht, da anscheinend Alaska fix auf die Runtime im EdgeWebView-Ordner zugreift und für das Asset keinen Quellcode mitliefert.

Viel Erfolg!

[ssemleit]

Guten Morgen,

ich kann das von Werner beschriebene Problem bezüglich des extrem langsamen Aufbaus bestätigen.
Zum Glück haben wir das noch nicht produktiv beim Kunden am laufen.
Eine Horrorvorstellung, wenn unzählige Kunden gleichzeitig das Problem melden würden.
Das bei jedem Anwender so zu fixen und dann auch wieder rückgängig zu machen wäre ein extrem hoher Aufwand.
Bin gespannt, wo das Problem genau liegt.

[Jan]

Moin,

hat einer von Euch das an Alaska gemeldet? Frank hatte ja geschrieben das es diesen Monat ganz bestimmt ein Update geben wird. Wäre ja toll wenn die dieses Problem damit auch gleich fixen könnten.

Jan

[Werner_Bayern]

Servus Stefan,

mit meiner "Lösung" - die ich bewußt so gewählt habe - wird das beim nächsten Edge WebView2-Update wieder überschrieben. Ich gehe davon aus, dass MS das fixed und mit dem nächsten Update dann bereinigt. Somit würde sich das - zumindest in meiner Phantasie - automatisch regeln.

[Werner_Bayern]

Servus Jan,

das ist ja m. M. n. kein Fehler an dem Asset, sondern das Problem haben auch andere Programme, die nicht in Xbase++ geschrieben sind. Das liegt hier ziemlich eindeutig am MS Edge WebView2, das für solche Fälle extra in einem entsprechendem Unterordner des Edge installiert ist. Der Edge benutzt diese selbst nicht, er hat seine eigene Version!

[Jan]

Moin Werner,

aber es wäre ja nicht das erste mal das Alaska etwas einbaut, das einen MS-Fehler abfängt.

Jan

[Marcus Herz]

Wieviel Optimismus brauchts, um von Microsoft zeitnah einen Patch zu erwarten?

[Werner_Bayern]

Ich melde keine Fehler mehr an Alaska, das hat mich in der Vergangenheit viel zu viel Zeit gekostet und war für mich persönlich extrem frustrierend.

[ssemleit]

Guten Morgen,

wäre schon schön, wenn sich das Problem zeitnah wieder von alleine durch ein erneutes Microsoft-Update lösen würde.
Ich hab mal an den Alaska-Support geschrieben. Das Verhalten lässt sich ja ganz einfach nachstellen.
Vielleicht haben die ja schon einen Workaround?!

[ssemleit]

Guten Morgen,

hat noch jemand das Performace-Problem mit dem XbpHtmlViewer2 (WebView2)?
Mittlerweile gab es mehrere Updates von Microsoft (aktuell läuft bei mir die 117.0.2045.55).
Das Verhalten ist jedoch immer noch gleich. Beim Navigieren geht der WebView2 GPU-Prozess für Sekunden in die Höhe und die Anzeige friert ein.
Es ist jedoch nicht auf allen Rechnern zu beobachten, auch bei anscheinend gleicher Hardware.
Überwiegend läuft alles flüssig ohne Verzögerung.

[Tom]

Beim Navigieren geht der WebView2 GPU-Prozess für Sekunden in die Höhe und die Anzeige friert ein.

Das gleiche hier, auf einer i9-Killermaschine mit Monster-Grafikkarte (damit ich die GRA-Engine von Xbase++ voll auskosten kann ). Beim Scrollen im WebViewer gibt es diesen Moment - immer an der gleichen Stelle -, dann geht es weiter. Mit dem aktualisierten Asset und dem neuesten Edge ist es gefühlt einen Tick besser geworden, die Verzögerung ist kürzer, aber sie ist noch da. Auf zwei Windows-10-Maschinen ohne jeden Firlefanz: Kein Problem. Auf einem okayen W-11-Rechner ebenso.

[ssemleit]

Dann bin ich mit Werner also nicht alleine.
Auch bei uns unter Win10 kein Problem, unter Win11 vereinzelt.

@Tom
Hast Du das mal versucht, was Werner beschrieben hat mit dem Downgrade?
Ich hab es mal versucht, aber es waren ständig Dateien im Zugriff.

[Tom]

Hast Du das mal versucht, was Werner beschrieben hat mit dem Downgrade?

Bislang nicht. Zu fummelig. Zu wenig Zeit. Das wäre auch kein Weg, den ich unseren Kunden empfehlen könnte.

Edit: Wir nutzen den WebViewer vor allem für die GoogleMaps-Integration. Die benötigt in aller Regel kein Scrolling. Jetzt haben wir ein umfangreiches Statistik-Dashboard veröffentlicht, das mit ziemlich komplexem Zeug unterwegs ist (Bootstrap, Tabler, ApexCharts usw.), und da tritt das Problem erstmals auf, aber da das mitten im ersten Rollout steckt und bislang von wenigen Kunden genutzt wird, sind wir noch nicht im akuten Problembereich.

[ssemleit]

Das sehe ich durchaus auch so, dass das keine Lösung ist.
Mich würde nur interessieren, ob es mit der 116er Version wirklich flüssig läuft oder es evtl. an etwas anderem liegt.

[Tom]

Wenn ich Zeit finde, probiere ich das mit dem Downdate mal aus, aber wahrscheinlich nicht mehr in dieser Woche.

[Tom]

Ich wollte gerade auf die 116 downdaten, aber auf meinem Killerrechner läuft die 115. Mit der das Problem zumindest hier auch auftritt.

[ssemleit]

Vielleicht liegt es ja auch noch an etwas anderem.
Da es nicht bei allen Rechnern auftritt ist es echt schwer zu greifen.

[Tom]

Mmh. Wenn ich im gleichen Dialog statt der Anzeige meines eigenen Dokuments zu einer (durchaus komplexen) Website navigiere, habe ich das Problem offenbar auch nicht. Eigenartig ...

Edit: Stimmt nicht ganz. Das hier beispielsweise hängt beim Scrollen. https://tabler.io/preview

[ssemleit]

Es ist bei mir Wurst, was ich Anzeige.
Oft gehen 2-3 Klicks, Scrollvorgänge bzw. öffnen einer Seite ohne Verzögerung und dann ist wieder für ca. 5-10 Sekunden Stillstand.

[Werner_Bayern]

Ich hab es mal versucht, aber es waren ständig Dateien im Zugriff.

Du musst die MS-Edge-Prozesse im Taskmanager beenden, dann Edge selbst und die App, die die WebView2 benutzte. Dann gehts immer! Ja, ich kann bestätigen, dass es bei uns nach wie vor 3 von 12 PCs sind und alle bisherigen Updates die Probleme wieder hatten.

[Werner_Bayern]

Servus,

hat das jetzt schon mal jemand an Alaska gemeldet und eine Antwort erhalten? Die WebView2 wird ja alle paar Tage von MS upgedatet und das nervt. Heute hat es bei 2 PCs geholfen, im Edge den Effizienzmodus abzuschalten. Bei mir leider nicht.

[ssemleit]

Guten Morgen,

ich habe es dem Support gemeldet.
Bei Alaska haben sie jedoch keinen Rechner auf dem das auftritt.
Soll heißen, es ist dort nicht nachstellbar. Aktuell hat wohl keiner eine wirkliche Spur, an was das liegen könnte.
Ich hoffe auch mit jedem Update der WebView2 Runtime, dass es sich wieder bessert.
Aber dann nicht zu wissen, an was es lag, macht etwas Angst bezüglich kommender Updates.

[ssemleit]

Neue Woche, neues Glück?

Effizienzmodus abschalten -> Bringt bei mir nix
Aktuelle Version 119.0.2151.44 -> Bringt keine Besserung

[Werner_Bayern]

dto.
Alle bisherigen, unzähligen Updates haben den Fehler wieder gebracht.

[Klaus Schuster]

Ich bin auf folgenden Eintrag unter https://github.com/MicrosoftEdge/WebVie ... ssues/1818 gestoßen:

@andreeasor Hi, I'm a developer on the Edge networking team!

It looks like you have WPAD enabled in your proxy settings. WPAD defines a protocol for automatically finding a PAC file, which would in turn figure out a proxy URL.

In Chromium, the way this works is that we'll do a DNS lookup for "wpad". If this succeeds, we'll then try to retrieve a PAC file at http://wpad/wpad.dat. In your case, the DNS lookup for "wpad" is succeeding, but subsequent network call to retrieve the PAC file times out. This indicates that your network admin has misconfigured WPAD for Chromium. For startup to be fast on your VPN, the DNS lookup must fail OR the URL http://wpad/wpad.dat must be configured to return a PAC file.

The reason this is fast when you're not on VPN is probably that the DNS lookup for "wpad" fails, so we don't try to retrieve a PAC file. One way for you to make your WebView2 startup fast on your machine is to disable WPAD in your proxy settings.

There's much more detail about this stuff in my colleague's blog post:
https://textslashplain.com/2020/07/14/w ... discovery/