Inoffizielles deutsches Xbase-Forum

Web Proxy Auto Discovery Protocol (WPAD) zur automatischen Konfiguration eines Proxys in Webbrowsern deaktivieren:

HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ Wpad
Registry-Eintrag Empfohlener Wert
WpadOverride REG_DWORD 0x00000001 (1)

Hallo Klaus,

danke für den Hinweis.
Die Probleme dürften aber nix damit zu tun haben, da es auch beim reinen scrollen im Fenster,
also wenn wenn nix (nach)geladen wird, diese Verzögerungen gibt.
Ich habe aber den Registry-Eintrag zum testen mal gesetzt.
-> Hat leider nix gebracht!

Es wäre auch ein bisschen rätselhaft, wie das automatische Auffinden eines Proxys im lokalen Netz dabei helfen sollte, dieses Nachladeverhalten zu korrigieren, vor allem dann, wenn überhaupt kein Proxy vorhanden ist. Woher hast Du diese Info, Klaus?

Danke Werner. Tom, das stimmt. Aber, ich gebe die Hoffnung nicht auf. Und, auf dem Weg zur Lösung kann uns jeder Schritt möglicherweise weiter bringen... Im Lied 'Wenn Liebe das ist' von 'Ihre Kinder' heißt es: Manches führt zu Vielerlei.

Und, auf dem Weg zur Lösung kann uns jeder Schritt möglicherweise weiter bringen

Möglicherweise. Wenn er in die falsche Richtung geht, führt er von der Lösung weg.

Aber interessant, was es alles gibt! Ich werde mich jetzt mal ein bisschen mit dem WPAD befassen. Wenn wir unsere Backends in DMZs verwenden, kann das möglicherweise hilfreich sein.

ssemleit hat geschrieben: ↑Do, 16. Nov 2023 7:31 Die Probleme dürften aber nix damit zu tun haben, da es auch beim reinen scrollen im Fenster,
also wenn wenn nix (nach)geladen wird, diese Verzögerungen gibt.

Bei uns dauert auch die Darstellung schon sehr lange, ohne scrollen, sogar, wenn die Elemente leer sind. Man merkt da sofort das Problem. Wir haben uns jetzt mit einem Powershell - Script geholfen, das den oben beschriebenen Vorgang automatisch ausführt. Die extrem vielen Updates des Edge Webview2 nerven tierisch.

Ich habe das problem ebenfalls auf meinem Windows 11 Rechner beim anzeigen von Google maps. Es ist nicht mehr nutzbar.

Würdest du mir das Script zur Verfügung stellen?

Servus,

nachdem von Alaska hierzu nichts kommt, habe ich mich jetzt nochmal intensiv damit beschäftigt.

Die Lösung für Xbase++ - Progs ist einfach, vermutlich auch für andere Programmiersprachen. Xbase++ sucht sich den Pfad für die WebView2-Runtime in verschiedenen Schlüsseln der Registrierung - fängt beim u. a. Pfad an. Hier die Lösung:

"schnelle" WEB-View2 komplett (also nicht mittels Explorer, sondern z. B. mittels 7zip oder Winrar) in einen beliebigen Ordner (derzeit aber kein UNC) entpacken

Folgenden Registry-Eintrag anlegen:

Code: Alles auswählen

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge\WebView2]

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder]
"DeineEXE.exe"="C:\\Users\\xxx\\Downloads\\WebView2"

Kann ein beliebiger Pfad sein, achtet auf die doppelten Slashs, wenn es über eine REG-Datei gemacht wird. Ab dann nutzt DeineEXE.exe die Webview2 im entsprechenden Pfad!

Inzwischen kann man keine ältere WebView2 mehr downloaden, die noch schnell ist unter Xbase++ ist. Einfach eine PM an mich, dann gibts einen Downloadpfad dafür

Reg auch als Anhang, musste ich aber zippen, weil reg nicht erlaubt ist.

Viel Erfolg!

Danke Werner für Deinen Einsatz!

Aktuell fällt es mir schwer mit WebView2 zu entwicklen. Macht so keinen Spaß.
Bei Alaska tritt das Problem auf keinem ihrer Rechner auf. Deshalb können sie es wohl nicht lösen.

Das mit dem gesonderten Pfad für die WebView2-Runtime klingt super. PN folgt.
Auch wenn das keine Dauerlösung ist, wegen Sicherheitsupdates etc., kann man wenigstens wieder damit arbeiten.

Servus Stefan,

Sicherheit: Wenn Du damit nur HTML anzeigst und nicht im Internet surfen lässt (oder anklickbare Links), dürfte das vernachlässigbar sein. Mit dieser neuen Lösung schaltest Du nur Deine Applikation frei für das spezielle Webview2. Es liegt auch an Dir, diese upzudaten oder den Registrierungsschlüssel wieder zu löschen, wenn es wieder einwandfrei funktioniert oder eine neuere Version gibt, die dieses Verhalten nicht hat.

Jupp, so lange der Anwender keine Möglichkeit hat das ganze Web abzugrasen, dürfte es keine Sicherheitsprobleme geben.
Ich hoffe ja immer noch auf Lokalisierung und Lösung des Problems seitens Alaska.
Dein Workaound sieht nach einem super Workaround aus. Prima!

Hier noch eine Quellenangabe: https://learn.microsoft.com/en-us/deplo ... w-policies

Alaska ist sich des Problems aber bewusst und arbeitet auch daran. Ich habe heute eine Initiativanfrage vom Support bekommen und bin um ein paar Infos gebeten worden.

