2010-01-20 23 views
10

Sto eseguendo un caricamento di file in stile Ajax pubblicando il file in un modulo su un iframe e notando alcuni comportamenti strani in IE (sembra che si verifichi in entrambi gli & 8). Fondamentalmente in IE il modulo non è target l'iframe correttamente così la risposta appare in una nuova finestra (invece che nell'iframe). È possibile riprodurre il problema con il seguente set minimo di HTML/JS:Comportamento strano dell'attributo iframe `name` impostato da jQuery in IE

<html> 
<head> 
    <script src="http://code.jquery.com/jquery-1.3.2.js"></script> 
    <script> 
    $(document).ready(function(){ 
     var frameName = "myFrame"; 
     var $iframe = $("<iframe src=\"about:blank\" />") 
       .attr("name", frameName) 
       .appendTo("body"); 
     var $uploadForm = $("<form action=\"http://www.google.com/search\" />") 
       .attr("target", frameName) 
       .append("<input type=\"text\" name=\"q\" />") 
       .append("<input type=\"submit\" />") 
       .appendTo("body"); 
    }); 
    </script> 
</head> 
<body> 
</body> 
</html> 

Ora (prima di postare una risposta), ho fatto qualche indagine (utilizzando strumenti di sviluppo di IE8) e sembra che il .attr("name", frameName) è in realtà aggiungendo l'attributo come submitName="myFrame" anziché semplicemente name="myFrame". Sulla base di questo, ho risolto il problema modificando il codice di creazione iframe al leggermente nastier:

var $iframe = $("<iframe src=\"about:blank\" name=\"" + frameName + "\" />") 
     .appendTo("body"); 

Questa modifica rende il palo forma nell'iframe lo desideri.

Le mie domande sono:

  • Perché non .attr("name", ...) lavoro come previsto?
  • Si tratta di un bug in jQuery, un bug in IE (sicuramente no!?!), O mi manca qualcosa di ovvio?
  • Da dove viene l'attributo submitName da & qual è il suo scopo?

risposta

16

un bug in IE

Difficile da credere, lo so, ma non ci siamo (sicuramente non!?!) .

Storicamente (*), l'impostazione dell'attributo name ha molti problemi in IE. Tende a reggere solo parzialmente. Ad esempio, nei nomi dei campi modulo, non influisce sulla ricerca form.elements[name] come dovrebbe. Questo sembra essere un altro caso in cui l'impostazione della proprietà name non è affidabile.

Mentre jQuery tenta di aggirare i bug del browser come questo, non cattura tutto, e non esiste un modo conosciuto per risolverlo completamente.

(*:. In IE fino a 7. Se si esegue IE8 in documentMode nativa utilizzando un doctype modalità standard e, se necessario, un header/meta X-UA-Compatible, entrambi questi errori non affiorano)

Il submitName visualizzato negli strumenti di sviluppo è un interessante spunto dietro le quinte di un bug di IE, poiché non appare affatto nel DOM visibile a tutti. Fa la stessa cosa se si guarda un elemento <input> o <form> il cui attributo name è stato scritto anche dopo la creazione.

Quindi ciò che sembra accadere è che IE-up-to-7 reindirizza tutti gli attributi denominati name a una proprietà altrimenti invisibile, internamente chiamata submitName, che per i campi modulo cambia i dati che il campo genererà come parte dell'invio di un modulo, ma che non modifica l'attributo reale name utilizzato per l'indicizzazione HTMLCollection, il raggruppamento radio, getElementsByName o, nel caso di [i] frame, il targeting.

+0

Grazie per lo sfondo, penso che questa sia la risposta definitiva che otterrò, escludendo qualsiasi postazione di sviluppatori di IE (anche se non posso immaginarli ammettere il fatto: P), quindi accetto esso. È bello sapere che almeno il bug scompare in IE8 se hai il doctype giusto sul posto. – Alconja

+0

'getElementsByName', il radiocomando e così via sembrano funzionare anche se gli attributi' name' rimangono gli stessi e solo il 'submitName'" attributo "change - hai riscontrato problemi con le cose che hai menzionato? Ho provato questo in modalità di compatibilità ie7 in ie8, e tutto sembrava funzionare. – cic

+0

Altre informazioni: http://thunderguy.com/semicolon/2005/05/23/setting-the-name-attribute-in-internet-explorer/ – cic

0

Hai visto il markup creation improvements in jQuery 1.4?

Se si scopre che brutta, provate questo:

$('<iframe />', 
{ 
    name: frameName, 
    src: 'about:blank' 
}).appendTo("body"); 
+0

Non fa alcuna differenza: l'impostazione di 'nome' dal nuovo oggetto' {attrs} 'fallisce allo stesso modo dell'impostazione usando' attr() '. – bobince

+0

Vergogna, comunque, i miglioramenti alla marcatura meritano di essere mostrati. +1 bobince –

+0

Sì, ho visto la nuova sintassi (bloccata con 1.3.2 per questo progetto), ma in realtà non risponde alla mia domanda ... Il problema esiste ancora usando la nuova sintassi e 1.4 in ogni caso (credo a quello che scritto è effettivamente equivalente al mio originale '.attr (" nome ", frameName)'). – Alconja

2

Non è solo un problema jQuery, quando si imposta manualmente, succede anche.

Se si utilizza il metodo setAttribute() per impostarlo, anche senza jQuery, fa lo stesso quando il modulo o iframe è appena stato creato! Allo stesso modo, utilizzando l'innerHTML è possibile risolvere il problema ... sì, ancora una volta, è il Microsoft distruggendo la mia giornata:/

4

creando l'elemento come questo

$("<iframe name='frameName' />") 

ha risolto il problema per me