Gunther: Browser - permanent neue Versionen, aber immer dieselben Bugs

Hallo zusammen!

Kommt nur mir das so vor, oder hinkt die Beseitigung von vorhandenen Bugs den Veröffentlichungen neuer Versionen stark hinterher?

Insbesondere Mozilla und Google sind ja sehr eifrig, was neue Versionen ihrer Browser angeht. Leider ist das jedes Mal kaum ein Fortschritt, da im Prinzip alle alten Bugs nach wie vor vorhanden sind ...!

Ich meine, es ist ja einerseits schön, wenn neue "Features" implementiert werden. Aber andererseits wäre es noch schöner, wenn man die "angeblich" bereits unterstützten denn dann auch mal verwenden könnte ...!

So schleppt Firefox bspw. seit Ende 2009!!! den Bug im Flexbox Modul mit sich, dass er keine Prozentangaben für Elemente "versteht" - siehe: https://bugzilla.mozilla.org/show_bug.cgi?id=529761

Oder angeblich ünterstützt Safari SVG Grafiken. Tatsächlich hat er bis heute einen Bug bezüglich der Höhe, der eine Verwendung in der Praxis de facto ausschließt (jedenfalls wenn es auch ohne JS "funktionieren soll). Auch dieser Bug ist spätestens seit September 2011 bekannt - siehe: https://bugs.webkit.org/show_bug.cgi?id=68995

Erstaunlicherweise hat Chrome diesen Bug nicht.
Was mich gleich zum nächsten Problem bringt ..., denn gerade bei verschiedenen Browsern, die auf derselben Engine basieren, wird eine "Unterscheidung/ Differenzierung" *ohne* Javascript oder serverseitiges UA Sniffing nahezu unmöglich.

Gerade heutzutage, wo RWD in aller Munde ist, wer braucht da schon die o.g. Features ...!? ;-)

Aber irgendwie drängt sich mir der Eindruck auf, dass alles andere wichtiger ist, als endlich mal die alten (und für Autoren sehr ärgerlichen) Bugs zu beseitigen!

Oder täuscht mich mein Eindruck?
Wie seht ihr das?

