Firefox 57 aneb Firefox Quantum je v betaverzi

Mozilla.cz informuje, že nový Firefox 57, nazývaný také Firefox Quantum, je už týden v betaverzi. Michal Stanke se v článku věnuje uživatelskému rozhraní, rychlosti i spotřebě paměti. Zveřejněno bylo oficiální video s porovnáním rychlostí vykreslování vybraných webů ve Firefoxu Quantum a v Google Chrome. K vytvoření videa byl použit open source projekt WebPagetest. Dle plánů by měl Firefox 57 aneb Firefox Quantum vyjít 14. listopadu.

2.10.2017 23:22 | Ladislav Hagara | Zajímavý článek

Komentáře

[ekant]

Je to ficak, chrome u mna konci, treba vyskusat...

[mica]

Já na rozdíl od jiných věčných nespokojenců chápu (ač tomu příliš nerozumím), že způsob, jakým byla XUL rozšíření zakomponována do prohlížeče, omezovala možnosti vývoje samotného jádra a že pokud Mozilla prováděla modernizační úpravy jádra, nutně to muselo vést k narušení funknčnosti jisté množiny rozšíření. Takže vytvoření rozhraní (API) pro rozšíření nezávislého na jádru bylo logickým a nezbytným řešením. Bohužel tím ovšem (kvůli omezeným možnostem nového API) za své vezme tradiční značná uzpůsobitelnost Firefoxu, jež byla mezi ostatními prohlížeči jedinečná, a už se zřejmě nikdy nevrátí, což je velká škoda. Pokud jde o doplňky, zatím mám ve Firefoxu (verze 56) 16 rozšíření, z nichž se mi do instalace zkušební verze 57 podařilo najít náhradu asi za 95% z nich. Ty zbývající mi nezbývá než oželet, nicméně vážnou překážkou pro mě je, že rozšíření pro úložiště MEGA (nezbytné pro manipulaci s velkými soubory) pro Firefox existuje jen ve verzi pro XUL a z toho důvodu zatím neplánuju používat Firefox 57 jako hlavní prohlížeč. Tolik má zkušenost s přechodem z hlediska rozšíření.

Nicméně musím říct, že jsem poněkud zklamaný i z přístupu Mozilly k přizpůsobitelnosti vzhledu prohlížeče. Ať si kdo chce o takovém postoji myslí, co chce, nemám rád, když se ovládací rozhraní programu výrazněji mění. A tak když Mozilla přišla s rozhraním Australis, v němž byl adresní řádek pod oušky panelů, ihned jsem nainstaloval rozšíření Classic Theme Restorer, abych mohl adresní řádek vrátit zase nahoru, kde tradičně býval. Jenže Classic Theme Restorer ve verzi 57 přestane fungovat. Přesto jsem zjistil, že povrtáním se ve vnitřnostech Firefoxu lze i od verze 57 docílit polohy adresního řádku nahoře. Technicky to tedy možné je, ale běžnému uživateli (který chce jen přetahovat myší a ne vrtat se v konfiguračních souborech) tato změna vzhledu přesto není umožněna. A já se ptám, proč. Kde je to staré heslo "přizpůsobte si prohlížeč svým potřebám"? To už Mozilla rezignovala na to, co pro Firefox bylo typické? Mně připadá, že si Mozilla myslí, že nejlepší machři světa na ergonomii přišli na to, že adresní řádek musí být jedině pod oušky panelů, a já jakožto hloupý uživatel, který tomu nerozumí, nesmím mít možnost to změnit, protože bych si tím ještě mohl ublížit. A že ostatní prohlížeče to mají právě tak, pro mě není omluva, protože ty nikdy neměly tradici široké přizpůsobitelnosti. Sice přiznávám, že se mi verzi 57 povedlo dostat do téměř totožného vzhledu, jaký mám ve standardně nainstalované verzi 56, takže bych si vlastně nemusel stěžovat, ale stejně se mi zdá (i z jiných důvodů, než jsem napsal), že Mozille na dřívější značné upravitelnosti rozhraní Firefoxu už tolik nezáleží.

[Martin Stransky]

A tak když Mozilla přišla s rozhraním Australis, v němž byl adresní řádek pod oušky panelů, ihned jsem nainstaloval rozšíření Classic Theme Restorer, abych mohl adresní řádek vrátit zase nahoru, kde tradičně býval. Jenže Classic Theme Restorer ve verzi 57 přestane fungovat. Přesto jsem zjistil, že povrtáním se ve vnitřnostech Firefoxu lze i od verze 57 docílit polohy adresního řádku nahoře. Technicky to tedy možné je, ale běžnému uživateli (který chce jen přetahovat myší a ne vrtat se v konfiguračních souborech) tato změna vzhledu přesto není umožněna. A já se ptám, proč.

