Bug nel JavaScript di Firefox: dati sensibili a rischio

[Leron]

Originariamente inviato da evelon


In realtà non ci si deve "abituare" ad IE.
Il suo comportamento è quello del "classico" browser dai tempi di w3.11 con netscape apri>naviga>chiudi.

La scomodità è un fatto del tutto personale, c'è chi li trova comodi e chi no...

FF l'ho provato per qualche giorno usandolo e cercando di configurarlo per farlo funzionare "come voglio io".

Questo è imho il punto più importante di qualsiasi software e più in generale dell'informatica: è il pc (hw + sw) che deve adeguarsi a me e farmi lavorare come mi rimane più comodo, non devo essere io a "ragionare" con la logica del sw....

Ed aggiungerei: tutto ciò deve essere anche semplice ed il più possibile immediato da usare e configurare visto che le persone non usano il sw x per "imparare ad usare il sw x" ma per fare altre cose che il sw x deve permettergli di fare nel modo più facile per loro.
In questo caso il web browsing.

infatti io attualmente trovo firefox e opera di una facilità disarmante, mentre se uso internet explorer mi viene il nervoso dopo 2 minuti a districarmi tra infinite finestre e funzioni che ritengo ormai fondamentali completamente assenti

IE non è comodo. è vecchio.

[Leron]

Originariamente inviato da evelon
Vado un pò a memoria ma mi sembra che ci sia un check che abilita un precaricamento di alcuni moduli (o il non rilascio dopo la prima apertura? boh..) che permetteva una maggiore velocità in apertura.

E' possibile che mi stia sbagliando ovviamente.

questo c'è in mozilla, ma non in firefox

[evelon]

Originariamente inviato da Leron
questo c'è in mozilla, ma non in firefox

Ricordavo male

[bodyman2000]

Vabbè comunque per chi non lo sà....E' STATO GIA' RISOLTO...eccovi il link al FF 1.0.3.....

h°°p://news.swzone.it/swznews-14489.php

scaricate la ver. 1.03....poi andate sul sito e fate la prova....NESSUN ELEMENTO O CARATTERE SARA' SCARICATO DALLA MEMORIA...bug corretto e versione sicura...
Il tutto...naturalemnte in meno di 48H....se era per explorer...ci volevano almeno 72 ore...ad andare bene....

[fek]

Originariamente inviato da bodyman2000
Il tutto...naturalemnte in meno di 48H....se era per explorer...ci volevano almeno 72 ore...ad andare bene....

Originariamente inviato da fek
E sfatiamo una leggenda metropolitana: rilasciare un bug fix dopo un giorno non e' una cosa positiva.

[cdimauro]

Originariamente inviato da IL PAPA
La mia frase "che imparino a fare un sw error free" era da inserire in un contesto più ampio, forse mi sono espresso male.

