Come spero avrete notato in settimana è uscito Firefox 5, primo risultato del nuovo ciclo di rilascio rapido che ci porterà ad avere Firefox 6 prima di settembre.

Da tutte le parti si critica la scelta di Mozilla di utilizzare il “metodo Chrome” per la numerazione delle versioni, personalmente trovo la discussione poco utile. Che la versione sia 5 o 4.1 poco cambia, più interessanti sono altri aspetti:

• a quanto pare pochi si lamentano del fatto che il passaggio alla versione 5 sia stato proposto come minor update, in altre parole non è stata richiesto all’utente se volesse passare alla nuova versione (come avviene per un major update, ad es. 3.6.x -> 4). Questo è positivo se l’obiettivo è arrivare ad avere un sistema di silent update (tanto per cambiare in stile Chrome);
• il problema principale è legato alla compatibilità delle estensioni. In questo caso il nodo non è certo il numero 5 – se si fosse chiamata 4.1 la situazione non sarebbe cambiata – quanto la difficoltà pratica per gli autori, quasi sempre volontari che sviluppano per puro hobby, di verificare la compatibilità delle estensioni con un ciclo di vita di sole sei settimane.

Interessante è la (lunga) discussione su dev-planning, in particolare alcune risposte di Asa Doztler che, stando al suo profilo Linkedin, adesso occupa il ruolo di “Director of Firefox”:

• a chi gli fa notare che esistono estensioni non ospitate su AMO, ad esempio utilizzate per la gestione di intranet aziendali, viene risposto che la diffusione in ambito corporate di Firefox non è un obiettivo. Opinione già sentita più volte in passato e poco condivisibile.
• sulla questione compatibilità delle estensioni

Add-on authors who use the Add-on SDK and host at addons.mozilla.org (and their users) will be rewarded with add-ons that don’t require any developer intervention across Firefox rapid releases.

In altre parole: il futuro è quello di estensioni basate su Add-on SDK (qualcuno ricorda la “vecchia” querelle su JetPack?). A questo punto il vero problema è: il nuovo SDK è maturo per estensioni complesse? Se la risposta è no, quando lo sarà? Gli utenti saranno disposti ad aspettare?

Aggiungo una nota: chi ospita le proprie estensioni su AMO ha a disposizione un pannello di controllo che permette di modificare agevolmente la compatibilità senza bisogno di rilasciare una nuova versione del componente aggiuntivo. Molte estensioni sono state automaticamente aggiornate dallo staff di AMO per aggiungere la compatibilità a Firefox 5.

Personalmente non ho avuto alcun problema nel passaggio 4->5, al contrario ne ho avuti diversi nel passaggio 3.6->4 (ho dovuto riscrivere la parte del codice relativa alla gestione delle preferenze).

Mi riallaccio a quanto già scritto per segnalare un bel post di Sean Martell sulle nuove icone per versioni nightly e aurora.

Direi che per il momento il risultato sulle nightly è carino (con qualcosa da sistemare sul fronte “branding”).

Qualche annotazione sul nuovo ciclo di sviluppo rapido adottato da Mozilla:

• gli sviluppatori, come è sempre avvenuto, lavorano sul repository mozilla-central (trunk). Le nightly vengono realizzate a partire dal codice presente in questo repository e ovviamente si tratta delle versioni meno stabili;
• ogni sei settimane le modifiche vengono spostate nel repository mozilla-aurora. Questo repository non prevede la possibilità di modifiche alle stringhe (è “string frozen”), lo scopo è quello di stabilizzare il codice prima di distribuirlo a un pubblico più ampio. Questo significa che i localizzatori possono lavorare su questo repository o, se lo decidono, direttamente su mozilla-central.
• dopo altre sei settimane il contenuto di mozilla-aurora viene spostato nel repository mozilla-beta;
• sei settimane dopo si passa da mozilla-beta a mozilla-release.

L’immagine seguente dovrebbe essere sufficientemente chiara, anche sui numeri di versione. Mentre la versione 5 inizia il ciclo “aurora”, sul trunk inizia il lavoro sulla versione 6 e così via. Di conseguenza ogni sei settimane si avrà una nuova versione.

Ad ogni repository corrisponde un canale di aggiornamento (nightly, aurora, beta, release), selezionabile nella finestra Informazioni su Firefox (come sempre design e localizzazione non sono necessariamente definitivi).

