Inoffizielles deutsches Xbase-Forum

Jahu.

Wir betten u.a. Requests an die GoogleMaps-API unter bestimmten Bedingungen als iFrames in HTML-Templates ein, wie Google das für die Einbettung in Websites auch anregt, etwa so: Unter Windows Server haben wir in dieser Situation leider manchmal das Problem, dass der XbpHtmlViewer an der Stelle, an der die Response von Google sichtbar sein sollte, nur eine weiße Fläche anzeigt. Das hat aber weder mit dem IE/Edge etwas zu tun, noch mit dem Request. Wir speichern den als HTML-Datei, die problemlos das richtige Ergebnis zeitigt, wenn man sie per Doppelklick in Edge öffnet, während sie Probleme machen kann, wenn sie per SetHTML an den XbpHtmlViewer gesendet wird. Es scheint tatsächlich etwas mit den Benutzerrechten zu tun zu haben. Nur - mit welchen? Wir haben dieses Verhalten sogar in Situationen bemerkt, in denen Rollen und Nutzerdaten kopiert wurden, und trotzdem war es so, dass der eine den Inhalt des iFrames sehen konnte, der andere nicht.

Javascript-Zeug funktioniert in allen Varianten einwandfrei.

So sollte das Ergebnis aussehen: Im Fehlerfall ist der Kartenbereich weiß. Wäre die URL ungültig o.ä., hätte er die Hintergrundfarbe des Rahmens. Wäre irgendwas mit Google, stünde dort eine Fehlermeldung. Es scheint etwas mit den iFrames zu sein. Aber was?

Ach so, die BROWSEREMULATION-Einträge u.ä. in der Registry sind vorhanden, alles fein. Es ist nicht das Control selbst.

Hast du schon mal versucht das loading auf eager zu setzen?

Hallo, Carlo.

Bei iFrames wäre das , aber ich wüsste nicht, was das helfen soll - das ist ja ein Mechanismus, der bei iFrames und eingebetteten Addons und Bildern das Nachladen erst dann auslöst, wenn sie in den sichtbaren Bereich gescrollt werden, aber die Sichtbarkeit ist hier immer gegeben. Es ist eine Dialogkomponente, und der Dialog ist letztlich bildschirmfüllend.

Aber ausprobieren kann ich's mal - wie gesagt, selbe Anwendung, selbe (!) Topologie, selber IE/Edge, unterschiedliche Benutzerkonten, das ist die Ausgangslage. Mal funktioniert's, mal nicht. Und offenbar ausschließlich auf Windows Server (2012, 2016, 2019) beim Einsatz als Terminal Server.

Hallo Tom

Cache, Cookies, Cross-Orgin Probleme sonst fällt mir dazu auch nichts mehr ein.