2009-06-29 10 views
3

La scène: J'écris un widget intégrable. Il prend la forme d'une balise <script>, qui construit un iframe contenant tout ce dont il a besoin pour afficher. Le iframe n'a pas src, et le script lui écrit avec theIframe.contentWindow.document.write(). Cela permet de conserver le widget et empêche les identifiants d'élément et le script d'entrer en conflit avec la page sur laquelle le widget est incorporé.Comment créer un iframe avec le même domaine que la page dans Safari/WebKit

L'astuce: Le widget doit pouvoir changer sa taille. Pour ce faire, il définit ses iframe contenant style.height. Cela nécessite l'accès au DOM de la page externe. Dans Firefox et IE, cela est autorisé, car le document iframe et le document externe sont considérés comme partageant une origine.

La torsion: Dans Safari, cependant, les deux documents sont considérés comme non de partager une origine. Le document interne est considéré comme étant about:blank, tandis que le document externe utilise clairement un protocole différent et un "domaine" (si blank peut être considéré comme le domaine).

La question: Comment créer un iframe par programmation dont le document Safari/WebKit considérera avoir la même origine que le document de la fenêtre qui le crée?


Modifier: Après une expérimentation plus loin, je ne peux pas trouver un moyen de créer un programme iframe dont l'emplacement est pas about:blank indépendamment du fait que je change son contenu.

Si je crée le cadre avec document.createElement(), lui donner un src qui pointe vers une véritable ressource HTML sur la même origine appelée « foo.html », et document.body.appendChild() il, la console de Safari montre l'élément comme prévu dans les DOM, mais le contenu de la page n'apparaît pas et le document est listé dans la barre latérale comme "about: blank".

Si j'inclue le code HTML de l'iframe directement dans la page, le contenu de foo.html apparaît et "foo.html" apparaît dans la barre latérale. Si j'insère le HTML en utilisant document.write(), j'obtiens le même résultat qu'avec document.body.appendChild().

Les deux versions programmées fonctionnent dans Firefox.

Répondre

0

Aha. Cela semble être un bug dans WebKit. Lorsqu'un iframe est créé par programmation, son attribut src est ignoré. Au lieu de cela, le cadre par défaut est about:blank et doit être dirigé vers une URL pour pointer ailleurs.Par exemple:

theIframe.contentWindow.location = theIframe.src 
+0

J'ai besoin d'un éclaircissement. Où ce javascript doit-il être exécuté, dans la fenêtre parente ou dans l'iframe lui-même? Qu'est-ce que theIframeContentWindow? Si vous faites référence à l'objet window de l'iframe, ne serait-ce pas "theIframe"? Ce qui signifie que vous pourriez simplifier cela à "theIframe.location = theIframe.src"? Toute aide serait appréciée, car j'ai déjà rencontré ce bug. Merci. –

+0

Désolé, il me manquait un point. theIframe est ici l'élément iframe, pas le cadre ou la fenêtre qu'il contient. theIframe.contentWindow est son objet window qui héberge la page interne. Ce code s'exécute dans la page externe, juste après l'ajout de l'iframe au DOM. C'est le point auquel le contentWindow existe (je crois). C'est aussi le point auquel les autres navigateurs font exactement cela: naviguer dans la fenêtre de l'iframe vers le src de l'iframe. – Peeja

1

La meilleure suggestion que je pourrais donner est d'avoir le iframe défini sur une page blanche sur le même serveur (c.-à-d. Blank.html) et puis éditer le contenu. Une douleur à l'arrière, je sais mais c'est une solution de contournement.

Vous pouvez également essayer

iframe.contentDocument.open("replace"); 
iframe.contentDocument.write("<b>This is some content</b>"); 
iframe.contentDocument.close(); 

Cependant, je ne suis pas sûr si cela fonctionne seulement dans IE. Désolé je ne pourrais pas être plus utile que cela.

+0

Bonnes pensées. Le problème semble être plus délicat que je ne le pensais. Voir les ajouts dans la question. – Peeja