Aggiornamento performance JS

Visto che è stata rilasciata la nuova beta di Firefox 3.0, ho aggiornato il grafico comparativo dei risultati ottenuti col test SunSpider.

Notare i risultati ottenuti da FireFox dopo le ottimizzazioni della patch PGO.

Explorer 8? Mi serve una nuova macchina virtuale…

Performance di JScript

Dopo il rilascio di SunSpider, la suite di benchmark realizzata dagli sviluppatori del WebKit, avevo fatto dei test sulla mia macchina, confrontando tra di loro diversi browser, IE incluso testato su una macchina virtuale. I risultati sono riassunti in questo grafico(*):

Il test SunSpider misura le prestazioni dell’interprete javascript di per se, quindi senza prendere in considerazione funzionalità più specifiche del browser come l’implementazione di DOM e le api javascript del browser.

Mi avevano colpito due dati. Il primo è l’incremento di prestazioni riscontrabile nelle nightly build del WebKit rispetto a quelle espresse da Safari (ora uso queste al posto di Safari). Il secondo è lo scarso risultato ottenuto da IE 7 sui test che si basano sulla manipolazione delle stringhe. Certo, si parla di un test eseguito usando una macchina virtuale, ma questo non può mettere in secondo piano il fatto che gli altri test non producono numeri così insoddisfacenti.

Qualche giorno fa ho trovato un post interessante sul blog di JScript in cui si parla dell’implementazione non ottimale dell’operatore + applicato sulle stringhe. In pratica, l’operazione di concatenazione, che comporta la creazione di un buffer in grado di contenere il risultato e la copia del contenuto dei due operandi, viene eseguita ogni volta che si presenta l’operatore +. Nel caso di concatenazioni multiple, non è prevista alcuna ottimizzazione per evitare di ripetere più volte inutili operazioni di allocazione e copia di buffer.Non so quanto questo c’entri con i risultati di sopra.

Nell’articolo mi colpisce una frase: “Jscript was meant to be used just as glue, not as full-fledge programming language as used in modern WebApps“.In un altro articolo a proposito delle prestazioni del garbage collector di JScript leggo qualcosa di simile: “the JScript GC was designed for simple little web pages“.

In effetti JScript come lo conosciamo ora è nato anni or sono quando non si prevedevano certe evoluzioni del web, con la proliferazione di applicazioni web di una certa complessità e dei vari toolkit javascript nati per renderne più semplice lo sviluppo e per spingere oltre il livello di complessità.

(*) Le specifiche della macchina sono le seguenti: MacBook, processore Intel Core 2 Duo 1.83 GHz, Cache L2 2 MB, 2 GB ram,  bus 667 MHz, Mac OS X 10.5.1 (9B18); per Explorer ho usato Windows XP Sp2 su Parallels desktop con assegnati 1GB di ram e configurato per ottimizzare le prestazioni della macchina virtuale.

Quando arriva IE 8?

Me lo chiedo perché vorrei non dovermi più preoccupare di certi problemi.

So bene che la perfezione è un’utopia, ma la situazione potrebbe essere decisamente migliore a quella attuale.

Perché mi lamento? Dunque… argomento: visual formatting model – attributo display.Il w3c dice a proposito dell’attributo display:

“inline-block

This value causes an element to generate a block box, which itself is flowed as a single inline box, similar to a replaced element. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an inline replaced element”.

Firefox 2 implementa in modo errato questa modalità. Stiamo calmi! Per fortuna, questo bug è stato corretto in Firefox 3. Opera e Safari… pardon, WebKit (io preferisco le nightly build) non danno problemi. IE 7 si mostra in teoria capace di implementare questa modalità; con display: inline e width e height specificati renderizza il blocco come previsto dallo standard nel per display: inline-block. Eppure display: inline-block sembra proprio non sappia cosa sia. E non mi pare neanche che un suo eventuale supporto avrebbe prodotto chissà quali problemi.

Siamo buoni: se ne sono dimenticati.

Altra dimenticanza: empty-cells: show. Ovvero, dobbiamo continuare a complicare il nostro codice inutilmente per produrre inutili. Ma era così difficile da realizzare?

URI handler “rimistificato” ;-)

Oggi devo ricordare una certa discussione a proposito della vulnerabilità sulla gestione degli URI riscontrata su Firefox ma anche su diversi altri applicativi. Io dissi che…

“Scusate, io vedo un problema ben più grande che va oltre l’interpretazione dei parametri di Firefox. La mia impressione è che il problema principale risieda nel meccanismo di gestione degli helper che è fin troppo banale nella definizione dei comandi da richiamare è che può essere usato per passare parametri dal comportamento pericoloso. Questo è un problema non imputabile a IE ma a cioè che sta in mezzo tra IE, cioè il software chiamante, e l’handler, cioè qualsiasi altro software chiamato.

