Milupo, danke, das Problem ist geklärt...
Fein.
Beiträge von milupo
-
-
Liegt wahrscheinlich an meinen Scripten
Wenn ich mich nicht irre, kommen die TypeError- und ReferenceError-Fehler nur zustande, weil sich die entsprechenden Skript-Elemente nicht in der Konsole ausführen lassen. Gewissermaßen ganz normal.
-
Ich sehe gerade, in Beitrag #9 fehlt der Eintrag #appMenu-developer-button im Vergleich zu Beitrag #2. Da kann natürlich auch nichts darauf angewendet werden.
-
Boersenfeger Du hast ja in Beitrag #9 wieder ganz gekonnt die Einträge weggelassen, auf die es ankommt:
#appMenu-developer-button
#PanelUI-developer
Manchmal ist es besser den ganzen Code einzustellen, wenn man nicht weiß, wo genau der Hund begraben ist.
-
Ein weiteres Add-On wollte ich dafür aber nicht installieren
Das Add-on dient doch nur als Ausführungscontainer für das Skript, das dir Andreas angeboten hat. Es handelt sich dabei um eine der Erweiterungen Greasemonkey, Tampermonkey oder Violentmonkey.
-
Hallo Maria87, na bestens, geht doch.
Du hast in deinem Profilverzeichnis eine Datei user.js. Hast du diese Datei selbst angelegt? Wenn nicht, öffne die Datei in einem Texteditor und kopiere den Inhalt wieder mit dem Symbol </> in einen Code-Kasten, wie du es mit den Informationen zur Fehlerbehebung oben gemacht hast.
-
Ehrlich gesagt sieht das für mich nach einem Grafikfehler aus, d.h. ich würde denken, dass ein Deaktivieren der Hardwarebeschleunigung das Problem löst.
Und da könnte es einen gravierenden Unterschied zu Fx 71 und Fx 72 - soweit ich weiß, verwendet Büssen den auch - geben? Denn das Problem tritt ja nur in Fx 73 auf.
-
Das ist reichlich merkwürdig.
Ist es, vor allen Dingen, weil die Bildschirmfotos in den Beiträgen #356 und #366 unterschiedliche Seiten zeigen, einmal den Add-on-Manager und einmal eine Forumsseite. Meiner Meinung nach kann da der Fehler nicht nur in der about-addons.css liegen. Dann wäre sicherlich nur der Add-on-Manager betroffen. Andererseits auch nicht nur in der CSS-Datei für das Forum. Aber vielleicht in beiden.
-
Naja, wenn der Fehler aber in einem CSS Code liegt, bringt das erstmal auch nichts denke ich.
Nun ja, wenn das Problem nach Deaktivierung aller Skripte weiterbesteht, dann ist es wahrscheinlich, dass es CSS-Codes betrifft oder umgekehrt. Wenn du alle Codes in einen Ordner verschiebst, kann man natürlich jedes einzelne aktivieren. Ich denke aber, das ist zeitaufwändiger. Ich kann doch zwei Ordner anlegen, einen mit CSS-Codes und einen mit Skripten. Und dann teste ich die Hälfte der Skripte, Problem bleibt, andere Hälfte der Skripte Problem gelöst - oder, wenn nicht - kommen die CSS-Codes an der Reihe. Der ganze Aufwand lohnt sich aber natürlich nur, wenn man auch eine ganze Reihe von Skripten bzw. Code-Dateien hat. Bei jeweils drei Dateien kann man das auch einzeln machen.
-
Vielleicht kann man das da auch wie bei der Deaktivierung von Erweiterungen machen: Erst die Hälfte der Skripte aus dem Verkehr ziehen und wenn dann das Problem weiterhin bleibt, weiß man, dass sich das verursachende Skript innerhalb der ersten aktivierten Gruppe befindet. Da braucht man die andere Gruppe nicht erst durchsehen.
-
Meine Art dann:
Papierkorb von Windows leeren.
Meine Art: Dateiendungen in .txt ändern. Nicht ganz so riskant, aber vielleicht zeitaufwändiger.
-
Und dann hast du im nächsten Beitrag den Zusammenhang zu Scripts hergestellt. Daraus würde ich, wenn ich nicht das wüsste, was ich geschrieben habe, ableiten, dass das in den Scripts zu ersetzen wäre. Für mich liest sich das genau so. Und den Beitrag von Andreas interpretiere ich so, dass er auch so verstanden hat.
Ich habe aber auch diesen Satz geschrieben:
Es ist mir noch nicht bekannt, inwieweit das die Namensraum-Angabe betrifft
Es ist doch wohl fakt, dass der Namensraum ausgetauscht werden muss, aber es war mir da klar, dass man das nicht so einfach machen kann, weil es Probleme geben könnte. Der zitierte Satz ist vielleicht etwas dünn, aber er sollte genau das ausdrücken.
-
document.createElement() erstellt in XUL-Dokumenten Elemente im XUL-Namensraum und in (X)HTML-Dokumenten Elemente im XHTML-Namensraum
Zwischenzeitlich wurde ja mal document.createXULElement () eingeführt, ich habe gelesen, dass das wieder durch document.createElement () ersetzt wird, wenn XUL dann nicht mehr verwendet wird. Ich denke, dass da wohl ein Großteil der Skripte umgeschrieben werden muss, da viele Skripte ja Oberflächenelemente anlegen und sei es nur das eigene Symbol für die Symbolleiste.
-
Es gibt auch kein toolbarbutton-Element in (X)HTML, das ist ein XUL-Element. Im XHTML-Namensraum wäre dieses Element unbekannt. Fügt man das im XHTML-Namensraum ein, zerstört das Script die Oberfläche von Firefox.
Darum habe ich in meinem Eingangsbeitrag nicht einfach geschrieben, den XUL-Namensraum durch den XHTML-Namensraum zu ersetzen und natürlich habe ich ebenfalls getestet.
-
Könnte natürlich auch an der Webseite der Sparkasse liegen.
Ach du hast bei deiner eigenen Sparkasse getestet. Geht auch nicht anders.
-
Über welches Feld? Es gibt doch nur ein Bildschirmfoto. Und unten ist zwar der Pfad zu sehen, aber nicht vollständig.
-
2002Andreas Woher hast du die Selektoren genommen? Auf dem Bildschirmfoto kann ich die nicht sehen.
-
OK. Aber eigentlich müsste ich wenigstens die Startseite der Sparkasse erreichen können. Aber die ist womöglich eine andere. Ist das die Sparkasse Stuttgart?
Ich mache kein Onlinebanking. Was ist der Flicker für den TAN-Generator? Ist der auf deinem Screenshot zu sehen?
Zum Problem: Du kannst selbst sehen, dass die Klasse .block mehrfach im Inspektor angegeben ist, Klassen sind auch dafür da, an mehreren Stellen verwendet zu werden. Da gibt es keine Eindeutigkeit. Klicke dort mal an dem markierten Eintrag auf die drei Punkte. Da werden dann Untereinträge ausgeklappt.
-
Die Verbindung kommt nicht zustande. Selbst nicht mit http://www.sparkasse-sg.de
-
