Appeler une fonction JavaScript définie dans un iframe à Chrome en utilisant le protocole de fichier

Cette question est extrêmement similaire à la version entièrement mise à jour de la question posée ici: Comment appeler une fonction JavaScript d'un cadre à l'autre dans Chrome / Webkit avec protocole de fichier – malheureusement, cette question n'a jamais été réellement répondu.

J'ai une page HTML contenant une image SVG dans un iframe. Le SVG exporte une API JavaScript qui lui permet de faire des choses utiles (réinitialiser au zoom et au centre, afficher à "taille réelle"). Au-dessous de l'iframe, j'ai mis des boutons sur lesquels l'utilisateur peut cliquer sur cet appel vers les fonctions définies dans le SVG.

Mon code ressemble à ceci:

function reset() { document.getElementByID('iframe').contentWindow.reset(); }

Il fonctionne parfaitement dans Safari, Firefox et même IE 9 (qui prend en charge les SVGs – hooray!). Mais sur Chrome, il échoue: le débogueur m'informe que:

Property 'reset' of object [object DOMWindow] is not a function .

Et en effet, cela semble être vrai: même si 'contentWindow' est de type DOMWindow, il n'a pas de méthodes ni de champs (au moins, non pas que le débogueur me montre). Même en demandant que son champ 'document' échoue (rend nul).

Le frottement semble être l'utilisation du fichier: // protocole pour transférer à la fois le HTML contenant et le SVG contenu. Comme indiqué dans la question que j'ai mentionnée ci-dessus, Chrome produit l'erreur suivante lors de la tentative d'accès à "ContentWindow":

Attempt to access frame with URL file://[...]/contained.svg from frame with URL file://[...]/container.html. Domains, protocols and ports must match.

En général, je pense que la sécurité est géniale; Cela ressemble à une restriction inspirée de la sécurité. Mais ici, cela semble être trop loin: ce sont des fichiers sur le système de fichiers de l'utilisateur, après tout, et dans mon cas, sont même dans le même répertoire.

L'hébergement du code n'est pas une option: il doit résider sur la machine de l'utilisateur. Je détesterais avoir à dire aux gens "ne pas utiliser Chrome", il a des idées stupides de sécurité. "

N'y a-t-il aucun moyen de contourner cette restriction?

Bien sûr, il n'y a aucun moyen 🙂 Ces protocoles de fichiers sont destinés à être explicitement appelés par l'utilisateur. Il n'y a absolument aucun moyen pour une application Web de permettre cela, comme vous l'avez vu.

La seule façon de le faire est que si vous «en tant qu'utilisateur» a permis que cela se produise, dans ce cas, vous pouvez l'activer en ajoutant le paramètre de ligne de commande suivant:

 // By default, file:// URIs cannot read other file:// URIs. This is an // override for developers who need the old behavior for testing. --allow-file-access-from-files

Ouvrez donc Chrome avec: chrome.exe --allow-file-access-from-files ceci est utilisé pour le développement.

Grâce aux informations offertes par @Mohamed Mansour, j'ai pu trouver plus de détails sur ce problème.

La raison d'être du comportement de Chrome est d'empêcher une page malinicieuse, via JavaScript et les cadres internes, d'accéder au contenu de votre système de fichiers à votre insu et de télécharger des données sur Internet [ Chromium bug 4197 , Chromium bug 47416 ].

Il est regrettable, selon mon point de vue, que l'équipe de Chromium choisisse de prendre les choses aussi loin qu'elles. Gecko est un peu plus subtil en bloquant cette mole: elle limite les scripts de cross-page aux mêmes sous-répertoires [ Mozilla bug 230606 , politique de même origine pour le protocole de fichier ]. Le résultat est beaucoup moins surprenant pour les utilisateurs et les développeurs et a généré beaucoup, beaucoup moins d'ennuis que sur le comportement de Chrome – lire Chromium bug 47416 en particulier pour voir ce que je veux dire.

En raison de ce comportement, j'ai dû modifier mon «site Web» – qui ne peut être hébergé sur Internet et doit résider sur les machines des utilisateurs locaux – afin qu'il lance une boîte de dialogue indiquant aux utilisateurs de changer de navigateur. C'est vraiment dommage – j'aimerais soutenir Chrome mais je ne peux pas espérer que mes utilisateurs le relancent avec une option de ligne de commande obscure quand ils veulent exécuter mon "site web".

Je publie mes résultats ici, au cas où quelqu'un d'autre trébucherait sur ma question lorsque Chrome semblerait ne pas fonctionner mystérieusement pour eux et aussi pour encourager quiconque lira ceci à considérer en vedette Chromium bug 47416 . Les développeurs ont rendu douloureusement clair qu'ils ne veulent pas envisager de modifier le comportement de Chrome, à moins qu'il soit clair que les gens se soucient vraiment du problème. En disant «j'ai dû dire aux utilisateurs de ne pas utiliser Chrome», cela n'a pas été assez encourageant.