E anche questa è andata: Firefox 3.5 è ufficialmente disponibile per il download (con tanto di mappa dei download in tempo reale).

In Firefox 3.5 – allacciate le cinture, i giorni che mancano al rilascio ufficiale si contano sulle dita di una mano – ci sono due novità che susciteranno l’ira di alcuni utenti di vecchia data, notoriamente poco propensi al cambiamento:

• se è aperta una solo scheda, il pulsante di chiusura non viene visualizzato;
• chiudendo l’unica scheda aperta nella finestra del browser (con CTRL+W), Firefox viene completamente chiuso (il problema non riguarda gli utenti Mac). Questo non accadeva nelle versioni precedenti, nel caso in cui l’utente avesse scelto di visualizzare sempre la barra delle schede (impostazione predefinita nella nuova versione). Il problema risulta particolarmente fastidioso quando si attiva anche l’eliminazione dei dati personali in fase di chiusura (a differenza di Firefox 3, non viene più richiesta la conferma prima di procedere con l’operazione): basta un CTRL+W di troppo per ritrovarsi con il browser chiuso.

Il secondo punto è facilmente risolvibile:

• digitare about:config nella barra degli indirizzi;
• cercare la chiave browser.tabs.closeWindowWithLastTab e impostarla a false (basta fare doppio clic).

Per il primo problema esistono più soluzioni:

• installare Stylish e questo user-style;
• modificare a mano il file userChrome.css nella cartella del profilo aggiungendo queste righe (è lo stesso codice dello user-style precedente)

.tabbrowser-tabs[closebuttons="alltabs"] > .tabbrowser-tab > .tab-close-button {
display: -moz-box !important;
}
.tabbrowser-tabs:not([closebuttons="noclose"]):not([closebuttons="closeatend"]) > .tabbrowser-tab[selected="true"] > .tab-close-button {
display: -moz-box !important;
}

A proposito di schede, provate a “tirare” una scheda dalla sua posizione iniziale (ad esempio trascinandola dalla barra delle schede verso il centro della finestra). Quando avete finito, potete sempre riportarla nella finestra originale 😉

Nelle scorse settimane sono circolati diversi articoli relativi all’abbandono, da parte di Mozilla, del supporto alle vecchie versioni dei sistemi operativi Windows. Tutto è nato da questa proposta avanzata da Mike Connor – lead developer di Firefox 3 – nel gruppo di discussione mozilla.dev.planning:

Innalzare i requisiti minimi su sistemi Windows per Gecko 1.9.2 (e qualsiasi versione di Firefox basata su Gecko 1.9.2), richiedendo come versione minima Windows XP Service Pack 3 o successivo

Considerata la scarsa precisione di alcuni di questi articoli e il conseguente allarmismo, è opportuno spiegare nel dettaglio che cosa significhi e cosa comporti questa decisione.

Gecko è il motore di rendering utilizzato dai software Mozilla: l’attuale versione stabile di Firefox (3.0.x) utilizza la versione 1.9.0 di Gecko (la versione è rilevabile nella finestra Informazioni su di Firefox, dove viene visualizzato l’user agent completo del browser). La prossima versione di Firefox (Firefox 3.5), il cui rilascio è previsto nei prossimi mesi, si baserà sulla versione 1.9.1 di Gecko. La versione successiva, al momento chiamata Firefox 3.6, si baserà sulla versione 1.9.2 di Gecko.

Questa scelta di non supportare le versioni più vecchie di Windows non riguarda l’attuale versione di Firefox, non riguarda la prossima versione di Firefox, coinvolge esclusivamente la versione di Firefox che verrà rilasciata all’inizio del 2010 (se verrà rispettata la pianificazione attuale). Si tratta quindi di quasi un anno, a cui bisogna aggiungere i sei mesi canonici di supporto garantiti da Mozilla: se la nuova versione (ipotizziamo Firefox 3.6) viene rilasciata nel febbraio 2010, il ramo di sviluppo relativo alla versione precedente (Firefox 3.5.x) continuerà a ricevere aggiornamenti di sicurezza fino ad agosto 2010. Per avere un ulteriore riferimento, il supporto di Microsoft a Windows XP sp2 terminerà il 13 luglio 2010.

Come ulteriormente spiegato dallo stesso Connor, sarà possibile continuare ad utilizzare Firefox sulle vecchie versioni di Windows, ma tali piattaforme saranno considerate “non supportate”. In pratica questo significa che:

• non sarà disponibile una tinderbox;
• non ci saranno controlli QA (controllo qualità);
• non si effettueranno unit test e controllo delle prestazioni (talos);
• non verranno considerati bloccanti i bug riguardanti esclusivamente queste piattaforme;
• verranno accettate correzioni di terze parti, a patto che non compromettano la compatibilità con i sistemi operativi ufficialmente supportati.

Da notare come nell’ultima proposta la versione minima supportata sia passata dall’iniziale Windows XP sp3 alla versione service pack 2.

Per quanto riguarda gli altri sistemi operativi, ricordiamo che:

• con Firefox 3 è stata abbandonata la compatibilità con Windows 98, Windows Me e Mac OS X Panther (10.3.x)
• con buona probabilità, Gecko 1.9.2 (vedi considerazioni iniziali sulle tempistiche) non sarà compatibile con Mac OS X Tiger (10.4.x)

Tutto parte da questo post di Wladimir Palant, autore di AdBlock Plus:

The recent events give an impression of the kind of effects we should expect here. This is going to be about the popular NoScript extension which happens to make its money from ads.
[…]
NoScript was extended by a piece of obfuscated (!) code to specifically target Adblock Plus and disable parts of its functionality. The issues caused by this manipulation were declared as “compatibility issues” in the NoScript forum, even now I still didn’t see any official admission of crippling Adblock Plus. Clearly, NoScript is moving from the gray area of adware into dark black area of scareware, making money at user’s expense at any cost.

