Seid Anfang Juni hat sich ein Reload Bug in Fhem eingeschlichen.
Nutzer des ios6 styles haben mich darauf aufmerksam gemacht. Habe es leider durch meinen wohl zu großen Update Zyklus nicht sofort gemerkt.
Das Problem sieht wie folgt aus. Man hat in jQuery eine Click Funktion so wie diese hier:
$(document).ready(function() {
/*
/* Style Config
*/
$("#logo").click(function () {
$("#menu").toggle();
});
// Hier wird der Logolink entfernt und durch ein # ersetzt
var parentLink = $("#logo").parent("a");
if (typeof(parentLink.attr("href")) == "undefined") {
parentLink.attr("onclick", "#");
} else {
parentLink.attr("href", "#");
}
});
Ist die Funktion ausgeführt worden, wird jedoch nicht der Anker (#) aufgerufen, sondern Fhem neu geladen, dass alle durch JS gesetzten Klassen etc. entfernt :(
Hat jemand eine Idee wo sich der Fehler eingeschlichen haben könnte?
PS: das erste mal ist das Problem am 12.06. aufgefallen
In der letzten Zeit hat fhemweb.js zunehmend mehr <a> tags ueberschrieben, damit die Aktionen in JavaScript ausgefuehrt werden, und kein Reload der Seite verursachen. Ich vermute, dass die beiden Programme sich gegenseitig stoeren.
Tritt das Problem immer noch auf? Ich habe vor 3 Tagen ein paar Probleme in diesem Bereich gefixt.
Falls ja, kannst du mir bitte ein konkretes Beispiel geben, was ich direkt testen kann?
Und auch beschreiben, was man erwartet.
Mal ne Frage am Rande:
Seit einigen Tagen öffnet sich beim Klick auf das Mausrad (Link im neuen Tab öffnen) gleichzeitig auch der Link im Ursprungsfenster. Somit habe ich danach zwei Fenster mit gleichem Inhalt.
Ich bin nur schnell durch die letzten Commits gedüst und ich habe auch nur gezielt nach JS-Änderungen gesucht. Ich hatte leider noch keine Möglichkeiten, ein Revert auszuprobieren, aber könnte der Fehler evtl. durch eine der letzten Commits in fhemweb.js (https://github.com/mhop/fhem-mirror/commits/master/fhem/www/pgm2/fhemweb.js) kommen?
Kann nicht nachvollziehen, bitte ganz genau beschreiben, am besten anhand eines Beispiels mit fhem.cfg.demo
Ich habe vor 2-3 Tage genau so ein Problem behoben, evtl. ist das Problem nach einem frischen update geloest.
Okay, ich habe gerade festgestellt, dass der Fehler im Firefox nicht auftritt. Aber im Google Chrome Browser.
Es spielt auch keine Rolle, welches Style aktiviert ist.
Beschreibung:
- Ich befinde mich auf der FHEM Startseite
- Dann klicke ich auf den Menüpunkt "Logfile" mit der mittleren Maustaste
- das aktuelle Tab lädt das Logfile
- zeitgleich öffnet sich (gewollt) ein neues Tab und dort wird auch das Logfile geladen.
Wenn ich im Internet surfe, dann klicke ich ständig Seiten in neue Tabs, um diese danach "abzuarbeiten". Nun ist es bei FHEM jedoch der Fall, dass die im Hintergrund gewünschte Aktion leider auch im Vordergrund ausgeführt wird.
Mein FHEM ist up-to-date. Cache geleert. Etc.
Zitat von: rudolfkoenig am 15 Juli 2015, 17:10:43
Tritt das Problem immer noch auf? Ich habe vor 3 Tagen ein paar Probleme in diesem Bereich gefixt.
Falls ja, kannst du mir bitte ein konkretes Beispiel geben, was ich direkt testen kann?
Und auch beschreiben, was man erwartet.
Leider besteht das Problem immer noch.
Beispiel zum Nachstellen, bei dem es aufgefallen ist:
1. Ios6 style (z.b. Touchpad) ist ausgewählt.
2. pgm/ios6.js ist als JavaScript in der config angehängt
Sollzustand: bei Click auf das Logo klappt das Menü auf bzw. zu (nachvollziehbar mit der fhemweb.js Version vor dem 12.06.)
Istzustand: Menü klappt zu, reload der Page -> gesetzte klasse geht verloren somit ist das Menü immer noch geöffnet
Alternativ kannst du auch mit dem Code von oben testen, der ist nur auf das Problem reduziert
Vielen Dank schonmal :)
@FunkOdyssey: Das Problem trat bei mir ueberall auf (Shift-Click bzw. Meta-Click, verwende ich nie).
Ich habe es jetzt gefixt (update ab morgen), leider verstehe ich weder, warum das Problem auftrat, noch, warum mein Patch das verhindert. Wenn jemand mir die Ursache erklaeren koennte, waere ich dankbar.
@Blackcat: Du hast eine Funktion von FHEMWEB (Klick auf Icon leitet einen zu motd oder defaultRoom) geklaut, und jetzt, wo das Klauen nicht mehr klappt, soll der "Bestohlene" helfen, das funktioniert so nicht. :)
Stattdessen musst Du das Klauen perfektionieren: $(parentLink).unbind("click")
Ich habe eine ähnliches Verhalten beobachtet. Wenn ich versuche einen Link auf der FHEM Startseite in einem neuen Tab zu öffen, z.B. zum Logfile, benutze ich die Kombination Strg+linke Maustaste. Es wird, wie gewünscht, ein neuer Tab mit dem Logfile geöffnet, aber gleichzeitig wird das Logfile in dem aktuellen Tab geöffnet. Ich habe dieses Verhalten beim Firefox beobachtet. Bei Benutzung der mittleren Maustaste wird das Logfile nur im neuen Tab geöffnet. Auch das Öffnen des Links über das Kontextmenü "Link in einem neuen Tab öffnen" funktioniert einwandfrei.
Zitat von: rudolfkoenig am 16 Juli 2015, 12:52:24
@Blackcat: Du hast eine Funktion von FHEMWEB (Klick auf Icon leitet einen zu motd oder defaultRoom) geklaut, und jetzt, wo das Klauen nicht mehr klappt, soll der "Bestohlene" helfen, das funktioniert so nicht. :)
Stattdessen musst Du das Klauen perfektionieren: $(parentLink).unbind("click")
Elstern klauen gerne das schöne, klitzernde und benutzen es für ihre Zwecke :) Denn was eignet sich besser als Menü Button im mobilen Bereich als das schöne Logo ;)
Aber du hast recht, ich sollte nochmal zu Lupin in die Schule gehen ::)
Vielen Dank ! Da werden sich morgen mit dem Update wieder ein paar User freuen über geklaute Ware ;D
Nach dem Update heute morgen öffnet Strg+linke Maustaste einen Link immer noch im aktuellen Tab und in einem Neuen.
Soweit ich weiß ist Sourceforge down und beim Update Check wird mir (vermutlich daher) die neue Datei nicht angezeigt. Bist du also sicher, dass du die neue Version erhalten hast?
Der update heute frueh ging leider schief, da sourceforge um 7:45 bereits down war.
O.k., jetzt sehe ich es im Logfile, da ist kein fhemweb dabei.
Da das SCM ja nun wieder läuft, habe ich mir manuell die aktuelle Version von "fhemweb.js" geholt.
Jedoch habe ich leider immer noch das Problem in Google Chrome.
Oder habe ich da eine weitere Änderung übersehen?
Nachtrag: Hmm, irgendwie finde ich das entsprechende Commit nicht mehr wieder. Ist der Fix im SVN überhaupt angekommen?
der "Fix" betrifft nur das ios6 Menü ;)
Mist. Lange gehofft und falsch geguckt.
Ich habe ein IOS7 Style
Kein Problem.
Mir ist auch aufgefallen, dass der Stand vom SVN auch nicht der aktuelleste war (Wiederherstellungspunkt von Sourceforge).. somit habe ich es nochmal eingecheckt
@Rudolf: könntest du dir bitte das andere Problem (iOS7 Style) anschauen? Danke.
ja, dauert aber noch ca 2 Wochen
So, ich habe die Änderungen gefunden, die den Fehler in GoogleChrome verursacht:
==> fhemweb.js: remove "Connection lost" messages on iOS when changing the room (http://sourceforge.net/p/fhem/code/8928/)
Beitrag wurde nachträglich mehrmals aktualisiert.
Ich habe mit dem standard fhem.cfg, aktuellen Chrome, Click mit Meta oder Shift auf Logfile keine Probleme.
Click aufs Logo bringt einen zu motd/defaultRoom, ios6 macht da was spezielles mit eigenen .js, was die anderen Styles nicht haben.
@FunkOdyssey: hast du das Problem immer noch? Wenn ja, bitte genau beschreiben, ich bin etwas durcheinander.
Ich habe bei mir den o.g. Commit rückgängig gemacht und die fhemweb.js aus nem Update bis zum Fix herausgenommen. Der Fehler ist bei einer normalen Installation definitiv präsent.
Browser: GoogleChrome unter Windows
Style: iOS7
Beim Klick auf das Mausrad wird normalerweise ein neue Tab geöffnet und der sichtbare Inhalt bleibt unverändert. Doch die fehlerhafte Situation verursacht ein Laden des angeklickten Links auch im aktiven Tab. Somit wird der Link zweimal geladen.
Da ich das Problem mAn gefixt habe, und es selbst nicht nachvollziehen kann: kann jemand sonst das Problem bestaetigen oder widerlegen? Evtl. wird eine falsche Version der Datei geladen (Cache?): mein fhemweb.js ist 30015 Bytes lang, die relevante Stelle ist:
if(e.shiftKey || e.ctrlKey || e.metaKey) // Open link in window/tab
return;
Mein Problem ist mit dem Update gestern behoben: Strg + linke Maustaste öffnet einen neuen Tab, wie es sein soll.
So, ich habe mich nochmal sortiert und bin erneut Schritt für Schritt durchgegangen.
Mit [r8916] (http://sourceforge.net/p/fhem/code/8916/tree/trunk/fhem/www/pgm2/fhemweb.js?format=raw) "fhemweb.js: show set results in a dialog, not FW_errmsg (Forum #38875)" kann ich NOCH mit Klick auf die mittlere Maustaste ein neues Tab öffnen, ohne dass das aktive Tab auch diesen Inhalt lädt.
Mit
[r8928] (http://sourceforge.net/p/fhem/code/8928/tree/trunk/fhem/www/pgm2/fhemweb.js?format=raw) "fhemweb.js: remove "Connection lost" messages on iOS when changing the room" taucht dieses Fehlverhalten auf.
Somit wird der Fehler durch diesen Commit (http://sourceforge.net/p/fhem/code/8928/) verursacht:
--- a/trunk/fhem/www/pgm2/fhemweb.js
+++ b/trunk/fhem/www/pgm2/fhemweb.js
@@ -349,9 +349,19 @@
attr = attr.replace(/^location.href='/,'');
attr = attr.replace(/'$/,'');
}
+
+
var ma = attr.match(/^(.*\?)(cmd[^=]*=.*)$/);
- if(ma == null || ma.length == 0 || !ma[2].match(/=(save|set)/))
+ if(ma == null || ma.length == 0 || !ma[2].match(/=(save|set)/)) {
+ ma = attr.match(new RegExp("^"+FW_root)); // Avoid "Connection lost" @iOS
+ if(ma) {
+ $(el).click(function() {
+ FW_leaving = 1;
+ location.href = attr;
+ });
+ }
return;
+ }
$(el).removeAttr("href");
$(el).removeAttr("onclick");
$(el).click(function() {
Google Chrome (unter Windows) hat die Versionsnummer 44.
Und der Fehler scheint Style-unabhängig zu sein. Auch im Default-Skin tritt dieser Fehler auf.
Besteht das Problem mit einem aktuellen Version von fhemweb.js immer noch? In dem genannten Patch war meine vorher erwaehnte Zeile mit e.shiftkey usw. noch nicht enthalten, sie sollte das Problem beheben. Wenn das nicht der Fall ist, dann bitte vor der Zeile mit e.shiftkey folgendes einbauen:
console.log(e);
dann Seite neu laden, Problem reproduzieren, in der JavaScript Console das gemeldete Objekt (e) moeglichst vollstaendig oeffnen, und die Daten uns zeigen (Copy&Paste oder Bildschirmfoto).
Zitat von: rudolfkoenig am 23 August 2015, 14:26:51
Besteht das Problem mit einem aktuellen Version von fhemweb.js immer noch? In dem genannten Patch war meine vorher erwaehnte Zeile mit e.shiftkey usw. noch nicht enthalten, sie sollte das Problem beheben.
Die fhemweb.js wurde letztmalig am 9. August geändert. Meine Posts kommen vom 10. August mit aktueller FHEM-Version. Dennoch habe ich erneut ein Update gemacht, den Cache gelöscht usw.
Es gibt auch keine Proxys, etc.
Zitat von: rudolfkoenig am 23 August 2015, 14:26:51
Wenn das nicht der Fall ist, dann bitte vor der Zeile mit e.shiftkey folgendes einbauen:
console.log(e);
dann Seite neu laden, Problem reproduzieren, in der JavaScript Console das gemeldete Objekt (e) moeglichst vollstaendig oeffnen, und die Daten uns zeigen (Copy&Paste oder Bildschirmfoto).
Das habe ich gemacht (siehe Screenshot). Aber ich konnte das Objekt nicht weiter öffnen.
Ich hatte http://fhem:8083 geöffnet (Startseite) und dann mit dem Mausrad auf den Raum "Automation" geklickt.
Das Tab mit der Startseite hat dann den Raum "Automation" geladen. Außerdem wurde (wie gewünscht) ein weiteres Tab aufgemacht mit dem gleichen Raum "Automation".
ZitatAber ich konnte das Objekt nicht weiter öffnen.
Das ist schade, vlt. sehen wir mehr wenn du e.originalEvent ausgibst. Fuer mousewheel scheint es extra events zu geben, ich sehe in der Doku aber nur was von scrollen, nicht von clicken. Ausserdem scheint Firefox vom Rest sich zu unterscheiden.
Alternativ gewoehnst du dir Ctrl/Cmd-Linke-Maustaste an. :)
Ich hab mir ein Breakpoint gesetzt und habe mir die Ausgabe mal näher angeschaut.
Anhand der üblichen Verdächtigen "shiftKey", "ctrlKey" usw. konnte ich nichts erkennen. Aber der Wert "button" war auf "1". Und laut http://wiki.selfhtml.org/wiki/JavaScript/Objekte/DOM/event/button wird darunter anscheinend die mittlere Maustaste verstanden.
Quick&dirty habe ich dann folgende versucht:
if(e.shiftKey || e.ctrlKey || e.metaKey || e.button == 1) // Open link in window/tab
Und es funktioniert.
Habs eingecheckt.