Z vlastni zkusenosti prispevatele myslim ze to je dano jednak omezenymi zdroji (vsechny volne ruce se v soucastnosti venuji ladeni a opravam bugu v FF57) a malou poptavkou po teto konkretni uprave.

Podivejte se na: https://addons.mozilla.org/cs/firefox/addon/classicthemerestorer/

stranka rika 325 306 uživatelů. Celkovy pocet uzivatelu Firefoxu je priblizne v radech stovek milionu (kolem 500 co si pamatuju). Podle techto udaju je tato zmena atraktivni asi pro 0.16% vsech FF uzivatelu. Rekneme si na rovinu, neni to zrovna mnoho :)

[mica]

No, možná na tom něco je, ale skutečně se každá nová změna rozhraní zavede až poté, co se zjistí v anketě, kolik lidí si takovou změnu přeje? Co když lidem prostě bylo něco vnuceno a spoléhalo se na to, že se s tim smíří?

[Michal Kubeček]

To zní věrohodně… ale jen do chvíle, kdy si vzpomenu, jak se s velkou slávou ("vidíte, není se čeho bát") rozšiřovalo API kvůli rozšíření, které má oproti Classic Theme Restorer uživatelů méně než třetinu.

[j]

Az na to, ze XUL nema s prohlizecem spolecnyho prakticky vubec nic. Je to totiz jenom API a nic jinyho, stejne jako kterykoli jiny API. Paradni na tom bylo prave to, ze cast vlastni funcionality browseru byla resena prave pres XUL. Tudiz se znacna cast fungovani browseru dala uplne stejne pres to XUL zmenit.

Nema to zhola nic spolecnyho ani s vykonem, ani s paralelizaci ani s nicim podobnym. A samozrejme, pokud muzes zasahovad do chovani brwseru, muzes delat veci kaly i nekaly, uplne stejne jako to muzes delat ... trebas pomoci DRM blobu ... kterej soudruzi v chrozille nadsene prifarili.

[Kate]

XUL je API. Jasně. Asi tak jako HTML nebo Qt Quick.

[oryctolagus]

Az na to, ze XUL nema s prohlizecem spolecnyho prakticky vubec nic. (...) Nema to zhola nic spolecnyho ani s vykonem, ani s paralelizaci ani s nicim podobnym.

No něco musí ten XUL obsah renderovat. Což je dost podobná úloha jako renderování HTML a jeho stylování, takže bych očekával, že tam určitě bude minimálně nějaký společný kód s prohlížečem (minimálně právě třeba CSS engine). A že XUL aplikace trpí špatným výkonem je celkem známo už roky. Vůbec se nedivím Mozille, že hodily XUL přes palubu, vzhledem k tomu, že dělá v podstatě to samé co HTML + CSS + JS, akořát hůř.

[Michal Kubeček]

A že XUL aplikace trpí špatným výkonem je celkem známo už roky.

Známo to možná je, ale nevzpomínám si, že bych někdy viděl nějaké věrohodné vysvětlení, proč by to měl být principiální problém XUL jako takového a ne jen neefektivita konkrétní implementace.

[oryctolagus]

Nejsem si jistej, je možné, že tam budou principielní důvody jako třeba XPCOM (ie. místo přímého bindingu JS ↔ nativní kód se AFAIK při použití XPCOMu více marshalluje). Ale je klidně možné, že to je také nebo i z většiny způsobeno neefektivní implementací. Nepřijde mi ale, že by se tím na věci něco měnilo - proč se snažit zefektivnit engine, který v podstatě duplikuje funkcionalitu druhého enginu, který je k dispozici hned o kousek vedle v tom samém programu a je už tak jako tak efektivnější?

[Michal Kubeček]

Třeba proto, aby Firefox nepřipravili o tu největší výhodu, kterou dosud měl.

[oryctolagus]

Což je co?

(Za mě největší výhoda FF je, že to je použitelný FOSS prohlížeč, který není od Googlu ani Applu.)

[Michal Kubeček]

Obrovské množství rozšíření, na které jsou uživatelé zvyklí.

[oryctolagus]

