Wir sollten den Thread hier schließen. Ich habe mal eben einen einfachen Fall nachgestellt. Der scheint mit FF70 zu funktionieren.
Es könnte jetzt noch sein, dass mit jQuery irgendwo in die Hacken gelaufen ist oder dass der Fehler vorm Bildschirm sitzt. %-)
Trotzdem danke für die Hilfe.
Ich habe mal einen Fall nachgestellt. Mit Inspe
Ich habe das Problem falsch vereinfacht. Das Problem tritt bei Custom-Elementen auf.
Ich habe bisher unterstellt, dass die Data-Attribute bei Custom-Element genauso wie beim Div-Element arbeiten.
Das Problem tritt Konkret bei
<vendor-reaction id="vendor-reaction-1" data-gear="2">
auf.
Padina
Vermutlich ist es nur ein Einstellungsproblem mit den Entwickler-Tools oder ich habe an der Falschen Stelle gesucht.
Problem:
Ich habe im HTML ein Div-Tag mit Attribut wie zum Beispiel ´<div data-counter="3">´. Der Wert im Counter wird per JavaScript hochgezählt.
Nach dem Arbeiten mit der Seite möchte ich mit dem Entwickler-Tool irgenwo sehen, welchen Status das Div-Tag hat bzw. welcher Wert aktuell in Attribut 'data-Counter' steht hat.
Der inspect-Befehl in der Konsole der Entwicklertools zeigt mir aber immer nur das an, was an Werten initial beim Aufruf vorlag und nicht den aktuellen Wert.
Workaround:
Ich kann zwar per javascript, den aktuellen Wert abfragen, aber auf Dauer ist das unproduktiv.
Frage:
Ich denke, dass die Entwicklertools auch ein Abbild vom aktuellen Status eine DOM-Elements geben können. Die Frage ist nur, wo ich die Infos finde, oder wie ich die Entwicklertools konfigurieren muss, damit sie ein Snapshop vom jeweils aktuellen Status anzeigen.
Über Hilfe und Hinweise werde ich mich freuen.
Padina
Welches Sicherheitskonzept verfolgst denn bzw. willst du verfolgen?
Der passwort-Manager von Firefox ist bei mir immer nur Slave, so dass ich im Bedarfsfall einfach alle Passworte wegschmeiße.
1) Die Masterinstanz ist die KeePass-Datei, wobei ich für verschiedene projekte verschiedene KeyPass-Dateien habe. .
2) Man könnte aber zum Beispiel auch OwnCloud nutzen (https://www.heise.de/download/product/owncloud-85372)
Moin,
ich programmiere gerade an einer Extension für TYPO3, mit der ich zukünftig Akzeptanztests bzw. Upgrade-Tests durchführen kann. Das Grundkonzept basiert auf dem Zwei-Wege-Prinzip. Mit JavaScript werden einen Informationen der Frontendausgabe einer Webseite mit den Informationen vergleichen, die ich auch einem zweiten Weg erhalte.
Aktuell nutze ich für die detailierte Ausgabe der Hinweise und Fehler den console.log-Befehl. Wünschenswert wäre es aber, dass ich die Log-Hinweise in eine bzw. mehrere Log-Datei(en) schreibe, um die Daten unabhängig vom Rest der Javascript-Ausgaben händeln zu können.
Gibt es mit Firefox eine Möglichkeit, dies einfach und ohne manuelle Eingriffe des Users automatisch zu machen? Gibt es eventuell ein Add-On, dass eine entsptrechende Funktionalität schon anbietet? Für Ideen und Hinweise wäre ich dankbar.
Padina
Hallo DAUFahnder,
Vielen Dank für den Tipp.
ich werde die Schleife über die Background-Ebene einmal probieren, zu bauen. Hätte einige angenehme Eigenschaften.
Ich möchte nicht in mehreren Tabs arbeiten, weil der Surfalgorithmus parallel zu meiner normalen Arbeiten laufen soll. Außerdem leidet die Performance, wenn zu viele Tabs offen sind. Auch will ich gar im Detail nicht wissen, was der Browser automatisiert ansurft.
Hallo EffPeb,
danke für den Hinweis.
Ich werde es in jedem Fall ausprobieren, nach einem Alarm bei Location.href funktioniert. Der Event-Flow würde dadurch einfacher werden.
Als Anfänger kannte ich die Übersicht noch nicht. Sie scheint gut geeignet zu sein, um die für AddOn.-Entwicklung nötigen Vokabeln zu lernen.
Mit besten Dank für eure helfenden Hinweise
Padina
Ich habe vor kurzen begonnnen, mein erstes AddOn für Firefox zu programmieren.
Ich möchte ein AddOn haben, dass in einem Tab automatisch nach einiger Zeit eine neue Webseite ansurft.
Nach einem Aufruf von "window.location.href = " scheint das "setTimeout" nicht mehr zu funktionieren.
Es scheint, als ob beim Neuladen einer Seite das gesamte Content-Objekt verworfen wird, so dass der Timeout-Prozess verloren geht.
Grundsätzlich funktioniert das setTiemout in Bereich der ContentScripts, wie ein Test-CountDown-Zähler zeigte
Kann mir jemand einen Stups in die richtige Denkrichtung geben, wie ich das Problem lösen kann oder bei welchem AddOn ich einen Lösungsansatz finde?
Mit besten Grüßen
Padina
Wozu das Ganze? - Hintergrund:
Ich möchte ausprobieren, wie sich das Ansurfen bestimmter Webseiten bei angemeldeten google- und facebook Account auf die Suchergebnisse zu bestimmten Test-Suchbegriffen auswirkt. Gemäß des Mottos: "Ups, mein Browser surft wie ein ..."
Ganz einfaches Problem. 
Ich plane den Tastatur-Event ALT-D für ein JavaScript-Event auf meiner Website verwenden. (Schlimmer: eigentlich möchte ich in einem Menü für Frontend-Editing ALT-D plus Maus-Click verwenden, um einen Datensatz zu löschen. Ein Doppelclick ist mir für eine solche Aktion zu unsicher.)
Bei ALT-D öffnet Firefox aber gleich sein Print-Fenster, was extrem nervig ist, wenn die Maus hinter dem Fenster verschwindet.
Wie geht man bei Firefox bzw. bei Browsern allgemein mit der Konkurrenz von Key-Code-Events (Browser-menu – Webseite) um? - Als Entwickler möchte ich im JavaScript mein Alt-D-Event haben und ich möchte gleichzeitig dem User natürlich nicht das gewohnte Drucken per Tastatur verwehren.
Gibt es dazu allgemeine Regeln, wie man einfach verständliche Tastaturgesteuerte Web-Oberflächen entwickeln kann?
Gibt es standardisierte Umschaltmöglichkeiten und Visualisierungen, was gerade aktiv ist?
Gibt es Übersichten, welche Tastatur-Code in der Regel von verschiedenen Browsern für Standardaktionen vorbelegt sind (CTRL-C, CTRL-X, CTRL-V,...)? Ich könnte mir vorstellen, dass es nationale/sprachliche Unterschiede gibt (Druckfenster in DE => ALT-D; Druckfenster in EN => ALT-P., ...)
Nach meinem Gefühl ist das Thema " Best-Practice bei Key-Events" eher urwüchsig; aber ich habe mich seit Längerem nicht mehr mit Frontend-Fragen beschäftigt und bin damit definitiv nicht auf dem aktuellsten Stand.
Über Hinweise, die zur Lösung meines Anliegens beitragen können, werde ich mich riesig freuen. Selbst wenn es Hinweise auf Schlüsselwörter für die Suche sind.
Padina
Hallo Fox2Fox,
danke für den Hinweis. Dein Hinweis nach Sachlichkeit ist ein zweischneidiges Schwert, denn Humor ist natürlich immer auch ein sanfte Form der Kritik, die der Sachlichkeit nicht innewohnt.
Hallo Roadrunner,
danke für den Hinweis. Ich werde die Testdatei morgen mal auf einem Windows-7-Rechner ausprobieren. Vielleicht ist der Fehler ja nur auf einem "Ausluf"-Betriebssystem zu finden.
Vielleicht kann ich per CSS einen anderen Font ausweichen, bei welchem Firefox auf XP nicht diesen Fehler zeigt. (Tipp von Bernd).
Padina
Hallo Bernd,
vielen Dank für deine Ausführungen.
es könnte natürlich an einem fehlerhaft installierten Font liegen.
Aber es ist schon merkwürdig, wenn Firefox ein Unicode-Zeichen im Normaldruck korrekt und im Fettdruckmodus falsch darstellt. Übrigens können Opera oder auch der google-Chrome sowohl den Fettdruck wie auch den normaldruck problemlos gleichartig darstellen, wenn sie ein Zeichen verfügbar haben. Die nährt eher den verdacht, dass der Fehler beim Firefox und nicht beim Betriebssystem liegt.
Okay ist übrigens, dass in der Testdatei nicht alle Zeichen dargestellt werden, da ich für den Test nur einige Ziffern zufällig wählte und hoffte druckbare Zeichen zu finden.
Die beiden Antworten vorher zeigen, dass der Fehler wahrscheinlich nicht systematisch auftritt. Leider haben Road-Runner und madperson nicht geschrieben, welches Betriebssystem sie nutzen.
Zur Überschrift: Mir ist bekannt, dass der Browser Firefox heißt. Den Fehler habe ich aber Firemurx genannt, weil er mir bisher nur beim Firefox aufgefallen ist. "einwenig Humor darf doch wohl erlaubt sein, oder? "
Übrigens tritt der Fehler mit der Konvertierung der Zeichung auch bei css-Befehl font-weight:bolder auf oder bei font-weight: >=600.
Spannend ist auch, dass nur ein Teil des Unicode-Zeichensatzes von dem Fehler betroffen ist, wie das Beispiel der letzten beiden Zeilen zeigt.
Zu deinem Vorschlag, auf das Zeichen zu verzichten, sei gesagt, dass es in meinem Browser-Spiel Mobger um Pfeile (Gers) geht. Mein Ziel ist/war es dabei, das gesamte Spiel mit Javascript ohne Graphiken in einer einzelnen HTML-Datei zu kodieren. Ich brauche also die Unicode-zeichen. Wenn aber der Browser firefox nicht richtig funktioniert, so ist es einfach nur doof. (Übrigens kann ich zum Beispiel auf dem Samsung Galaxy ACE das Spiel MobGer auch nicht spielen, weil der Browser auf dem Händy bei vielen Unicode-Zeichen rumzickt. .) Aber vielleicht ist es ja nur mein Rechner, der rumzickt.
Hat also wer ähnlich Probleme wie ich?
Übrigens: Wer nach MobGer googlet, sollte sich noch einwenig gedulden. Dereit programmiere ich für MobGer Layout-Relaunch, um das Spiel für Smartphones wirklich attraktiv zu machen - in der Hoffnung, dass die technischen Standards irgendwann auch von allen Browsern erreicht werden und in der Hoffnung, bis zum spielautorentreffen Anfang Juni damit fertig zu sein.
Padina
Hallo Road-Runner,
Hallo madperson,
vielen Dank für eure rückmeldung.
Bei mir mit dem Firefox 20.0.1
auf einem laptop mit Windows XP (Service-Pack 3)
wird dagegen das Folgende angezeigt.
Welche Betriebssysteme habt ihr genutzt?
Padina
<div>ee ⬆ : ⬖⬦⬶⭆⭖⭦⭶⮆⮖⮦⮶⯆⯖⯦⯶</div>
Die oben codierte Webseite produziert im Normaldruck
Unicode-Pfeile und im Fettdruck kringelieges Zeichen. - Wahrscheinlich für alle Unicode-Zeichen größer 10.000.
Da ich Unicode-Zeichen für ein Browser-Game brauche, stellt sich mir die Frage, ob es für den Bug einen Work-Around gibt oder ob ich schreiben muss, dass FireFox 20.0 aus Windows XP für das Spiel nicht geeignet ist.
Padina
P.S. Auf Wunsch wurde die humoristische Anspielung aus der Betreff-Zeile genommen. Ich kann den Wunsch nach mehr sachlichkeit einerseits verstehen - andererseits ...
Wenn ich eine XHTML-basierte Seite mit "Datei Speichern unter" als "komplette Website" speichere, dann wird
aus
"<?xml version="1.0" encoding="utf-8" ?>"
nach dem Speichern
"<!--?xml version="1.0" encoding="utf-8" ?-->"
Auch werden in den Einzeltags die Abschließenden Slasches gestrippt und die Umlaute werden auch nicht zurückgesetzt.
aus
' <meta name="audience" content="Spieler, Player, Rätsellöser, Menschen" />
wird
' <meta name="audience" content="Spieler, Player, Rätsellöser, Menschen" />"'
Auch <br /> wird systematisch in <br> umgewandelt.
Das Zurückschreiben eine internen DOM-Objekte scheint nicht korrekt zu funktionieren.
P.S. Der Fehler passiert nicht, wenn man eine Seite nur als HTML-Seite speichert.
Mir fiel der Fehler nur auf, weil ich bei dem User die Möglichkeit zu geben, bei einem javascript-basierten Gesellschaftsspiel bestimmte Spieleinstellungen offline und ohne Cookie dauerhaft speichern zu können.
Padina
Hallo bugcatcher
Zitat von bugcatcher
Lösung ist recht trivial. Der div#content muss Abstand zum Rand hin halten, der den Bannern den benötigten Platz liefert. Ergo: margin-left:180px; und margin-right:180px;
Das ist der Work-Around, nach dem ich gesucht habe. Er bringt natürlich den Nachteil mit sich, dass unterhalb der Banner rechts und Links breite leere Streifgen bleiben; aber das lässt sich wohl nicht ändern. Ich werde demnächst das Design der Seite ändern, um auf diese Eigenarten von Opera und Firefox einzugehen.
Lieber Bugcatcher, und Ulli, vielen Dank noch einmal für eure Erläuterungen. Bugcatchers Satz bringt das Problem auf den Punkt:
Zitat von bugcatcher
Das DIV mag durchsichtig sein, ist aber trotzdem ein Block-Element und insofern verhält es sich wie eine Glasscheibe. Da kann man nicht "durchklicken".
Wenn dieser Satz von Firefox und Opera konsequent eingehalten werden würde, so ist es aus meiner Sicht widersprüchlich, dass im http://www.buergerstimmen.de/politik/ngo_1007.htm in einigen Bereichen des Banners der Link zu "sehen" ist und in anderen Bereichen nicht. Die Fotos zeigen eindeutig, dass die Reaktion von Firefox nicht vorhersagbar ist. Das spricht aus meine Sicht nicht unbedingt dafür, dass dieser Effekt gewollt ist.
Nach diesem Thread stelle ich für mich fest, dass ich die die "Float"-Anweisung im CSS falsch (Also im Stil des Internet-Explorers) verstanden habe. Augenscheinlich darf ich bei Firefox und Opera eine Anwendung der Float-Anweisung nur auf den sichtbaren Text erwarten. Nicht direkt sichtbaren Elemente wie Quicktexten oder Linkzuordnungen werden damit nicht unbedingt immer erfasst, was für mich eher nach einem Fehler als nach Gewollt aussieht.
Bei der zukünftigen Weiterentwicklung des Designs werde ich diese Eigenarten von Firefox und Opera mit berücksichtigen müssen, da sie weit verbreitete Browser sind.
Padina (Dieter)
P.S. Ich danke euch nochmals für eure Hilfe. Beim Work-Around war ich einfach wie blockiert. Ich habe ihn auch schon umgesetzt, so dass die "Fehler" jetzt nicht mehr auftreten.
Liebe Teilnehmer,
vielen Dank für die Hinweise.
Die Seite http://www.buergerstimmen.de/politik/ngo_1007.htm ist W3C-Kompatibel
http://validator.w3.org/check?…29&doctype=Inline&group=0
und hat auch eine korrekte CSS-Syntax
http://jigsaw.w3.org/css-valid…ng=1&vextwarning=&lang=de
und der Internet-Explorer ist in der Lage, die Seite korrekt darzustellen
Es ist also ein Bug im Browser von Firefox und Opera.
Aber leider kennt hier niemand einen Work-Around. So werde ich wohl weiter rumprobieren müssen.
Padina
Liebe Teilnehmer,
vielen Dank für eure Antworten.
Den Fehler mit dem fehlenden Body-Tag im IFRAME habe ich geändert. Aber das Problem bleibt.
Um den Fehler aufzuzeigen, musste ich eine Screen-Kamera verwenden, da bei normalen Screenshot die Mauseffekte nicht mit aufgenommen werden. Für die Foto habe ich die aktuelle Firefox Version 9.0.1 mit XP als Betriebssystem verwendet.
Beispiel http://www.buergerstimmen.de/politik/ngo_1007.htm
Bild 1
Der Mauszeiger ist oberhalb der roten Schlagzeile. Der Quicktext wird angezeigt und durch Anklicken kommt man zu Website, die hinterm Banner liegt.
[Blockierte Grafik: http://www.buergerstimmen.de/test/tl1.jpg]
Bild 2
Der Mauszeiger ist in Höhe der rotfarbenden Schlagzeile. Es erscheint kein Quicktext und auch die Verlinkung ist verschwunden. Wenn man hier rumklickt, wird der Text der Schlagzeile markiert
[Blockierte Grafik: http://www.buergerstimmen.de/test/tl2.jpg]
Bild 3
Der Mauszeiger ist unterhalb der rotfarbenden Schlagzeile. Es erscheint wieder der Quicktext. Auch die Verlinkung ist wieder vorhanden.
[Blockierte Grafik: http://www.buergerstimmen.de/test/tl3.jpg]
In dem speziellen Beispiel ist der Effekt nur auf den Linken Banner beschränkt. Bei der Übersichtsseite bzw. bei der Startseite mit den Schlagzeilen tritt der Effekt auch beim rechten Banner auf.
Bild 1.
Der Mauszeiger oberhalb der Oberhalb der ersten Schlagzeile
[Blockierte Grafik: http://www.buergerstimmen.de/test/hr1.jpg]
Bild 2
Der Mauszeiger ist in Höhe der rotfarbenden Schlagzeile. Es erscheint kein Quicktext. Auch die Verlinkung ist verschwunden.
[Blockierte Grafik: http://www.buergerstimmen.de/test/hr2.jpg]
Mit den Effekten bei den Einzelartikeln hätte ich leben könne, aber der Effekt auf der Startseite ist grausam.
Der Internet-Explorer zeigt diese Effekte nicht. Der Opera-Browser 11.60 zeigt ähnlich Effekte.
Für den Hinweis auf einen Work-Around wäre ich wirklich dankbar. Ich verstehe den Fehler nicht.
Dieter
Hallo
auf der Seite
http://www.buergerstimmen.de/politik/stadt_1302.htm
befindet sich rechts und links jeweils ein Banner, der innerhalb eines IFrames mit einem PHP-Skript erzeugt wird und der verlinkt ist.
in der Version 8 und auch in der Version 9 "vergisst" firefox den Link in Höhe der rotfarbenden Überschrift.
Besonders ärgerlich wird dieser Fehler auf der Startseite http://www.buergerstimmen.de/, weil dort der Banner quasi fast nicht mehr verlinkt ist.
Hat jemand eine Idee für einen Work-Around? Ich habe keine Idee, warum Firefox an der Stelle fehlerhaft arbeitet.
Der Internet-Explorer zeigt hierbei die Seite korrekt an.
Padina
Liebe Mitleserinnen,
liebe Mitleser,
http://www.wegert-buecher.de/privat/brut.html
Mit einem Internet Explorer 5,5 werden die Graphiken auf der Seite einwandfrei dargestellt.
Firefox zeigt dagegen die Graphiken nicht an. Werden die Graphiken verbrannt oder habe ich eine falsche Einstellung beim Firefox gewählt.
Mit besten Grüßen
Padina
Dies ist mir übrigens schon häufiger passiert, dass bestimmte Graphiken nicht angezeigt werden. Dies ist besonders ekelig, wenn die Graphiken für die Navigation wichtig sind.
