Strano baco di IE7

[Debiru]

Vabbhè, non ne ha pochi di bachi IE7 ma purtroppo è il browser più usato.

Oggi al lavoro stavo facendo una pagina in ASP che comprende anche delle funzioni javascript.

A seconda della scelta dell'utente dovrebbe apparire un menù a tendina diverso, in sostanza le possibili situazioni sono:
Menù a tendina con tutti i comuni d'italia.
Menù a tendina con delle Università.
Nulla.

Siccome specialmente la query dei comuni risulta particolarmente onerosa avevo pensato di sfruttare il javascript invece di far ricaricare la pagina ad ogni cambio d'impostazione.

La mia idea era di creare una megavariabile javascript stringa che contenesse il codice completo della select dei comuni e una variabile con quella delle università.

E fin quì tutto ok, funzionava tutto, ho fatto delle prove e sono rimasto soddisfatto, anche perché sono riuscito in qualche modo ad ottimizzare i tempi è la pagina si caricava più velocemente.

Finché dai test su Firefox non sono passato a quelli su IE7...


Apro la pagina in questione con IE7 nello stesso modo in cui la apro con Firefox (il quale impiega all'incirca 2/3 secondi ad aprirsi), il computer muore.

Comincia a caricare come un dannato, i servizi non si muovono più, explorer è bloccato, tutte le applicazioni girano a fatica e rimane in questo stato di sforzo estremo per circa 4-5 minuti, dopodiché finalmente carica la pagina...

Ricapitoliamo, Firefox impiega 2-3 secondi sforzando il minimo il pc mentre IE7 impiega 4-5 minuti bevendosi tutte le risorse del pc (e il pc che ho al lavoro spacca le chiappette ai passeri).

Può esserci una così abissale discordanza fra i due browser?

Cioè, ho creato una killer application per IE7 senza neanche accorgermene

[Xinod]

testa la pagina a PC completamente fresco,
IE soffre di memory leakage
cosi' almeno puoi renderti conto se dipende in tutto e per tutto dalla tua applicazione
e se le performance peggiorano con l' uso della stessa (chiaro sintomo di leak)
ciao

[Debiru]

Ti posso dire che il pc è morto esattamente quando ha iniziato a caricare la pagina, ho fatto 2-3 prove per esserne certo ed è così, fai conto che era talmente sotto sforzo che era andato giù anche IIS.

Ho l'IIS attivo perché condivido delle paginette con i colleghi ed un collega ad un certo punto mi ha detto: "Ma che hai spento il pc?".

Pensa quanto ha sofferto

[mondobimbi]

premetto che ho notato, a volte, una tolleranza maggiore di browser tipo mozilla o firefox ad errori di codice. Quindi ti suggerisco prima di tutto di verificare con molta attenzione il tuo codice utilizzando eventualmente gli strumenti di debug che ti fornisce firefox.
In ogni caso penso che la tecnologia da applicare nel tuo caso sia quella di ajax, dai quindi una occhiata alle possibilità che ti offre e vedrai che certamente risolverai il tuo problema in modo più brillante.
ciao
sergio

[Debiru]

Dunque, ti rispondo a capitoli

Errori del codice:

Purtroppo errori non ce ne erano, essendo poi di base molto semplice.
L'unico inghippo era la pesantezza della variabile, la quale era corretta, ma veramente onerosa...


Ajax:

Ad Ajax ci avevo pensato, solo che volevo ottenere la massima performance di questa pagina, un po' per mio estro, un po' perché se poi fai una pagina troppo pesante di rompono non poco al lavoro (c'è un sistemista che ha tutti i grafici di performace sempre sottocontrollo).
Ajax, per sua stessa dicitura, è una tecnologia asincrona, ogni volta che viene chiamato finché non ha finito continua a lavorare.
Anche trovando il sistema di attendere il ritorno del puntatore dalla chiamata prima di permettere una successiva chiamata rimarrebbe comunque il fatto che se l'utente (o utonto) fosse indeciso su cosa scegliere e cambiasse la sua scelta, che ne so, 10 volte, vorrebbe dire che per 10 volte io andrei a fare una query su database e questo lo vorrei evitare nella maniera più assoluta.


Soluzione, ovvero, in confronto Dante ha bighellonato :

La mia prima soluzione l'ho dovuta cannare per ovvi motivi, visto che il caro IE7 non gradisce le variabili js grandi.
Mi sono arrovellato e alla fine ho pensato: "Ah, ma se a lui non piacciono le variabili grandi, passiamogli il codice tramite HTML".

Allora, invece di una grande variabile ho riscritto il codice della SELECT dentro un DIV invisibile con ID, in questo modo fregavo IE7 che non si faceva più prendere da scompensi in vista di megavariabili.
Ora invece di sostituire l'innerHTML della cella dove risiedeva la combo con le varie combo a mia disposizione il cui codice era nelle variabili, ora il codice me l'andavo a pescare da un altro innerHTML.

Firefox tutto ok, IE7 no... non impazziva più devastando il pc, ma al momento di scambiare il contenuto della cella faceva visibilmente più fatica del firefox (ci metteva 3/4 volte di più).

Allora mi sono arrovellato ancora, capendo che IE7 faticava anche a riscrivere l'innerHTML....

Finalmente ho trovato la soluzione definitiva.
Le due combo le ho create e messe tutte e due al posto loro, ma invisibili, ll'unico problema era che una combo invisibile comunque occupa spazio (anche facendone apparire una alla volta una si vedeva a sinistra, l'altra a destra).
Poi ho avuto l'illuminazione, non bastava renderla invisibile, ma per scollegare la combo dalla pagina bastava cambiare il suo position da relative ad absolute e come per incanto se ne andava a quel paese in tutti i sensi


Il risultato è una pagina che una volta caricata, pur sembrando un po' pesantina nel cambiare la combo iniziale, in realtà fa sbrigare tutto il lavoro al pc client non appesantendo ulteriormente il server.

Ho dovuto penare ma alla dura l'ho vinta