Když jsem ještě používal FF, bylo relativně časté, že s novou verzí přestalo fungovat pár rozšíření. A s TB, které používám dodnes, to je podobné, nedávno jsem měl problém s Conversations. Mj. právě z tohohle důvodu jsem se snažil z toho "obrovského množství rozšíření" jich používat co nejméně...

Ale chápu, že někomu to asi vadit bude. Je to tradeoff jako každý jiný a porušení zpětné kompatibility vždycky někoho naštve...

[Michal Kubeček]

Nejde o naštvání, ale o pragmatické zhodnocení. Vidím prohlížeč, který se snaží v čím dál větší míře imitovat jiný, který se mi nelíbí. Vidím prohlížeč, který v té imitaci jde tak daleko, že dobrovolně zahazuje hlavní výhodu, kterou proti tomu druhému má. A konečně vidím prohlížeč, jehož vývojáři se rozhodli podstatnou část přepsat do nějaké Yet Another Cool Language, čímž značně zkomplikovali build a packaging, protože vytvořili závislost na pohyblivém cíli (nestačí totiž YACL, je potřeba co nejnovější verze překladače YACL). Viz bugzilla:

> Do you really expect distributions to constantly
> update to the latest git snapshot of the Rust compiler just because they are
> updating their Firefox package?

The latest stable distribution, not the latest git snapshot. Rust has a stable release every six weeks.

Doufám, že absurdita té odpovědi a mimoňství toho, kdo ji napsal, jsou dost zjevné bez obšírného vysvětlování.

Těch signálů, že o mne nestojí, je prostě už příliš mnoho. Překousl jsem toho hodně, ale Firefox 57 a nekompromisní odstřelení velké části rozšíření (včetně CTR, který je pro mne z kategorie "must have") je ta poslední kapka.

[oryctolagus]

Doufám, že absurdita té odpovědi a mimoňství toho, kdo ji napsal, jsou dost zjevné bez obšírného vysvětlování.

K tomu YACL: Souhlasím, že k balíčkování/distribucím ten přístup není kdovíco, moc se mi nelíbí. Např. podpora system-wide shared objectů je dost na vlastní pěst. (Což je IMHO průser, který nikdo moc neřeší.)

Na druhou stranu, není tím, co chceš ESR verze FF? Ty 'rapid' verze mají podporu koneckonců ~měsíc, to mi přijde spíše vhodné pro distra jako Arch a podobně. V tom bugu taky píšou, že trackovat každou novou stable verzi rustc není dlouhodobý záměr.

Co se týče podpory této YACL na platformách, příležitostně se tomu snažím pomoci. Např. jsem před časem fixnul socket API na illumos/Solaris a aktuálně se snažim vylepšit pár drobností na *BSD. Ono dát to všechno do kupy není až taková sranda, ti lidi nevytvářejí schválně problémy Michalu Kubečkovi, ale snaží se to celé ukočírovat a něco se daří, něco méně.

Těch signálů, že o mne nestojí, je prostě už příliš mnoho. Překousl jsem toho hodně, ale Firefox 57 a nekompromisní odstřelení velké části rozšíření (včetně CTR, který je pro mne z kategorie "must have") je ta poslední kapka.

Hm, a jaký z toho vyvodíš důsledek? Nebylo by skoro jednodušší dát novému FF šanci? Ale samořejmě udělej co uznáš za vhodné...

[Michal Kubeček]

Mně hlavně přijde absurdní, že někdo vůbec může napsat o překladači "vydáváme stable verzi každých šest týdnů" a myslet to vážně. Ještě absurdnější mi pak přijde použít takový překladač a jazyk v podstatné míře pro projekt používaný (jak sám uvádíte) stovkami milionů lidí a ještě ke všemu s tím, že se budou využívat nové featury toho jazyka, ještě než na nich uschne barva. Možná ze mne mluví čtyři roky v L3, ale tohle prostě považuji za nezodpovědnost.

Na druhou stranu, není tím, co chceš ESR verze FF?

Částečně a navíc by to stejně bylo jen dočasné řešení. Než začali blbnout s rustem, bez problémů jsem si balil snapshoty přímo z mercurialu a v předstihu jsem tak věděl, na jakou jobovku se zase připravit. Rustifikovaný firefox se mi ještě zabalit nepodařilo, protože rust sice k něčemu (link?) potřebuje gcc, ale musí to být aspoň gcc5 a rust ignoruje standardní proměnné prostředí, takže se mi nepodařilo mu vysvětlit, že místo "gcc" má volat "gcc-5.0" (ale je pravda, že jsem to vzdal už někdy začátkem prázdnin, takže to třeba opravili). A asi to nebude jen mojí neschopností, protože maintainer openSUSE balíčku je z toho nešťastný úplně stejně.