Proprio l’esempio che viene fatto mi pare chiarificatore:

FIREFOX.EXE -url “FirefoxURL://foo” –argument “qualcosa di losco” -requestPending

Io che leggo so bene che –argument sia “qualcosa di losco” e -url sia “FirefoxURL://foo”. Se da prompt dei comandi scrivo -altro “altro parametro”, so bene che il valore del parametro è tutto ciò che è racchiuso tra gli apici. Nel caso in cui voglia includere degli apici nel valore probabilmente farò uso di una sequenza di escape. Ora, Questo stesso meccanismo, cioè quello usato per interpretare i comandi che gli utenti usano per richiamare le applicazioni dal prompt o da script batch (e ci sarebbe da riflettere pure su questo) è usato per definire l’interazione tra due applicazioni. Mi aspetto che in questo modo si possano fare innumerevoli porcate che prescindono da Firefox, IE e qualsiasi altro software. Un sistema che permette una banale concatenazione di stringhe per costruire i parametri così come dovranno essere forniti all’applicazione che li dovrà acquisire si dimostra alquanto debole. Insomma, ci fosse almeno un banale escaping! Mi aspetto altri tipi di exploit basati sullo stesso principio”

Nota: non sapevo che il problema era stato introdotto con un componente aggiornato da Explorer 7.

Una considerazione dal mio punto di vista ragionevole.

Oggi, per caso, scopro, grazie ad un articolo di P.I. che microsoft pubblicato un Security Advisory in proposito che riguarda Windows XP con Explorer 7 installato.

Se ho capito bene, si sono accorti del problema che avevo indicato sopra, mesi or sono.

A questo punto mi viene da fare qualche osservazione sulla questione e sul modo di gestire le problematiche di sicurezza.

In questo caso i problemi sono di due tipi: uno periferico e che riguarda il comportamento di N applicazioni, dove N può essere più o meno elevato, numero che purtroppo mette a rischio la sicurezza di X sistemi, con X MOLTO elevato; l’altro centrale, cioè nel meccanismo che fa si che applicazioni poco accorte nella valutazione dei parametri possano essere sfruttate. Correggere N applicazioni non è più facile di correggere un singolo point of failure. Fino ad ora s’è scaricata la responsabilità sulle N applicazioni solo perché di mezzo ci stava una questione di marketing (Explorer v.s. Firefox). Ma per me, che non sono un esperto di sicurezza, mi pare ragionevole agire su un singolo punto critico e mettere in sicurezza milioni di sistemi senza stare tanto a discutere su di chi sia la colpa. Mentre è meglio discutere su dove sia il punto critico.

Comunque, meglio tardi che mai.

Firefox update e unità di misura mancanti

Attenzione! Dopo l’ultimo update di Firefox tutte le misure specificate nei css senza indicare l’unità di misura (ex.: px, cm) vengono ignorate. Preparatevi a correggere tonnellate di css (rimbombano ancora le imprecazioni di V.).

p.s.: questo post andrebbe riscritto, dato che la questione è un attimo più complessa e interessa ciò che prevede lo standard e l’uso del DOCTYPE.

Page Zoom con Firefox 3

Non molti hanno chiara la misura dell’innovatività della prossima release di Firefox. Alcuni dettagli tecnici possono essere d’aiuto. Ad esempio, è noto che Firefox 3 sarà basato su Cairo, libreria grafica vettoriale open source. Non conoscendo così a fondo come è fatto Firefox non posso valutare fino a fondo le conseguenze di questa novità. Però, dovendo affrontare un problema per un lavoro, ho scoperto alcuni dettagli interessanti a proposito del supporto SVG in Firefox 3. Lo standard SVG prevede l’incorporazione di frammenti XHTML nel codice xml del formato grafico. Ho preso in considerazione questa possibilità per realizzare delle pagine contenenti miniature di documenti XHTML. Ovvero, potendo mettere dentro pagine XHTML oggetti SVG, mi è sembrato ovvio che un frame contenente un frammento HTML, presentato con una trasformazione per ridimensionarne il contenuto potesse presentare l’eventuale contenuto HTML ridimensionato graficamente, per esempio del 50% o del 70%. Una cosa diversa dal ridimensionare ogni singolo attributo del frammento HTML, soluzione tradizionalmente adottata in questi casi e che ha diverse controindicazioni (prima: la complessità). Però al momento non è possibile utilizzare questa soluzione perché non c’è un browser, Firefox 2 incluso, in grado di renderizzare HTML dentro SVG. Al contrario, Firefox 3 prevede questa possibilità. Ho provato con l’ultima release alpha di FF3 e sembra che la soluzione funzioni, fatta eccezione per un bug presente sulla versione mac che fa si che sui font non venga applicata correttamente la trasformazione.

Magari prossimamente pubblico un esempio con tanto di codice.