Risposta di Giorgio Maone, autore di NoScript (conviene leggere tutta la discussione, da quel post fino alla calata dei bimbominkia):

1.9.2, together with the long awaited bookmark-based syncrhonization feature, deployed a countermeasure meant to prevent automated subscriptions from affecting these sites, which NoScript and FlashGot development depends upon. Unfortunately this countermeasure proved to be overzealous, because it unwillingly disabled also blocked objects reporting on these sites: therefore user was unable to block my ads even if he really wanted to (short of disabling active content using NoScript itself).
I promptly fixed this in subsequent development versions, which enable users to block ads on these sites as well if they wish to.
However I decided to make this work-around simpler and more apparent to users, for transparence sake: so next stable releases will just add an explicit whitelist site filter, also providing instructions about disabling such a filter for those ABP users who don’t know how to do it and are determined not to see any ad supporting NoScript and FlashGot development.

A mio modo di vedere Giorgio ha commesso due errori:

• ha sottovalutato la portata di quella modifica, soprattutto in un’estensione votata alla sicurezza come NoScript. Tradire la fiducia dell’utente, andando a modificare un’altra estensione senza consenso, è un comportamento stupido e ingiustificabile (e credo se ne sia reso conto a sue spese).
• non ha comunicato (risposto) in modo adeguato: il post di Wladimir Palant, che personalmente trovo fuori dalle righe così come il comportamento dell’attuale maintainer di Easylist, è stato pubblicato su Planet Mozilla e ha fatto il giro del mondo (vedi reazione nei commenti su AMO), la risposta è ad oggi sepolta in un forum di supporto e nelle FAQ del sito (e nelle note di versione dell’ultimo aggiornamento, che nessuno si prende la briga di leggere, in cui viene rimosso il filtro incriminato).

È disponibile per il download la versione beta 4 di Firefox 3.5 (ex Firefox 3.1, note di versione in inglese). Come sempre l’installazione di versioni di sviluppo è consigliata solo ad utenti esperti: si tratta di versioni non definitive e non necessariamente stabili, per cui i crash e le perdite di dati sono eventi da non escludere. Il suggerimento è quello di utilizzare un profilo appositamente creato e solo estensioni espressamente compatibili con la nuova versione del software. Prima di segnalare eventuali bug su Bugzilla, è indispensabile cercare di riprodurre il problema con un profilo pulito (senza estensioni).

Come già scritto, le versioni beta sono rivolte a sviluppatori e tester, per questo motivo non verrà fornito alcun supporto sul forum di Mozilla Italia. È comunque possibile discutere delle nuove funzionalità, segnalare eventuali bug, perplessità, malfunzionamenti o problemi riscontrati nell’apposita sezione del forum dedicata alla versioni di sviluppo.

Alcune annotazioni su Firefox 3.5 beta 4:

• questa nuova beta è disponibile in 70 lingue;
• migliorata la gestione dei dati personali, inclusa una modalità di navigazione anonima;
• migliorate le prestazioni e la stabilità dell’applicazione grazie al nuovo motore JavaScript TraceMonkey;
• supporto agli standard per la geolocalizzazione;
• supporto nativo a JSON e supporto ai web worker thread;
• miglioramenti al motore di rendering Gecko, incluso un sistema di parsing “speculativo” per ridurre i tempi di visualizzazione delle pagine;
• supporto a nuove tecnologie web quali: elementi <video> e <audio> (HTML5), font scaricabili e altre nuove proprietà CSS, supporto a query selector in JavaScript, offline data storage (HTML5) e trasformazioni SVG.

Leggo sull’ultimo numero italiano di Wired un articolo relativo all’ottimizzazione di Firefox (aka “rendere il browser più veloce”). Esaminiamo uno alla volta i consigli dell’esperto (Angelo di Veroli).

1) Creare in about:config una chiave content.notify.interval e impostarla a true, creare una seconda chiave content.notify.ontimer e impostarla a 500.000. Cito dagli articoli che descrivono queste preferenze su MozillaZine:

Setting this preference to true will greatly increase rendering time on high speed connections.

Lowering the interval will lower the perceived page loading time but increase the total loading time, especially on slower connections. Values below 100,000 have a significant impact on performance and are not recommended.

Traduco le parti in grassetto per chi non mastica l’inglese: “aumenta in modo considerevole il tempo di rendering su connessioni ad altà velocità” e “diminuisce il tempo percepito di caricamento della pagina ma aumenta il tempo complessivo di caricamento”. Sbaglio oppure l’obiettivo iniziale era quello di aumentare la velocità del browser?

2) Creare in about:config una chiave content.switch.threshold e impostarla a 250.000

Raising the value will make the application more responsive at the expense of page load time

Il valore di default è 750.000 (0,75 secondi). In pratica si diminuisce l’intervallo necessario per passare dalla modalità high frequency interrupt a quella low frequency interrupt: in modalità low frequency interrupt il caricamento diventa più veloce, a scapito della reattività dell’interfaccia. Peccato che serva attivare anche la prima chiave (content.notify.interval).

3) Creare in about:config una chiave content.interrupt.parsing e impostarla a false.

Parsing cannot be interrupted. The application will be unresponsive until parsing is complete.

L’applicazione potrebbe “non rispondere” fino a quando il parsing della pagina non sarà completato, e già questo dovrebbe far riflettere sull’utilità della modifica. La chicca in realtà è un’altra: il “consiglio” numero 2 (content.switch.threshold) richiede questa chiave a true (valore predefinito), quindi diventa perfettamente inutile.

Morale della favola: documentatevi e non fidatevi del primo esperto che trovate in un angolo.