1. Nachrichten
  2. Forum
    1. Unerledigte Themen
    2. Forenregeln
  3. Spenden
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. camp-firefox.de
  2. Alkaloid

Beiträge von Alkaloid

  • preventDefault() Bug

    • Alkaloid
    • 27. Juli 2014 um 15:26

    Palli: Ich sehe die Situation ein bischen anders. Ich habe ein Problem festgestellt, das nur mit FF auftritt, und ich habe mit die Zeit genommen und dem Aufwand spendiert, die FF-Entwicklung davon zu informieren. Dort ist man nicht kooperativ. Nicht ich habe eine Lösung zu suchen, sondern die FF-Entwicklung muss das tun. Oder auch nicht.

    Ich suche bei Problemen mit meinen Programmen auch selbst nach Lösungen und erwarte nicht, dass der Problemmelder dies tut. Und es ist mein Interesse, die Probleme meiner Programme zu beheben. Eine ähnliche Haltung erwarte ich auch von anderen Entwicklern.

    Ich habe zwar Interesse, dass meine Programme mit so vielen Browsers wie möglich funktioneiren, aber das interesse geht in diesem Fall nicht so weit, dass ich mich weiter engagiere (von den 10.000 unique visitors meiner Site verwendet nicht einmal 1% mobile FF!).

    "wäre es möglich auf Webseiten, die das Attribut nutzen, die Adressleiste zwangsweise immer Einzublenden?" -- Das funktioniert nicht. preventdefault() ist keine globale Funktion, sondern wird bei jedem einzelnen Event aufgerufen - oder auch nicht. Ich verwender preventDefault() beispielsweise nur bei den Tastenkombinationen, die ich auswerte; alle andere lasse ich ohne preventDefault() durch. Dazu zählen beispielsweise alle ALT-Tastankombinationen, die eine Seite dann in Formularen oder anderweitig verwenden kann.

    "Wenn du als Argument eine fehlerhafte Standardeinbindung bringst, dann beeindruckt das schon." -- Bisher jedenfalls nicht. Keine Reaktion auf das Argument.

    So, das war's dann, von meiner Seite. Der Mohr hat seine Schuldigkeit getan, der Mohr kann gehn. [geht ab.]

  • preventDefault() Bug

    • Alkaloid
    • 27. Juli 2014 um 12:28

    "Kann ich nicht nachvollziehen": So schaut bei mir die Adresszeile aus, in Firefox:
    [attachment=0]Screenshot_1.jpg[/attachment]
    Da ist nix von einer ID! Ich habe einfach in der Bugzilla-Mail auf den Link geklickt.

    "Jetzt bleib aber mal auf dem Teppich":
    http://gs.statcounter.com/#browser-ww-weekly-200827-201327

    Aber egal auch. Ich nehme den Vergleich zurück. Wie auch immer, Abhilfe gibt es keine. Das ist alles was zählt.

    Bilder

    • Screenshot_1.jpg
      • 15,95 kB
      • 689 × 220
  • preventDefault() Bug

    • Alkaloid
    • 27. Juli 2014 um 08:49

    Schlechte Neuigkeiten: FF weigert sich, den Bug zu beheben: WONTFIX.

    Dabei widerspricht das Verhalten ganz klar der Spezifikation:
    https://developer.mozilla.org/en-US/docs/Web….preventDefault

    "Calling preventDefault during any stage of event flow cancels the event, meaning that any default action normally taken by the implementation as a result of the event will not occur."

    Nochmal mit Betonung: ANY.

    In allen anderen Browsern auf Android, die ich probiert habe (Chrome, Opera, Android) funktioniert preventDefault spezifikationsgemäß.

    Mir bleibt nur, meinen Besuchern zu raten, die Titelleiste einzuschalten oder einen anderen Browser zu verwenden. :(

    [Nein, ich halte nichts davon, auf FF einzuschlagen, aber WONTFIX ist einer der Gründe, die zum Niedergang von IE geführt haben. Geschichte wiederholt sich. Leider.]

    BTW: Kann leider keinen Link auf den Bug Report setzen, weil es dazu keine vernünftige URL gibt; alle Reports werden unter der gleichen URL (https://bugzilla.mozilla.org/process_bug.cgi) angezeigt. Der wahre Geist des Webs ist das auch nicht.

  • preventDefault() Bug

    • Alkaloid
    • 26. Juli 2014 um 08:47

    Bugzilla# 1044370

  • preventDefault() Bug

    • Alkaloid
    • 26. Juli 2014 um 08:15

    Ich hatte eigentlich gehofft, dass die Meldung hier ausreicht ... ok, werde ich tun.

  • preventDefault() Bug

    • Alkaloid
    • 25. Juli 2014 um 11:24

    Aber ja, kein Problem: http://www.janko.at/Raetsel/Nurikabe/021.a.htm

    a) Einstellungen -> Ansicht -> Titelleiste ein -> ok
    b) Einstellungen -> Ansicht -> Titelleiste aus -> Fehler

    Einfach mal ein weißes Feld nach unten oder nach oben ziehen. Oder ein Feld durch Tippen schwärzen und dann nach unten/oben ziehen.

    Nachtrag: stopPropagation() wird natürlich auch aufgerufen, hat aber eigentlich mit dem Browser nichts zu tun.

    Android 4.4 mit FF 31 auf Nexus 7 (2012)

  • preventDefault() Bug

    • Alkaloid
    • 25. Juli 2014 um 10:54

    Ich habe ein HTML5 Canvas, das Maus/Touch-Events bearbeitet und mit preventDefault() verhindert, dass FF (Version 31) die Maus/Touch-Events selbst interpretiert (z.B. die Seite scrollt). Funktioniert in Chrome und Opera problemlos. Funktioniert in FF nur dann, wenn die Adresszeile *immer* eingeblendet ist.

    Wenn die Adresszeile ausblendbar ist, führt eine vertikale Bewegung in jedem Fall zum Ein/Ausblenden der Adresszeile, was zur Folge hat, dass die Seite scrollt (trotz preventDefault) und das Canvas damit unbedienbar wird. (Das ist wie wenn man versuchen würde, mit einem Bleistift auf ein Papier einen Kreis zu zeichnen, das Papier sich aber unter dem Bleistift bewegt.)

    Kennt jemand eine Abhilfe?

  • Verknüpfungs-Icons bei FF18

    • Alkaloid
    • 10. Januar 2013 um 16:34

    "Möchtest du nur Jammern, geh ne Runde ums Haus, Joggen oder Enten füttern - das interessiert hier niemanden." -- Möchstest Du flegeln? Das interessiert hier hoffentlich auch niemanden. Aber es gibt immer Leute mit Knick in der Optik, die nicht sehen (wollen), dass ich eine komplette Fehleranalyse genacht habe und auch die Motivation dargestellt habe, warum das Problem für mich gravierend ist.

    ESR ist keine Lösung, wie mein Vorschreiber schon dargestellt hat.

    Abgesicherter Modus ist auch keine Lösung, schließlich möchte ich nicht ohne Add-Ons wie Noscript oder Cookie Manager auskommen.

    So, und nun verabschiedet sich der Jammerer wieder aus diesem Forum und dankt für die freundliche Aufnahme!

  • Verknüpfungs-Icons bei FF18

    • Alkaloid
    • 10. Januar 2013 um 09:53

    Habe noch ein bisschen rumgespielt. Wenn man aus einer .url die Icon-Zeile löscht passiert gar nichts, weiterhin wird das WIndowsDefault-Icon angezeigt. Das ist dem Icon-Cache von Windows geschuldet. Wenn man die .url unter einem anderen Namen zurückschreibt hat an das FF-Icon wieder.

    Das gleiche habe ich auch mit einem Wikipedia-Link gemacht. Überraschung: Nach dem Löschen der Icon-Zeile in der .url wurde das Wiikepdia-Favicon angezeigt! Vermutung: Ich habe irgendwann mal mit IE einen Wikipedia-Link angelegt, IE hat das Favicon irgendwo gespeichert und der Icon-Manager von Windows hat es gefunden und verwendet. Die Lösung ist intelligent und sexy: Wenn das favicon verloren geht oder nicht vorhanden ist (z.B. weil der Link auf einen anderen Rechner verschoben wurde), wird das Standard-Browser-Icon angezeigt (und nicht das Windows-Default-Icon); anderenfalls das favicon.

  • Verknüpfungs-Icons bei FF18

    • Alkaloid
    • 10. Januar 2013 um 08:46

    Mag ja sein, Teufel oder Beelzebube. Warum bleiben denn sie viele Leute bei XP, trotz der schlechteren Security? "Du musst wegen Security eh umsteigen, da brauchen wir die Fehler ja nicht zu beheben" ist eine schlechte Strategie. Vielleicht sollte Moz aus dem Vista-Debakel lernen. Oder dem Debakel mit den inkompatiblen Plugins. Oder dem sinkenden Marktanteil. Security ist eben *nicht* alles.

    PS: Ich lege pro Tag berufsbedingt mindestens 100 Web-Adressen in diversen Verzeichnissen ab - nur um mal die Größenordnung zu verdeutlichen. Es geht nicht darum, hin und wieder mal ein Icon zu reparieren.

    PPS. Kann man die favicons nicht irgendwie ausschalten? Würden bei mir sowieso nicht funktionieren, weil die Links zwischen verschiedenen Rechnern geshared werden und die favicons auf anderen Rechnern sowieso nicht vorliegen. (Das Ganze ist eine Fehlkonstruktion.)

    EDIT: Die Nicht-Ablage der Icons in der .url Datei hat noch den Vorteil, dass ich das FF-Icon sehe, mein IE-Kollege das IE-Icon, mein Opera-Kollege das Opera-Icon usw. Jeder nach seinen Vorlieben.

  • Verknüpfungs-Icons bei FF18

    • Alkaloid
    • 10. Januar 2013 um 07:52

    Danke für den Link. Hilft aber nicht wirklich, da man ja jeden neuen Link manuell reparieren muss. Das Script tut auch nichts anderes als die Icon= Zeilen aus der .url Datei zu löschen (das kann man auch mit jedem Tetxteditor tun).

    Interessant auch, dass das Problem schon mit FF17 auftritt und in FF18 noch nicht behoben wurde, obwohl es doch sehr störend ist. Nun ja, bleibe ich bei FF16 :(

  • Verknüpfungs-Icons bei FF18

    • Alkaloid
    • 9. Januar 2013 um 22:49

    Hat die entsprechende Seite denn ein Favicon? -- nein. Ich hab's eben auch mit Webseiten mit favicon probiert, gleicher Effekt (d.h. statt des favicons pder des FF-Icons wird das Default-Icon angezeigt). Und wenn ich die Antwort richtig vestehe, müsste ab FF17 ja das favicon angezeigt werden und nicht das Windows-Default-Icon.

    Anbei ein Beispiel, wie ein Link auf die Wikipedia aussieht (das favicon der Wikipedia ist ein "W").

    Bilder

    • wp-icon.jpg
      • 1,92 kB
      • 71 × 64
  • Verknüpfungs-Icons bei FF18

    • Alkaloid
    • 9. Januar 2013 um 22:15

    Ich bin eben von FF16 auf FF18 umgestiegen. Bei FF16 alles ok, bei FF18 werden falsche Verknüpfungsicons angezeigt.

    Wenn man eine URL auf den Desktop zieht, erzeugt man so eine Internet-Verknüpfung. In FF16 wird das FF-Icon angezeigt, bei FF18 ein Standard-Icon, das Wiendows immer dann anzeigt, wenn Windows kein anderes findet. Dies deshalb, weil FF18 in die .url-Datei folgende Einträge schreibt:

    ► [InternetShortcut]
    ► URL=http://de.wikipedia.org/
    ► HotKey=0
    ► IconFile=C:\Dokumente und Einstellungen\ich\Lokale Einstellungen\Anwendungsdaten\Mozilla\Firefox\Profiles\uc51524i.default\shortcutCache\tCEVMz4l96bm+KVtk5DDIQ==.ico
    ► IconIndex=0

    Das ist unabhängig davon, ob die Website ein favicon zur Verfügung stellt oder nicht. Die Datei "tCEVMz4l96bm+KVtk5DDIQ==.ico" enthält Schrott. In FF16 sieht die .url-Datei noch so aus:

    ► [InternetShortcut]
    ► URL=http://de.wikipedia.org/

    (und sonst nichts, die Icon-Einträge fehlen richtigerweise). Die Registry-Einträge sind in Ordnung und wenn ich auf FF16 zurückgehe werden auch wieder korrekte .url-Dateien angelegt.

    Weiß jemand Rat?

Unterstütze uns!

Jährlich (2025)

92,9 %

92,9% (604,17 von 650 EUR)

Jetzt spenden
  1. Kontakt
  2. Datenschutz
  3. Impressum
Community-Software: WoltLab Suite™
Mastodon