Вызов функции JavaScript, определенной в iframe в Chrome, с использованием файлового протокола - PullRequest
Новая
       11

Вызов функции JavaScript, определенной в iframe в Chrome, с использованием файлового протокола

3 голосов
/ 25 февраля 2011

Этот вопрос очень похож на полностью обновленную версию вопроса, задаваемого здесь: Как вызвать функцию JavaScript из одного кадра в другой в Chrome / Webkit с файловым протоколом - к сожалению, этот вопрос былна самом деле никогда не отвечал.

У меня есть HTML-страница, которая содержит изображение SVG в iframe.SVG экспортирует API-интерфейс JavaScript, который позволяет ему выполнять полезные функции (сброс в увеличенном и центрированном виде, отображение в «реальном размере»).Под фреймом я поместил кнопки, по которым пользователь может щелкнуть по этому вызову, для функций, определенных в SVG.

Мой код выглядит следующим образом: 

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

Он отлично работает в Safari, Firefox и даже IE 9 (который поддерживает SVG - ура!).Но в Chrome он не работает: отладчик сообщает мне, что:

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

И действительно, кажется, в этом есть доля правды: хотя «contentWindow» имеет тип DOMWindow, у него нет методов или полей (по крайней мере, не то, что отладчик покажет мне).Даже запрос на его поле 'document' завершается неудачно (возвращает null).

Проблема заключается в использовании протокола file: // для передачи как содержащего HTML, так и содержащего SVG.Как отмечалось в вопросе, на который я ссылался выше, Chrome выдает следующую ошибку при попытке доступа к 'contentWindow':

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

В общем, я считаю, что безопасность велика;это похоже на ограничение безопасности.Но здесь, похоже, зашло слишком далеко: это файлы в файловой системе пользователя, в конце концов, а в моем случае даже в одном каталоге.

Размещение кода не является опцией - он должен находиться на компьютере пользователя.Я бы не хотел говорить людям «просто не пользуйтесь Chrome - у него глупые представления о безопасности».

Нет ли способа обойти это ограничение?

Ответы [ 2 ]

5 голосов
/ 25 февраля 2011

Конечно, нет пути :) Эти файловые протоколы предназначены для явного вызова пользователем.Как вы видели, у веб-приложения абсолютно нет возможности разрешить это.

Единственный способ сделать это, если вы «как пользователь» позволили этому произойти, если да, вы можете включить это.добавив следующий параметр командной строки: 

// 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

Итак, откройте Chrome с помощью: chrome.exe --allow-file-access-from-files, который используется для разработки.

2 голосов
/ 25 февраля 2011

Благодаря информации, предоставленной @Mohamed Mansour, мне удалось найти более подробную информацию по этому вопросу.

Обоснование поведения Chrome заключается в том, чтобы вредоносная страница не могла получить доступ к содержимому вашей файловой системы без вашего ведома через JavaScript и внутренние фреймы и загружать данные в Интернет [ Chromium bug 4197, Ошибка хрома 47416 ].

К сожалению, с моей точки зрения, команда Chromium решила взять вещи настолько далеко, насколько они это сделали. Геккон немного хитрее в использовании этого крота: он ограничивает межстраничные скрипты одинаковыми подкаталогами [ Ошибка Mozilla 230606 , Политика одного и того же источника для протокола файла ]. Результат гораздо менее удивителен для пользователей и разработчиков и вызвал гораздо меньше беспокойства по сравнению с поведением Chrome & mdash; прочитайте Ошибка хрома 47416 в частности, чтобы понять, что я имею в виду.

Из-за этого поведения мне пришлось изменить свой "веб-сайт" & mdash; который не может быть размещен в Интернете и должен находиться на компьютерах локальных пользователей & mdash; так что он выдает диалоговое окно, в котором пользователям предлагается переключать браузеры. Это действительно очень плохо & mdash; Я бы хотел поддержать Chrome, но просто не могу ожидать, что мои пользователи перезапустят его с непонятной опцией командной строки всякий раз, когда они захотят запустить мой «сайт».

Я публикую свои выводы здесь на тот случай, если кто-нибудь еще наткнется на мой вопрос, когда Chrome, по-видимому, таинственно не работает для них, а также призывает всех, кто читает это, рассмотреть ошибка Chromium 47416 . Разработчики до боли дали понять, что не желают рассматривать изменение поведения Chrome, если не ясно, что люди действительно заботятся об этой проблеме. То, что мне сказали «я должен был запретить пользователям использовать Chrome», не было достаточной поддержкой.

...