Su un’applicazione web su cui stiamo lavorando è capitato un errore che può forse far trasparire il meccanismo di funzionamento interno di ie7 nei confronti del codice javascript.
In pratica, una pagina asp.net generava codice html con alcuni blocchi di codice da eseguirsi client-side tra i tag <script>;</script>;. Uno di questi blocchi faceva riferimento ad un oggetto del DOM che nel frattempo era stato fatto sparire. La riga con l’errore diceva qualcosa come:
document.getElementById(“btnChiudi”).click()
e, malgrado quella riga fosse all’interno di un blocco try/catch, il risultato era una messagebox con il messaggio:
Microsoft JScript runtime error: Object doesn’t support this property or method
Il problema era proprio che il bottone btnChiudi era sparito dalla pagina. Ma io mi sarei aspettato che l’errore mandasse l’elaborazione nel ramo catch, invece che buttare fuori una messagebox. Questo è già strano di suo.
Un’altra cosa molto strana è che l’errore viene segnalato su quella pagina .aspx, ma la riga dell’errore era indicata come “42”. Il punto è che, alla riga 42 di quella pagina, anche andando a vedere il codice ricevuto proprio dal browser IE7, quindi andandolo a pescare dalla cache, non c’è nessun codice javascript. Ma… stranamente, se si prendono in considerazione le sole righe della pagina che si trovano tra i tag script, la riga incriminata è proprio la 42! Per questo motivo tra l’altro abbiamo fatto molta fatica a capire quale fosse esattamente l’errore che si presentava. La pagine infatti è modale, e IE non ha gli stessi strumenti di debugging di Firefox!
Apparentemente questo sembrerebbe indicare due cose:
- IE7, quando elabora una pagina web, trasferisce il codice javascript in uno “spazio” virtuale, una sorta di pagina code-behind, che contiene il solo codice. Il rendering grafico/html/css della pagina a questo punto viene fatto sul codice html originale, ma l’invocazione di codice dinamico client-side agisce su questa pagina virtuale. Sembra che i tecnici della Micro$oft si siano “dimenticati” di rimappare i numeri di riga per i messaggi di errore, come viene fatto dalle direttive di precompilazione
#line del classico c-compiler.
- Sembra che alcuni errori siano prodotti in una fase di “compilazione” precedente all’esecuzione vera e propria. Il contesto in cui avviene questa compilazione non tiene conto di eventuali blocchi try/catch. In questo caso il metodo
click() veniva evidentemente validato (fallendo) in questa fase di pre-compilazione, mentre avrebbe dovuto generare un errore a run-time, trappato dal successivo blocco catch.
Non posso essere sicuro che l’interpretazione dei fatti che ho esposto rappresenti veramente quello è che effettivamente successo “nella pancia” di IE7, ma gli indizi sembrerebbero portare proprio in quella direzione…
Pietro Toniolo 