• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

[FRAGE] Problem mit IE11 und clientX

Wenn Du es genau wissen willst... es geht um ca. 120 Webanwendungen.
Mein Job ist das Framework dafür, welches die Technik und die zentralen Funktionen bereitstellt.
Javascript ist dabei nur ein ganz kleiner Faktor. Das Framework ansich besteht aus Komponenten wie JSF(eigene und fremde Bibliotheken), Ajax, Spring, Hibernate usw.
Daher ist mein Javascriptwissen auch begrenzt. Im Moment stellen wir halt auf den IE11 um und da kam das Problem hoch.
Natürlich können wir die Anwendungen auch im IE10 Modus laufen lassen, aber mein Ziel ist schon der IE11 Modus.

Das ist leider keine Frage des Konzeptes mehr, sondern der Migration.
 
Also den Schlüssel der Daten, die bearbeitet wurden. Dieser wurde beim Aufruf der ersten Seite gesperrt und muss beim Schliessen des Browser wieder entsperrt werden.
Sowas sollte man dann aber serverseitig mit Sessions machen. Die Methode mit dem onunload und vor allem das Verarbeiten der Position des Mauszeigers halte ich für äußerst fehleranfällig - was ist beispielsweise mit einem Klick ganz knapp neben den Close-Button? Oder wenn ich das Fenster per ALT+F4 schließe?
 
Wenn neben dem Close Button geklickt wird passiert nichts, das Fenster bleibt dann halt offen. Die Tastenkombinationen werden auch behandelt, auch dort wird der Schlüssel entsperrt.
Das läuft bereits seit einigen Jahren ohne große Probleme und falls doch mal ein Schlüssel gesperrt bleibt handeln wir das über ein Sessiontimeout von 5 Minuten.
Die Anwendungen "pingen" alle 4 Minuten unsere Server an, da manchmal die Bearbeitung unterbrochen wird und die Sessions dann bestehen bleiben müssen.
 
Wenn neben dem Close Button geklickt wird passiert nichts, das Fenster bleibt dann halt offen.
Nehmen wir doch mal an, ich wechsle über die Tastatur die Seite. Das onbeforeunload-Event feuert. Wenn ich jetzt meinen Mauszeiger über den Close-Button positioniere, "denkt" das Skript, ich würde den Browser schließen... Oder wie willst du herausfinden, dass nicht jemand das Fenster per Rechtsklick in die Taskleiste / Schließen schließt?
 
Richtig, der Fall tritt in sehr seltenen Fällen auf und aus dem Grund haben wir den Sessiontimeout auch konfiguriert...