Provo ad esemplificare: Se io programmo un sw, vedo che è fallato (ovvio che al primo tentativo è sempre fallato, e qui non ci piove, forse l'equivoco è nato qui), mi metto al lavoro per chiudere le falle. orbene, passa il tempo e di falle se ne trovano ancora, decine, nel frattempo rilascio un Service Pack, patch successive etc. ma nulla, se ne trovano ancora; allora decido di dire al mondo "bene ragazzi! tra 2 mesi software nuovo nuovo!" io in prima persona mi chiedo: mbè? non hai ancora messo a posto quello vecchio? come pensi di aver maturato una sufficiente esperienza per farne uno nuovo e risolvere i vari errori che si presenteranno? (che come ripeto quando un sw è giovane sono presenti e con una certa dose di elasticità anche comprensibili) Tenendo anche conto che l'evoluzione del software stesso etc ti costringeranno a crearlo più complesso? anche per star dietro a molti standard o presunti tali che tu stesso hai fatto in modo diventino tali?

Programmare non è come produrre un pezzo per un motore, ad esempio, per cui se a occhio vedi che non è venuto bene gli dai qualche colpo di lima bastarda finché non è a posto...

E' qualcosa di più complicato, e il fatto di non trovare nessun bug sullo stesso software dopo un anno di utilizzo e controlli effettuati, non ti mette al sicuro dalla possibilità che prima o poi se ne trovi qualcuno.

A ciò aggiungi anche il fatto che il software è "mutevole" per definizione, sempre soggetto a cambiamenti, per cui le modifiche fatte per correggere un bug possono paradossalmente aggiungerne altri.

Detto ciò, anche il fatto di realizzare software più o meno "complesso" è irrilevante alla luce di quanto detto...

[cdimauro]

Originariamente inviato da Leron
cmq non è stylexp è semplicemente patchato con uxtheme e messo a mano

Che roba è?

[cdimauro]

Originariamente inviato da Leron
infatti è un bug non da poco e va risolto

Nemmeno il tempo di imparare a scrivere due righe di codice JS...

e ci stanno lavorando da parecchio, ma pare non sia molto facile

Ma non l'avevano risolto, per lo meno nella versione inglese? O forse mi sto confondendo con qualche altro bug...

[Leron]

Originariamente inviato da cdimauro
Che roba è?

uxtheme patcher è un programmino che cambia una dll (uxtheme.dll) consentendo di installare i temi di winxp senza usare programmi esterni

ti posterei il link ma il sito dove li ho messi (www.igpozzo.it) oggi non va ho anche inoltrato domanda a aruba e per tutta risposta hanno bloccato pure l'accesso all'FTP

[Leron]

Originariamente inviato da cdimauro
Nemmeno il tempo di imparare a scrivere due righe di codice JS...

Ma non l'avevano risolto, per lo meno nella versione inglese? O forse mi sto confondendo con qualche altro bug...

non saprei, io ho visto un thread su mozillazine ma magari era vecchio

[grendinger]

Originariamente inviato da IL PAPA
100 KB di memory leak sono nulla, un videogioco di nome Horizons arrivava a 300-400 Mega.
certo il fatto stesso che ci sia magari rompe.

Beh, per avere chiaro il concetto mi sono bastati i 100K
Certo se un bug del genere fosse presente per dire in Photoshop, sai che dramma... dovrei chiuderlo e riaprirlo a ciclo continuo...
Cmq, un memory leak (lo uso anch'io, faccio il "figo" ) dell'entità da te citata non porta a un "crash" dell'applicazione (o del sistema)?
Beh, magari dipende da quanta RAM hai effetivamente a disposizione...

Ciauz

[cdimauro]

Originariamente inviato da Leron
non saprei, io ho visto un thread su mozillazine ma magari era vecchio

Ricordavo bene: ne parlava JoJo all'inizio del thread.

"Il bug è stato segnalato da PI 3 giorni fa e, la nightly (versione di sviluppo aggiornata anche più volte al giorno che trovate qua), rilasciata quello stesso giorno era già patchata. Si attende, a breve visto che stamani è uscita la RC1 ENG, la nuova 1.0.3."

Quindi manca poco anche per la versione italiana...

Per uxtheme patcher, se non ti crea troppo disturbo, potresti farmi sapere (anche in PVT) quando e dove scaricarla? Grazie.

[Leron]

Originariamente inviato da cdimauro
Ricordavo bene: ne parlava JoJo all'inizio del thread.

"Il bug è stato segnalato da PI 3 giorni fa e, la nightly (versione di sviluppo aggiornata anche più volte al giorno che trovate qua), rilasciata quello stesso giorno era già patchata. Si attende, a breve visto che stamani è uscita la RC1 ENG, la nuova 1.0.3."

Quindi manca poco anche per la versione italiana...

Per uxtheme patcher, se non ti crea troppo disturbo, potresti farmi sapere (anche in PVT) quando e dove scaricarla? Grazie.

il multipatcher lo trovi qui

http://download.neowin.net/nw_uxtheme.zip


se vuoi il tema invece devi cercare su deviantart, si chiama iTunes

[fek]

Originariamente inviato da IL PAPA
La mia frase "che imparino a fare un sw error free" era da inserire in un contesto più ampio, forse mi sono espresso male.

La frase e' sbagliata in qualunque contesto perche' il software error free non esiste e non potra' mai esistere.

Provo ad esemplificare: Se io programmo un sw, vedo che è fallato (ovvio che al primo tentativo è sempre fallato, e qui non ci piove, forse l'equivoco è nato qui), mi metto al lavoro per chiudere le falle. orbene, passa il tempo e di falle se ne trovano ancora, decine, nel frattempo rilascio un Service Pack, patch successive etc. ma nulla, se ne trovano ancora; allora decido di dire al mondo "bene ragazzi! tra 2 mesi software nuovo nuovo!" io in prima persona mi chiedo: mbè? non hai ancora messo a posto quello vecchio?

C'e' solo un modo per produrre codice error free al 100% e riuscire a "mettere a posto quello che vecchio": testare tutti i possibili code path, con tutte le possibilie combinazioni di input. Si chiama fare testing esaustivo, ed e' l'unico modo per avere la certezza assoluta di scrivere software error free, quindi da quanto ho capito da quello che hai scritto, finche' non si mette a posto quello vecchio (ovvero dopo aver fatto testing esasustivo)non si ha la credibilita' per farne uno nuovo.

Immagina di avere un oggetto con una decina di metodi (funzioni) ogni metodo con un paio di code path, che accettano due o tre parametri interi.
Se inizi a calcolare tutte le combinazioni di input (2 alla 32 per ogni intero, elevato al numero di parametri, elevato al numero di code path totali), si parla di qualcosa nell'ordine di 10 elevato alla 20 possibili combinazioni (spannometricamente, non ho fatto il calcolo preciso). Ipotizzando di impiegare un millesimo di secondo a testare una combinazione, un testing esaustivo di questa classe impiegherebbe alcuni milioni di anni. Dici che rilasciare una versione nuova del software ogni qualche milione di anni e' un ritmo troppo lento?

[fek]

Originariamente inviato da IL PAPA
100 KB di memory leak sono nulla, un videogioco di nome Horizons arrivava a 300-400 Mega.
certo il fatto stesso che ci sia magari rompe.

I 100kb che ho citato nell'esempio e' un numero tirato a caso nel mio esempio che non si riferisce a Firefox.

Da quanto ho visto sulla mia macchina, in alcune situazione Firefox aveva un leak di qualche decina di kb al secondo per un certo periodo di tempo. Gli ho visto occupare fino a 200mb dopo uso prolungato della stessa istanza per alcuni giorni.

Mi basta killare il processo e farlo ripartire per rimettere le cose in ordine, ma e' comunque fastidioso.

[fek]

Originariamente inviato da grendinger
Cmq, un memory leak (lo uso anch'io, faccio il "figo" ) dell'entità da te citata non porta a un "crash" dell'applicazione (o del sistema)?

Dipende anche da quanto spazio hai sull'HD
Dopo un po' la memoria non acceduta viene parcheggiata sull'HD per soddisfare nuove richieste di memoria RAM. Per questo, se hai notato, ho sempre parlato di memoria e non di RAM

[Banus]

Originariamente inviato da fek
Ipotizzando di impiegare un millesimo di secondo a testare una combinazione, un testing esaustivo di questa classe impiegherebbe alcuni milioni di anni. Dici che rilasciare una versione nuova del software ogni qualche milione di anni e' un ritmo troppo lento?

Senza contare che il testing lo esegue un programma, che può essere a sua volta soggetto a bug. In questo modo rimane la possibilità che qualche caso sfugga anche a un test esaustivo
E' facile capire che non è possibile avere la certezza di un programma bug free, neppure in principio, a parte casi banali e di nessun interesse

[IL PAPA]

Originariamente inviato da fek
I 100kb che ho citato nell'esempio e' un numero tirato a caso nel mio esempio che non si riferisce a Firefox.

Da quanto ho visto sulla mia macchina, in alcune situazione Firefox aveva un leak di qualche decina di kb al secondo per un certo periodo di tempo. Gli ho visto occupare fino a 200mb dopo uso prolungato della stessa istanza per alcuni giorni.

Mi basta killare il processo e farlo ripartire per rimettere le cose in ordine, ma e' comunque fastidioso.

Allora accetta le mie scuse, ho interpretato male il tuo esempio.
Concordo sul fatto che killare un processo e farlo ripartire sia fastidioso, specie se hai dei TAB aperti e ne hai assoluto bisogno per i più svariati motivi.
Spero risolvano in breve!
(spero risolvano + che altro )

[IL PAPA]

Originariamente inviato da fek
La frase e' sbagliata in qualunque contesto perche' il software error free non esiste e non potra' mai esistere.



C'e' solo un modo per produrre codice error free al 100% e riuscire a "mettere a posto quello che vecchio": testare tutti i possibili code path, con tutte le possibilie combinazioni di input. Si chiama fare testing esaustivo, ed e' l'unico modo per avere la certezza assoluta di scrivere software error free, quindi da quanto ho capito da quello che hai scritto, finche' non si mette a posto quello vecchio (ovvero dopo aver fatto testing esasustivo)non si ha la credibilita' per farne uno nuovo.

Immagina di avere un oggetto con una decina di metodi (funzioni) ogni metodo con un paio di code path, che accettano due o tre parametri interi.
Se inizi a calcolare tutte le combinazioni di input (2 alla 32 per ogni intero, elevato al numero di parametri, elevato al numero di code path totali), si parla di qualcosa nell'ordine di 10 elevato alla 20 possibili combinazioni (spannometricamente, non ho fatto il calcolo preciso). Ipotizzando di impiegare un millesimo di secondo a testare una combinazione, un testing esaustivo di questa classe impiegherebbe alcuni milioni di anni. Dici che rilasciare una versione nuova del software ogni qualche milione di anni e' un ritmo troppo lento?

Indubbiamente facendo i dovuti calcoli posso darti ragione, tuttavia si può analizzare il problema e, nel caso tutti i bug sian introvabili e quindi irrisolvibili a breve termine, perlomeno focalizzare la propria attenzione su bug potenzialmente dannosi per l'utente, o su test per identificare perlomeno le falle di sicurezza.
Ora io non voglio cadere sul tecnico come hai fatto tu, per carità; ma molto spesso non è una questione di numeri snocciolati, è una semplice errata metodologia nell'analizzare ed affrontare i possibili errori di un prodotto, dando delle priorità a taluni aspetti piuttosto che ad altri.

[IL PAPA]

Originariamente inviato da grendinger
Beh, per avere chiaro il concetto mi sono bastati i 100K
Certo se un bug del genere fosse presente per dire in Photoshop, sai che dramma... dovrei chiuderlo e riaprirlo a ciclo continuo...
Cmq, un memory leak (lo uso anch'io, faccio il "figo" ) dell'entità da te citata non porta a un "crash" dell'applicazione (o del sistema)?
Beh, magari dipende da quanta RAM hai effetivamente a disposizione...

Ciauz

Si, il rallentamento era enorme anche nel task stesso, per non parlare del sistema, l'applicazione cmq dopo 3-4 ore di utilizzo, spesso e volentieri crashava a desktop.

Con 1 GB di RAM, in ogni caso il problema sarebbe stato presente anche con 2GB, si sarebbe solo presentato dopo.