Stejně jako nevěřím v "distribuční turistiku", nevěřím ani v nové supergeniální jazyky, které spasí svět. Když jsem se učil programovat, byl populární názor, že klasické jazyky už to mají spočítané a do roku 2000 se všechno podstatné bude dělat v Prologu. Dnes už asi můžeme celkem bezpečně zhodnotit, že tahle vize se tak úplně nenaplnila. Od té doby jsem podobná prohlášení slýchal od věrozvěstů různých dalších jazyků a koncepcí (koneckonců se stačí podívat na diskuse na téma "programovací jazyky" tady na ABCLinuxu), ale C a C++ jsou tady pořád a i když neumím haskell, erlang, go ani rust (a nehodlám na tom nic měnit), o práci se nebojím.

Hm, a jaký z toho vyvodíš důsledek?

Prozatím zůstanu u verze 52, dokud to půjde, a mezitím se poohlédnu po alternativách.

Nebylo by skoro jednodušší dát novému FF šanci?

Kdyby bylo, neměl bych Classic Theme Restorer na "must have" listu (který, mimochodem, není nijak dlouhý, jinak jsou tam už jen AdBlock Plus a Greasemonkey).

[oryctolagus]

Ještě absurdnější mi pak přijde použít takový překladač a jazyk v podstatné míře pro projekt používaný (jak sám uvádíte) stovkami milionů lidí a ještě ke všemu s tím, že se budou využívat nové featury toho jazyka, ještě než na nich uschne barva.

No no. Ty featury procházejí procesem stabilizace a nejsou nikdy stabilizovány, dokud nejsou ověřeny, trvá to AFAIK minimálně dva ty vývojové cykly (ie. 1/4 roku) a většina nových / nestabilních featur je v nightly o dost déle než se přesune přes betu do stable (některé jsou pouze v nightly roky).

Rustifikovaný firefox se mi ještě zabalit nepodařilo, protože rust sice k něčemu (link?) potřebuje gcc, ale musí to být aspoň gcc5 a rust ignoruje standardní proměnné prostředí, takže se mi nepodařilo mu vysvětlit, že místo "gcc" má volat "gcc-5.0" (ale je pravda, že jsem to vzdal už někdy začátkem prázdnin, takže to třeba opravili).

Ano, závislost na GCC je kvůli linkování, protože LLVM donedávna neměl svůj vlastní linker (a nevím, jak je na tom ten nový se stabilitou). Jinak linker nastavit u rustu určitě jde, vím, že jsem to potřeboval minimálně pro cross kompilaci na ARM a/nebo Solaris (a to bylo třeba ~rok zpátky). Nevysypu ti z hlavy, jak přesně se o dělá, ale jít by to mělo.

Stejně jako nevěřím v "distribuční turistiku", nevěřím ani v nové supergeniální jazyky, které spasí svět.

To já samozřejmě taky ne. Ale stejně tak nevěřím, že je dobrý přístup rezignovat na vývoj jazyků, říct že vše užitečné už bylo objeveno a dát všem befelem C99/C++11. Mimochodem, neměl jsi ještě donedávna údernou patičku kritizující C++? (Nebo si to s někým pletu?)

[Michal Kubeček]

No no. Ty featury procházejí procesem stabilizace a nejsou nikdy stabilizovány, dokud nejsou ověřeny, trvá to AFAIK minimálně dva ty vývojové cykly (ie. 1/4 roku) a většina nových / nestabilních featur je v nightly o dost déle než se přesune přes betu do stable (některé jsou pouze v nightly roky).

Obávám se, že naše chápání termínu "stabilní" u klíčových komponent systému (za kterou překladač považuji) se míjí naprosto zásadně, dost možná i řádově.

Ale stejně tak nevěřím, že je dobrý přístup rezignovat na vývoj jazyků, říct že vše užitečné už bylo objeveno a dát všem befelem C99/C++11.

Rezignovat určitě ne, ale znepokojuje mne trend čím dál větší adopce všemožných nových jazyků, které jsou jednak ještě ve stádiu divokého vývoje, jednak si do značné míry vynucují svůj vlastní balíčkovací systém.

Ono to má i praktické důsledky. Zorientovat se v cizím projektu je vždycky problém (i pro toho, kdo v tom má praxi) a když bude navíc každý napsaný v jiném jazyce, tak se na to většina lidí vykašle rovnou. Už jsem na to několikrát narazil, když jsem si říkal, že bych někde něco opravil, ale když jsem zjistil, v čem je to napsané, chuť mne rychle přešla.