Nel numero 241 (aprile 2011, pag. 174) di PC Professionale, nella rubrica della posta si parla di Firefox e Plugin Container. La rubrica è a cura di Gianluca Marcoccia, onestamente non so se tutte le risposte siano scritte da lui o dalla redazione.

Un lettore scrive lamentando problemi con Firefox (errori e blocchi, processo Plugin Container che consuma CPU), cito alcune parti della risposta.

Il Plugin container di Firefox è una piccola macchina virtuale all’interno della quale sono eseguite le estensioni del browser, con un procedimento analogo alla sandbox delle applicazioni Java. Ogni plug-in può accedere solo alla memoria e alle risorse messe a disposizione dal Plugin container, per impedire che estensioni mal progettate (o che eseguano deliberatamente codice dannoso) possano compromettere il browser o l’intero sistema operativo.

Alla fine della risposta, come extrema ratio viene suggerito di disattivare il plugin container modificando le voci dom.ipc.plugin.enabled.*

Al successivo riavvio, le estensioni saranno eseguite nello stesso spazio di memoria dedicato al browser e con gli stessi privilegi. Questa procedura annulla la protezione aggiuntiva contro i malware e i plug-in mal progettati, perciò deve essere considerata l’ultimo rimedio praticabile.

Le estensioni (extensions) e i plugin (plug-ins) sono due oggetti diversi, come dice il nome stesso il Plugin Container riguarda i plugin, non le estensioni. Citando la relativa pagina di SUMO.

In Firefox 3.6.4 e versioni successive, alcuni plugin sono caricati separatamente dal browser per mezzo del programma plugin-container, permettendo al processo principale del programma di rimanere in esecuzione se si verifica l’arresto anomalo (crash) di un plugin.

Il progetto Electrolysis ha come obiettivo la separazione dei processi relativi a interfaccia del browser, plugin e contenuti web. Una prima parte (Out-of-process plugins – OOPP) è stata rilasciata con Firefox 3.6.4 nel giugno 2010.

L’obiettivo principale è quello di migliorare la stabilità del browser: ogni plugin supportato dal sistema OOPP viene eseguito in un processo separato da quello del browser, in caso di crash del plugin il browser rimane attivo e funzionante. Non mi risultano, ma potrei sempre sbagliare, miglioramenti relativi alla sicurezza della navigazione legati all’OOPP (a parte, forse, l’effetto collaterale di impedire l’esecuzione di codice in caso di crash).

Per inciso, la maggior parte dei problemi con plugin-container.exe è legata a software di sicurezza (antivirus e firewall) configurati in modo errato.

Certi giorni odio aver ragione…

Hi Everyone,

With the upcoming release of Firefox 4, I will be leaving Mozilla Corporation to pursue a new challenge.  My last day will be Thursday, March 17, 2011.  Because of all of you, it’s been a personally transformative experience working for nearly five years at Mozilla.  I owe many of you my sincere thanks for helping a non-engineer with no prior experience find a place in this community to contribute.

Please keep in touch.

Seth B
@binder

Seth Bindernagel è (era) uno dei responsabili l10n in Mozilla (l10n-driver) ed è sempre stato “il” punto di riferimento per noi localizzatori: affidabile, capace, sempre presente quando avevi bisogno di informazioni o di lamentarti e non sapevi dove sbattere la testa, ma soprattutto era ‘nu buono guaglione‘. Pessimismo a pacchi.

Mentre il lavoro sulla release candidate di Firefox 4 dovrebbe concludersi entro il 25 febbraio, la cosa che più balza all’occhio nell’ultimo periodo è la diaspora di pezzi importanti del puzzle: a novembre dell’anno scorso John Lilly (decisione annunciata a maggio, ad oggi non ho ancora avuto modo di valutare il suo successore), a dicembre Aza Raskin, a breve lascerà anche Mike Beltzner , attualmente “Director of Firefox” in Mozilla Corporation.

Se a questo si aggiunge la sempre maggiore concentrazione sul marketing – chiamarlo “engagement” non migliora la situazione – e l’ascesa in credibilità e influenza di personaggi che non ho mai gradito, non sono del tutto ottimista sul futuro di Mozilla (o sul mio coinvolgimento nel progetto).