Sorry, aber ich war eigentlich nur auf der Suche nach einer Lösung nach dem Problem mit dem IE11, da ich dachte hier gäbe es bessere Javascript Programmierer als mich.
Aber zu dem neuen Verhalten des IE kommt leider nichts, nur viel zu anderen Themen... :(
Naja anscheinend bin ich hier falsch, sorry ...:(
 
Und wenn eure Anwendung nur ein Tab im Fenster ist, habt ihr keine Chance, die richtige Position ausfindig zu machen.

Ich würde ja beim onbeforeunload immer ein Request an den Server schicken, das den Timeout auf 30 Sekunden oder so legt. Komplett unabhängig davon, wie das Event ausgelöst wurde. Wenn danach wieder eine Seite geladen wird, die zu dem Schlüssel gehört, kann die ja gleich einen Request schicken, dass der Timeout verlängert wird.

Mit der Mausposition wird das nie sauber funktionieren.

PS: Auch der FF hat als navigator.appName ein "Netscape", kennt aber kein window.event - dadurch wird ein Fehler geworfen und der Rest des Eventlisteners nicht ausgeführt.
PPS: Warum vergleichst du eine Zahl mit dem String "0"?

- - - Aktualisiert - - -

Zu dem Thema können wir nichts sagen, weil der IE11 das einfach so macht.

Als einzige Lösung würde mir jetzt einfallen, dass man bei jedem mousemove-Event die Mausposition ausliest und irgendwo (nein - nicht in einer globalen Variable) zwischenspeichert, so dass man in onbeforeunload darauf zugreifen kann. Aber wirklich sauber ist das auch nicht... hab's gerade ausprobiert: funktioniert nicht, da mousemove nicht feuert, wenn sich die Maus nicht auf dem Dokument, sondern auf den Steuerelementen des Browsers befindet.
 
Sorry, aber ich war eigentlich nur auf der Suche nach einer Lösung nach dem Problem mit dem IE11, da ich dachte hier gäbe es bessere Javascript Programmierer als mich.
Ich kann total nachvollziehen, dass du schon wegen der Migraion einen Hals hast. Und jetzt werden hier auch noch Rückfragen gestellt...
Aber lass dir gesagt sein, hier findest du wirklich einige richtig gute JS Cracks, die schon einiges umgesetzt und Erfahrungen dabei gesammelt haben.

Und vielleicht ist es manchmal wirklich nicht mit einer einfachen Migration einer hundertjährigen Lösung getan sondern man muss sie neu aufbauen. Wir sind dir dabei gern behilflich aber wir können dir den IE nicht verbiegen. Das musst du bitte bei Microsoft beauftragen oder dir einen eigenen customizden Browser bauen. Das ist übrigens eine garnicht mal so seltene Art und Weise (zumindest kenne ich das aus Großbetrieben mit dem Firefox) sich seinen "eigenen" Browser zu bauen. Wo ich das gesehen habe wurde z.B. der Rechtsklick anders belegt, die Konsole gesperrt, die Favoriten gesperrt und auch Tabs waren gesperrt, Menüs komplett entfernt usw. und so fort. War komplett dicht das Teil. Die Anwendung hat nur ein weiteres Fenster zugelassen aber keine Tabs. Wahrscheinlich auch so ein ähnliches Problem wie bei dir :)

Also du bist hier definitiv richtig aber zaubern können wir hier auch nicht.
 
Ich würde ja beim onbeforeunload immer ein Request an den Server schicken, das den Timeout auf 30 Sekunden oder so legt. Komplett unabhängig davon, wie das Event ausgelöst wurde. Wenn danach wieder eine Seite geladen wird, die zu dem Schlüssel gehört, kann die ja gleich einen Request schicken, dass der Timeout verlängert wird.

Mit der Mausposition wird das nie sauber funktionieren.
Danke, genau das wollte ich sagen.
 
Und ich sagte bereits:
"Die Anwendungen "pingen" alle 4 Minuten unsere Server an, da manchmal die Bearbeitung unterbrochen wird und die Sessions dann bestehen bleiben müssen."

Dieser Ping übernimmt somit die Aufrechterhaltung der Session... daher müssen wir das nicht über das onbeforeunload handeln. Da dieser Ping wegfällt sobald das Fenster geschlossen wurde.
4 Minuten bleibt dann der Schlüssel noch gesperrt (Sessiontimeout des Servers). Dies ist aber schon an der Schmerzgrenze, da bei uns die Schlüssel nicht lang gesperrt bleiben dürfen, wenn sie nicht
bearbeitet werden.
Danke trotzdem und endgültig "Adios" ... :calm:
 
ich war eigentlich nur auf der Suche nach einer Lösung nach dem Problem mit dem IE11
Aber zu dem neuen Verhalten des IE kommt leider nichts, nur viel zu anderen Themen...
Wie gesagt:
Zu dem Thema können wir nichts sagen, weil der IE11 das einfach so macht.
Dafür können wir dir aber - bessere - Alternativlösungen zeigen:
Ich würde ja beim onbeforeunload immer ein Request an den Server schicken, das den Timeout auf 30 Sekunden oder so legt. Komplett unabhängig davon, wie das Event ausgelöst wurde. Wenn danach wieder eine Seite geladen wird, die zu dem Schlüssel gehört, kann die ja gleich einen Request schicken, dass der Timeout verlängert wird.


Und ich sagte bereits:
"Die Anwendungen "pingen" alle 4 Minuten unsere Server an, da manchmal die Bearbeitung unterbrochen wird und die Sessions dann bestehen bleiben müssen."

Dieser Ping übernimmt somit die Aufrechterhaltung der Session... daher müssen wir das nicht über das onbeforeunload handeln. Da dieser Ping wegfällt sobald das Fenster geschlossen wurde.
4 Minuten bleibt dann der Schlüssel noch gesperrt (Sessiontimeout des Servers). Dies ist aber schon an der Schmerzgrenze, da bei uns die Schlüssel nicht lang gesperrt bleiben dürfen, wenn sie nicht
bearbeitet werden.
Ich verstehe einfach nicht, warum du so krampfhaft an deiner Lösung festhältst, obwohl sie so fehleranfällig ist und im IE11 gleich überhaupt nicht funktioniert...

Und auf die folgenden Tipps bist du ebenfalls mit keinem Wort eingegangen:
PS: Auch der FF hat als navigator.appName ein "Netscape", kennt aber kein window.event - dadurch wird ein Fehler geworfen und der Rest des Eventlisteners nicht ausgeführt.
PPS: Warum vergleichst du eine Zahl mit dem String "0"?
Warum? Ist dein Ziel, dass das Ganze funktioniert; oder ist dein Ziel, dass das Ganze unbedingt mit diesem Mausposition-auslesen-Zeugs funktioniert? Falls letzteres: für manche Sachen lässt sich eben schlicht und einfach keine Lösung finden - so ärgerlich das dann auch ist...
 
@ j-l-n

Sag mal liest Du eigentlich meine Posting, oder verstehst Du einfach nicht meine Beschreibungen der Sachlage.533-18.gif

Es ist wahrlich ermüdent alles 2 mal zu erklären...
Dafür können wir dir aber - bessere - Alternativlösungen zeigen:

Ich würde ja beim onbeforeunload immer ein Request an den Server schicken, das den Timeout auf 30 Sekunden oder so legt. Komplett unabhängig davon, wie das Event ausgelöst wurde. Wenn danach wieder eine Seite geladen wird, die zu dem Schlüssel gehört, kann die ja gleich einen Request schicken, dass der Timeout verlängert wird.

Haben wir bereits mit dem Ping viel komfortabler und besser gelöst essen23.gif

Ich verstehe einfach nicht, warum du so krampfhaft an deiner Lösung festhältst, obwohl sie so fehleranfällig ist und im IE11 gleich überhaupt nicht funktioniert...

Weil man eben 120 Anwendungen mal nicht so eben einfach umstellt.533-18.gif

Und auf die folgenden Tipps bist du ebenfalls mit keinem Wort eingegangen:

PS: Auch der FF hat als navigator.appName ein "Netscape", kennt aber kein window.event - dadurch wird ein Fehler geworfen und der Rest des Eventlisteners nicht ausgeführt.
PPS: Warum vergleichst du eine Zahl mit dem String "0"?

Weil es kein Tipp ist und nichts mit dem eigentlichen Problem zu tun hatessen23.gif

Falls letzteres: für manche Sachen lässt sich eben schlicht und einfach keine Lösung finden - so ärgerlich das dann auch ist...

Als kleine Info für Dich, Microsoft hat das Problem heute als Bug aufgenommen und wird sich mit mir am Montag in Verbindung setzen...

Auch Dir "Danke"... für mich ist nun hier Sendepause....4dl-44.gif
 
Haben wir bereits mit dem Ping viel komfortabler und besser gelöst
Mein Vorschlag ist im Grund genommen das gleiche wie der Ping, nur etwas aufgebohrt...

Weil es kein Tipp ist und nichts mit dem eigentlichen Problem zu tun hat
Ja ist kein Tipp und hat nicht mit deinem beschriebenen Probelm zu tun. Kann aber zum Problem werden bzw. macht die Anwendung langsamer.
 
Zurück
Oben