Gruß Gunther

  1. Hallo,

    So schleppt Firefox bspw. seit Ende 2009!!! den Bug im Flexbox Modul mit sich, dass er keine Prozentangaben für Elemente "versteht" - siehe: https://bugzilla.mozilla.org/show_bug.cgi?id=529761

    Der Bug müsste auf »Won’t Fix« gestellt werden, weil die neuere Flexbox-Implementierung der W3C Candidate Recommendation den Fehler nicht mehr hat, wie wir festgestellt hatten.

    Grüße,
    Mathias

    1. Hallo,

      So schleppt Firefox bspw. seit Ende 2009!!! den Bug im Flexbox Modul mit sich, dass er keine Prozentangaben für Elemente "versteht" - siehe: https://bugzilla.mozilla.org/show_bug.cgi?id=529761

      Der Bug müsste auf »Won’t Fix« gestellt werden, weil die neuere Flexbox-Implementierung der W3C Candidate Recommendation den Fehler nicht mehr hat, wie wir festgestellt hatten.

      die aber in der Praxis aktuell (noch) nicht zu verwenden ist, da man wohl kaum davon ausgehen kann, dass ein "normaler" User irgendwelche Konfigurationseinstellungen im Browser manuell ändert.

      Und wie wir ebenfalls festgestellt haben, ist eine solche Art der Implementierung äußerst "unglücklich", da man mit reinem CSS keine Chance mehr hat, dem User auf jeden Fall eine "funktionierende" Variante auszuliefern.

      Davon mal abgesehen, muss ich persönlich auch sagen, dass ich immer mehr den Eindruck gewinne, dass Firefox hinter die Konkurrenz zurückfällt.
      Das bezieht sich sowohl auf die Implementierung neuer Features, als auch die Bugfixes. Hier hat Chrome mittlerweile deutlich die Nase vorn. Und wenn das so weitergeht, wird FF demnächst auch noch vom IE überholt ...! :-P

      Und auch die "neue" Flexbox Implementierung im FF ist im Prinzip für die Tonne, da die wesentlichste Geschichte, nämlich 'flex-wrap' nicht unterstützt wird. :-(

      Gruß Gunther

      1. Hi,

        Das bezieht sich sowohl auf die Implementierung neuer Features, als auch die Bugfixes. Hier hat Chrome mittlerweile deutlich die Nase vorn.

        Und bald gibt es sogar ein vernünftiges UI um die Rendering Engine herum! *freu*

        (Ich rede natürlich von Opera.)

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
        1. Hi,

          Das bezieht sich sowohl auf die Implementierung neuer Features, als auch die Bugfixes. Hier hat Chrome mittlerweile deutlich die Nase vorn.

          Und bald gibt es sogar ein vernünftiges UI um die Rendering Engine herum! *freu*

          (Ich rede natürlich von Opera.)

          natürlich! :-P

          Bin mal gespannt, was uns der Wegfall von Presto und die Geburt von Blink dann alles für neue Überraschungen beschert ...! ;-)

          Gruß Gunther

      2. Hallo,

        die aber in der Praxis aktuell (noch) nicht zu verwenden ist, da man wohl kaum davon ausgehen kann, dass ein "normaler" User irgendwelche Konfigurationseinstellungen im Browser manuell ändert.

        Das Feature ist derart versteckt, *weil* es noch nicht fertig ist. Das soll auch kein normaler Nutzer anschalten.

        Und wie wir ebenfalls festgestellt haben, ist eine solche Art der Implementierung äußerst "unglücklich", da man mit reinem CSS keine Chance mehr hat, dem User auf jeden Fall eine "funktionierende" Variante auszuliefern.

        Das alte Flexbox war eine experimentelle Übertragung von XUL-Interna und nie dafür ausgelegt, dass es Websites es verwenden.

        Alte, kaputte, unfertige Flexbox-Implementierungen sind nicht unbedingt ein sinnvoller Fallback für Flexbox CR. Das hat auch niemand behauptet. Ein robuster Fallback wäre eine Lösung mit float, position oder einem elaborierten JavaScript, welches für Flexbox CR aber noch nicht existiert.

        Davon mal abgesehen, muss ich persönlich auch sagen, dass ich immer mehr den Eindruck gewinne, dass Firefox hinter die Konkurrenz zurückfällt.

        Kein Wunder, Microsoft und Google gehören zu den größten IE-Unternehmen der Welt und setzen mittlerweile beide massiv auf die HTML5-Plattform. Mozilla ist ökonomisch gesehen ein Nebenprodukt der Traffic Aquisition von Google. Die Aggressivität, die Google mit Chrome, V8, Blink, Chrome OS und Microsoft mit IE 10 und Metro-Apps an den Tag legt, steht in keinem Verhältnis zu Firefox, Gecko und Firefox OS.

        Mathias

  2. Hallo,

    Kommt nur mir das so vor, oder hinkt die Beseitigung von vorhandenen Bugs den Veröffentlichungen neuer Versionen stark hinterher?

    nein, auch mir kommt es so vor.

    Insbesondere Mozilla und Google sind ja sehr eifrig, was neue Versionen ihrer Browser angeht. Leider ist das jedes Mal kaum ein Fortschritt, da im Prinzip alle alten Bugs nach wie vor vorhanden sind ...!

    ACK.

    Gerade heutzutage, wo RWD in aller Munde ist, ...

    Ist es das? Mir ist Responsive Design ein Begriff, aber die Abkürzung RWD war mir jetzt völlig fremd, ich musste erst mal suchen, was das wohl heißen könnte.

    Aber irgendwie drängt sich mir der Eindruck auf, dass alles andere wichtiger ist, als endlich mal die alten (und für Autoren sehr ärgerlichen) Bugs zu beseitigen!

    Ganz zu schweigen von den alten und für die _Nutzer_ sehr ärgerlichen Bugs.

    Beispielsweise dass Firefox nach längerem Betrieb irgendwann anfängt, Arbeitsspeicher und CPU-Zeit zu beanspruchen, dass es nur so kracht, und dass selbst ein Linux-PC mit 4GB RAM minutenlang nicht mehr bedienbar ist. Das ist AFAIR noch ein Erbe aus Version 2.x, vielleicht sogar noch Version 1. Ich hatte den Eindruck, dass es mit Version 3 etwas besser geworden war, aber das Grundproblem besteht immer noch.

    Oder dass der integrierte Popup-Blocker in der Defaulteinstellung wertlos ist, weil er innerhalb einer 2-Sekunden-Frist nach einem Tastendruck oder einem Mausklick Popups "als Reaktion auf die Benutzer-Interaktion" dennoch zulässt. Liebe Leute, fast alle Popups kommen als Reaktion auf einen Mausklick. Man muss also erst die Liste der Ausnahmen in dom.popup_allowed_events in about:config zurechtstutzen, damit der Popup-Blocker die Bezeichnung verdient.

    Oder dass die angezeigte Übertragungsrate bei längeren Downloads oft um den Faktor 3..5 oder mehr zu hoch liegt, wenn die tatsächliche Transferrate nicht konstant ist. Dann geht Firefox nämlich von den auftretenden Maximalwerten aus und berechnet auch die geschätzte verbleibende Download-Zeit nach diesem Maximalwert anstatt nach dem Durchschnittswert. Da wird aus den angezeigten 2 Minuten gern mal eine Viertelstunde.

    Oder die Reihenfolge, in der die Tabs bei Ctrl-Tab umgeschaltet werden. Normalerweise ist man gewöhnt, mit einfachem Ctrl-Tab vom aktiven Tab A zum letzten vorher aktiven Tab B zu gelangen, und von dort wieder zurück zum zuvor aktiven Tab A. Firefox dagegen geht unabhängig von der z-Ordnung der Tabs stur die Reihenfolge durch.

    Das sind alles Dinge, die man als Nutzer feststellt und die unangenehm auffallen. Fehler oder Versäumnisse in der Engine sind dagegen "nur" für den  wesentlich kleineren Personenkreis der Web-Autoren auffällig, wenn auch zum Teil ebenso ärgerlich. Und das sind Gründe, die mir Firefox als Alltags-Browser verleiden, so dass ich mich im Lauf der Jahre bei Opera besser aufgehoben fühle.

    So long,
     Martin

    --
    Jungs sind wie Waschmaschinen: Wenn man sie anmacht, kommen sie ins Schleudern.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hallo,

      Oder die Reihenfolge, in der die Tabs bei Ctrl-Tab umgeschaltet werden. Normalerweise ist man gewöhnt, mit einfachem Ctrl-Tab vom aktiven Tab A zum letzten vorher aktiven Tab B zu gelangen, und von dort wieder zurück zum zuvor aktiven Tab A.

      »Normalerweise«? Das ist ein untypisches Verhalten für Tabs. Weder in Windows noch bei Mac OS zeigen Standard-Tabs dieses Verhalten.

      Opera unter Windows ist da eine Ausnahme, dort ist es konfigurierbar. Bei Opera unter Mac gibt es Ctrl + Tab, welches die Tabs immer von links nach rechts durchläuft, und zudem Alt + Tab, welches die Tabs in der konfigurierten Reihenfolge durchläuft. Hat wahrscheinlich damit zu tun, dass Tabs in den OS X Human Interface Guidelines entsprechend standardisiert sind.

      Mathias

      1. n'Abend,

        Oder die Reihenfolge, in der die Tabs bei Ctrl-Tab umgeschaltet werden. Normalerweise ist man gewöhnt, mit einfachem Ctrl-Tab vom aktiven Tab A zum letzten vorher aktiven Tab B zu gelangen, und von dort wieder zurück zum zuvor aktiven Tab A.
        »Normalerweise«?

        ja, normalerweise. Weil das Tab-Konzept ja im Grunde nichts anderes ist als eine degenerierte Variante der MDI-Architektur, deren Vorteil gegenüber echtem MDI ich bisher noch nicht erkennen konnte.

        Das ist ein untypisches Verhalten für Tabs. Weder in Windows noch bei Mac OS zeigen Standard-Tabs dieses Verhalten.

        Ich kenne das aber sowohl von echten MDI-Applikationen so, als auch von einigen Windows-Anwendungen, die Tabs verwenden. Beispielsweise mein Lieblingseditor unter Windows PNP.

        Opera unter Windows ist da eine Ausnahme, dort ist es konfigurierbar.

        Opera implementiert auch die MDI-Architektur noch vollständig, man kann Tabs/Dokumentfenster auch beliebig anordnen oder minimieren.

        Opera unter Linux verhält sich auch so, wie ich beschrieben habe. Dass das konfigurierbar ist, war mir nicht bewusst; ich kann mich nicht erinnern, diesbezüglich etwas eingestellt zu haben. Vermutlich meinst du das:

        When cycling through tabs with Ctrl-Tab
          Cycle in recently used order

        AFAIR war das aber von Haus aus "richtig" eingestellt.

        Bei Opera unter Mac gibt es Ctrl + Tab, welches die Tabs immer von links nach rechts durchläuft, und zudem Alt + Tab, welches die Tabs in der konfigurierten Reihenfolge durchläuft. Hat wahrscheinlich damit zu tun, dass Tabs in den OS X Human Interface Guidelines entsprechend standardisiert sind.

        Das ist gut möglich.

        Ciao,
         Martin

        --
        Ich denke, also bin ich hier falsch.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(