Mimochodem, neměl jsi ještě donedávna údernou patičku kritizující C++? (Nebo si to s někým pletu?)

Především si nejsem jistý, jestli jsem tu vůbec někdy měl nastavenou patičku. A jakkoli mám vůči C++ řadu výhrad, patří spíš k mým nejoblíbenějším jazykům a pro poměrně velkou třídu úloh je to dokonce má první volba.

[Conscript89]

Mozna vydavaji pravidelne "novou verzi" ktera ma prazdny changelog.

[oryctolagus]

Obávám se, že naše chápání termínu "stabilní" u klíčových komponent systému (za kterou překladač považuji) se míjí naprosto zásadně, dost možná i řádově.

Ale ne. Já ten požadavek na tu stabilitu v delším horizontu chápu, ale zároveň vnímám i ten pohled z druhé strany: Rust se musí vyrovnávat s protichůdnými nároky, na jedné straně je tam pochopitelně ten požadavek na stabilitu, podporu platforem a všeobecnou vyspělost (zejména lidé zvyklí na C/C++ si často neuvědomují, co všechno má C/C++ za sebou a jak dlouho to trvalo), na straně druhé ale zároveň požadavky na všelijaké featury. Ten jazyk musí zároveň v relativně krátké době prokázat, že je užitečný, zajímavý a reálně nasaditelný, ale zároveň být stabilní. To není jednoduchá situace.

Mimochodem, jak často vychází nový stabilní kernel, když už jsme u těch klíčových systémových komponent?

A co třeba nedávno nová verze glibc, která odstraňuje jeden header file ("xlocale.h", což bylo potřeba opravit v Perlu btw.) a macro SIGUNUSED.

A jakkoli mám vůči C++ řadu výhrad, patří spíš k mým nejoblíbenějším jazykům a pro poměrně velkou třídu úloh je to dokonce má první volba.

Jsem také příznivec C/C++ (koneckonců, živí mě to), ale pro takovou věc jako browser je problematická bezpečnost. Jistě zaznamenáváš neutuchající přísun bugů typu buffer overflow apod. v projektech napsaných v C/C++. Rust má do jisté míry ten rozměr cool nového jazyka, jak jsi napsal, a bohužel existují kolem něj fanatici, ale důvody Mozilly pro jeho vytvoření a použití ve FF jsou v zásadě pragmatické: Potřebovali jakzyk, který bude výkonově blízko C++, ale bude předcházet bugům tohoto typu. Jistě, ten nový CSS engine by určitě šlo napsat v C++, ale kolik chyb s pamětí nebo race conditions by nová implementace obsahovala? Kolik soutěží typu Pwn2Own by bylo potreba na jejich nalezení? Čiliže Rust není pouze "Yet Another", ale poskytuje praktické výhody, které žádný jiný jazyk neposkytuje.

Jestli chceš, můžem se domluvit a můžu ti zkusit někde na IRC pomoct ten nový FF sestavit s tim jiným linkerem...

[aceman]

Suhlasim ze XUL bol HTML + CSS + JS avsak este plus nieco priamo v c++. Zrejme to iste HTML + CSS + JS urobit v minulosti ked vznikol XUL nevedel. Ak to uz dnes HTML + CSS + JS vie, tak stacilo upravit XUL na pouzivanie tychto novych vlastnosti a C++ kod (a pripadne pomale XPCOM rozhrania) odstranit. Kde je teda nahrada za XUL? XUL bola sada preddefinovanych widgetov/elementov, z ktorych sa dalo vybudovat graficke rozhranie aplikacie/rozsirenia. Zaroven boli dizajnovo akotak zladene, zapadali do dizajnu operacneho systemu/desktopoveho prostredia ci toolkitu (gtk3). Ak je to iste dnes mozne implementovat v cistom HTML + CSS + JS, kto to urobi? Je uz nejaka kniznica, ktora ponuka podobnu sadu elementov aj s ich spravanim/funkciami? Ak nie, to si ma kazde rozsirenie bastlit ten HTML+CSS+JS po svojom? To bude pekny bordel alebo budu fakt len primitivne rozsirenia bez nejakeho UI.

Aka je teda alternativa?

[oryctolagus]

Vypadá to, že tohle řeší dva problémy, které jsem s FF měl, totiž rychlost a rozdělený řádek na URL a řádek na vyhledávání. Asi zřejmě čas dát FF po letech opět šanci