Alaska hat am 24. April den PDR 7662 angelegt mit dem Symptom "A slow-down can be observed in XbpHTMLViewer2 instances under certain conditions...". Gefixt wurde der am 26. April. Sollte also wohl Anfang kommender Woche im Update beseitigt sein.

Wenn das der Grund für die hier diskutierten Probleme sein sollte. Hört sich zwar gleich an, aber so viele Monate später erst angelegt?

Jan

Jan hat geschrieben: ↑Sa, 27. Apr 2024 17:22 Alaska hat am 24. April den PDR 7662 angelegt mit dem Symptom "A slow-down can be observed in XbpHTMLViewer2 instances under certain conditions...". Gefixt wurde der am 26. April. Sollte also wohl Anfang kommender Woche im Update beseitigt sein.

Wenn das der Grund für die hier diskutierten Probleme sein sollte. Hört sich zwar gleich an, aber so viele Monate später erst angelegt?

Ja, ich bin zuversichtlich, dass die bisher geschilderten Probleme damit behoben sein werden.
Vorerst. Das sage ich absichtlich. Wir sind mit unserer Lösung noch nicht 100% zufrieden. Wir arbeiten noch an unserer Zufriedenheit

.
Wir hatten 2 Lösungsansätze (für ein Problem, das von Microsoft verursacht wird/wurde). EInen recht aufwändigen, da haben wir uns aber vergallopiert. Und diesen, hier umgesetzten. Leider kann ich euch das eigentliche Problem nicht erklären, mangels technischem Verständnis. Das ist zu hoch für mich. Wurde aber von Microsoft mit einem bestimmten Build eingeführt.

Und der PDR wurde so spät erfasst, weil es eigentlich nichts mit Xbase++ zu tun hat. Wir umschiffen "nur" ein Problem. Den PDR haben wir somit aus Dokumnetationsgründen geschrieben. Wir haben uns ja dem Problem angenommen (annehmen können).

Das Update ist heute Morgen raus. Könnt es ja gerne mal testen.

Schöne Grüße
Frank

Könnt es ja gerne mal testen.

Bin dabei.

Hallo,

ich wollte das Update gerade installieren.
Da dachte ich mir, ich schau mir das Verhalten vorher noch mal an und hab aus der Registry
meinen Eintrag für die gesonderte Runtime für meine Anwendung entfernt.
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder]
Und siehe da, ich kann das Problem mit der Edge Webview2 Version 123.0.2420.97 und Xbase++ 2.00.2104 nicht mehr nachstellen.
Was ich auch beobachten kann ist, dass im Taskmanager unterhalb meiner Anwendung der WebView2 Prozess nicht mehr angezeigt wird.
Zudem läuft die msedgewebview2.exe nun anscheind auch immer auf der CPU, auf der auch die Anwendung läuft.
Könnt Ihr das auch beobachten?

ssemleit hat geschrieben: ↑Mo, 29. Apr 2024 13:14 Xbase++ 2.00.2104 nicht mehr nachstellen.

Ist das ein Typo? Denn da war unser Workaround noch nicht enthalten. Der kommt erst mit Xbase++ Build 2139.
Wird immer spannender ...

Frank

Nein, nein.
Ich hab noch die Xbase++ 2.00.2104 am laufen und wollte vor dem Update nochmal testen.
Also auch ohne Euren Workaround im Build 2139 läuft es schnell.

Danke für die Rückmeldung.
Hat eventuell auch MS etwas verbessert? Keine Ahnung.
Dann warte ich mal, was die Anderen so berichten.

Grüße
Frank

Dann warte ich mal, was die Anderen so berichten.

Uneinheitliches.
Windows-10-Maschine: XbpHtmlViewer2 hängt bei einem Projekt, bei dem es bislang immer und nachstellbar hing (jedenfalls bis zur letzten Inaugenscheinnahme, die ein paar Wochen zurückliegen mag, und es mag seither Windows-Updates gegeben haben), plötzlich nicht mehr - aber noch mit dem vorigen Build.
Windows-11-Maschine: XbpHtmlViewer2 hängt bei diesem Projekt mit Build 2104 nach wie vor. Nach Inbetriebnahme von Build 2139 und mit aktualisiertem Asset hängt es nicht mehr. Dasselbe auf einer weiteren W11-Maschine und auf einer virtualisierten.

Neuer Tag, neues Verhalten.

Gerade stellte ich fest, dass mit dem Build 2104 der XbpHtmlViewer2 nun doch wieder hängt.
Gestern war das nicht so und es lief flüssig.
Beim heutigen Start meines Rechners hat sich Webiew2 auf Version 124.0.2478.67 aktualisiert.
Damit scheint das Problem mit den Hängern nun wieder zu bestehen.

Nach der Installation des Build 2139 läuft der XbpHtmlViewer2 aber jetzt wieder flüssig.

Mir lässt sowas ja immer keine Ruhe....
Ich hab jetzt wieder die WebView2 Runtime 123.0.2420.97 für meine Anwendung aktiviert und siehe da,
damit läuft der XbpHtmlViewer2 (V1.5) aus dem Build 2104 flüssig.
Es liegt für mich also ganz klar an der Version von WebView2.

Also, lese ich es richtig: mit dem Build 2104 funktioniert es? Egal mit welcher WebView2 Version?
Darf ich das so lesen?

Frank

Das, was ich geschrieben habe: Ja.

Inoffizielles deutsches Xbase-Forum

XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme

Re: XbpHtmlViewer2 Neue Probleme