Entwicklung Firefox

    Ja, der Schalter ist bereits in Firefox 55 da, aber Stylo wird in Firefox 55 nicht mit kompiliert - außer du kompilierst Firefox 55 selbst und aktivierst vorher das Build-Flag. ;)

    Dass Stylo vor einigen Wochen noch spürbar langsamer war, ist keine Überraschung, da es ja erst einmal darum ging, Stylo soweit zu bekommen, alle Web-Features zu implementieren, so dass alle Webseiten korrekt dargestellt werden. Performance-Optimierungen kommen jetzt, nachdem mittlerweile (fast) alles korrekt dargestellt wird. Teilweise ist Stylo auch schon schneller, das kann man auf Twitter feststellen [1].

    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25

    Das war auch nicht als Kritik gemeint, ich wollte nur kurz erläutern weshalb der Test sinnvoll gewesen wäre, wäre Stylo schon mitdrin gewesen :)
    Das AOF auf Custom Builds setzt nehme ich aufgrund des Posts nicht an, aber ja so wäre es schon vorher möglich gewesen.

    Also laut einem Platform Engineer bei Reddit ist das schon ziemlich wichtig:
    Oh boy, you have no idea how much we're waiting for 57 as well! My favorite part is all the stuff we'll finally be able to remove - https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

    That may not sound as shiny as new features, but that's *a lot* of code that we have to maintain for years now because some extension, out there, is using it and has never been updated.

    With 57 we can finally start removing all this code and seriously clean up the codebase. #littlethingsthatgetdevsexcited

    Ja Mozilla hat noch viel XUL im Code und es soll ja auch Experiments geben aber das dürfte wesentlich leichter zu verwalten sein als wenn es für jedes Addon offen stehen muss.

    Zitat von Lurtz


    Am 2. August ist Merge Day. Es werden dann relativ schnell viele Legacy-Addons in der Nightly kaputt gehen, da viel Code entfernt werden wird: https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

    "post-57" heißt auf Deutsch "nach Firefox 57", also Nightly 58 und danach. Im Entwicklungszyklus von Firefox 57 liegt der Fokus darauf, Firefox 57 fertig zu bekommen. Code-Entfernungen kommen meistens erst, nachdem der Code nicht mehr verwendet wird, zumal sowas immer ein erhebliches Risiko mit sich bringt, weswegen zwischen Deaktivierung und Entfernung eines Features fast immer mindestens eine Firefox-Version liegt. Alles andere wäre schon aus Sicht eines vernünftigen Release Managements schlecht. So kann auch das danach Zitierte verstanden werden: im Sinne von "sobald Firefox 57 ausgeliefert ist, können wir die alten Sachen aus Firefox entfernen". Vor allem ist auch alleine die Umsetzung aller Abhängigkeiten dieses Meta-Tickets eine Sache von Wochen, wahrscheinlicher sogar Monaten. Da legt niemand einen Schalter mit dem Merge-Day um und dann sind die ganzen Sachen plötzlich weg. Auch die Entfernung erfordert einen nennenswerten Aufwand.

    Zitat von Sören Hentzschel

    "post-57" heißt auf Deutsch "nach Firefox 57", also Nightly 58 und danach. Im Entwicklungszyklus von Firefox 57 liegt der Fokus darauf, Firefox 57 fertig zu bekommen. Code-Entfernungen kommen meistens erst, nachdem der Code nicht mehr verwendet wird, zumal sowas immer ein erhebliches Risiko mit sich bringt, weswegen zwischen Deaktivierung und Entfernung eines Features fast immer mindestens eine Firefox-Version liegt. Alles andere wäre schon aus Sicht eines vernünftigen Release Managements schlecht. So kann auch das danach Zitierte verstanden werden: im Sinne von "sobald Firefox 57 ausgeliefert ist, können wir die alten Sachen aus Firefox entfernen". Vor allem ist auch alleine die Umsetzung aller Abhängigkeiten dieses Meta-Tickets eine Sache von Wochen, wahrscheinlicher sogar Monaten. Da legt niemand einen Schalter mit dem Merge-Day um und dann sind die ganzen Sachen plötzlich weg. Auch die Entfernung erfordert einen nennenswerten Aufwand.


    Bei dem Platform Engineer klingt das aber gerade ganz anders:
    [Blockierte Grafik: https://abload.de/img/unbenanntzws9g.jpg]

    Nichts mit Warten bis Firefox 57 fertig ist. Zumindest einzelne Teile von XPCOM werden sehr schnell aus der Nightly verschwinden.

    .. ich lese daraus, das er innerhalb 1 Woche nach dem Erscheinen von Firefox 57.0 mit dem Code rausschreiben beginnen möchte....

    Zitat von Lurtz


    Nichts mit Warten bis Firefox 57 fertig ist.

    Deine Schlussfolgerung wäre dann nicht korrekt.. :wink:

    Das Problem ist, dass hier zwei Themen durcheinander gehen, die definitiv miteinander zu tun haben, aber nicht das Gleiche sind. Lass mich versuchen, das zu erklären:

    Ich beziehe mich auf das verlinkte Bugzilla-Ticket, in dem es darum geht, was alles nach dem Erscheinen von Firefox 57 aus Firefox entfernt werden kann. Aber das alles bis zum Erscheinen von Firefox 57 zu entfernen ist überhaupt nicht zu schaffen und würde zusätzlich die Ressourcen binden, die für die anderen Projekte erforderlich sind, die für Firefox 57 geplant sind.

    Der Kommentar, den du gerade als Screenshot eingestellt hast, der bezieht sich auf die Kompatibilität von Legacy Add-ons und dass diese schon sehr bald nicht mehr funktionieren. Das ist nicht das Thema in dem verlinkten Bugzilla-Ticket. Die Nicht-Unterstützung von Legacy-Erweiterung ist die Voraussetzung dafür, dass die Abhängigkeiten des verlinkten Tickets, also die Entfernung des Codes, überhaupt erst einmal begonnen werden kann. Und wie gesagt, in dem Ticket steht ja auch "post-57". ;)

    Also zusammengefasst: Nicht-Unterstützung von Legacy-Erweiterungen: sehr früh im Nightly-57-Zyklus. Abhängigkeiten des Tickets "Bug 1347507 - Stuff we can remove when XPCOM extensions are no longer supported" aka Entfernung von Code: ab dann nach und nach, aber nicht mit einem bestimmten Stichtag, das wird sich über Monate ziehen, das alles zu entfernen, da gibt es ja keinen magischen Knopf für.

    Im Endeffekt ist das auch gar nicht wichtig. Deine Aussage war in Bezug auf den Merge-Day: "Es werden dann relativ schnell viele Legacy-Addons in der Nightly kaputt gehen" und das stimmt eh. Das aber eben unabhängig von Ticket 1347507, für die Nicht-Unterstützung gibt es tatsächlich eine Einstellung, die Mozilla nur umkippen muss: extensions.legacy.enabled - das ist ähnlich wie mit der Signierung von Erweiterungen: auch dieser Schalter hat nur in Nightly-Versionen von Firefox einen Effekt, nicht in Beta- oder finalen Versionen. Und sind die Legacy-Erweiterungen deaktiviert, kann sich Mozilla die Zeit nehmen, die es eben braucht. ;)

    Ich lese das aus dem Posting von zbraniecki anders raus, aber es ist müßig jetzt darüber zu diskutieren, wir werden es bald sehen. Er spricht da ganz unabhängig von dem Schalter davon, dass er den Code, für den er zuständig ist, so bald wie möglich im Nightly 57-Zyklus entfernen wird.

    Kann natürlich sein dass er sich missverständlich ausgedrückt hat, aber da er explizit einen Beitrag zitiert, in dem der Schalter extensions.legacy.enabled als "Lösung" erwähnt wird, halte ich das für sehr unwahrscheinlich.

    Der Schalter ist sowieso keine Lösung für irgendjemanden, der meint, damit noch länger Legacy-Erweiterungen nutzen zu können, da vollkommen klar ist, dass Mozilla das SDK und andere für Legacy-Erweiterungen relevante Teile entfernen wird und das eher früher als später. Mir ging es um die Unterscheidung, dass die Deaktivierung der Unterstützung von Legacy-Erweiterungen und die Entfernung des Codes zwei unterschiedliche Paar Schuhe sind, und um die korrekte Abhängigkeit. Legacy-Erweiterungen werden, wie du schon richtig sagst, vermutlich früh im Nightly 57-Zyklus nicht mehr funktionieren. Aber eben ganz klar nicht wegen Bug 1347507, sondern weil Mozilla vorher den Schalter umlegen wird. Ist der Schalter umgelegt, ist alles, was im Rahmen von Bug 1347507 geschieht, für den Nutzer eh nicht mehr spürbar, weil die Add-ons dann bereits nicht mehr funktionieren. ;)

    Wenn diese beiden Erweiterungen in der aktuellen Nightly-Version nicht funktionieren, hat das sicher eine andere Ursache, da das Firefox 56 betreffen würde. "Es geht schon los" stimmt also wahrscheinlich nicht in Bezug auf das vorherige Thema. Wahrscheinlicher ist für mich ein unerwünschter Effekt einer der Performance-Verbesserungen, wo ja viel daran geändert wird, wann und auf welche Weise Code geladen wird. Ich nutze weder die eine noch die andere Erweiterung. Ich schlage vor, mozregression zu nutzen, um die Ursache zu finden und das Problem zu melden. Dem Beitrag von gorhill kann entnommen werden, dass er sich nicht um die Ursachen-Findung kümmern wird. Aber Mozilla hat definitiv nicht vor, die Kompatibilität bereits in Firefox 56 zu brechen. Mozilla hat es zwar eilig, aber bis Firefox 57 warten sie schon. ;)

    In den Kompatibilitäts-Hinweisen für Firefox 56 [1] steht auch nichts, was diese Auswirkung hätte, ist also auch demnach keine geplante Änderung für Firefox 56 (natürlich unter der Annahme, dass nichts vergessen wurde, was grundsätzlich natürlich möglich ist).

    [1] https://blog.mozilla.org/addons/2017/07…ity-firefox-56/