2012-03-09 2 views
0

В настоящее время функция SpiderMonkey nsJSContext::CompileEventHandler компилирует обработчики событий с нулевыми принципами. Поэтому в функции frontend::CompileFunctionBody Spidermonkey в настоящее время нет возможности связать принципала с обработчиком событий. Позже директор функции обработчика событий определяется по адресу nsScriptSecurityManager::CheckFunctionAccess.
Мой вопрос в том, может ли детектор безопасности обработчика событий быть обнаружен в точке входа компилятора? Моя интуиция заключается в следующем: обычно обработчики событий привязаны к элементам DOM, основной задачей которых является контейнерный документ. Есть ли какой-либо угловой случай, когда обработчик события вызывается отдельным директором, чем контейнерный документ? Если приведенное выше значение истинно, можно ли определить принципала обработчика события из атрибута «имя_файла» функции frontend::CompileFunctionBody (например, хром: // система URI означает, что http: // uri означает не систему)?
(кстати, как мы можем обнаружить принципала о:.? Протокольных документах иногда они «система», а иногда нет)Определение принципала безопасности обработчика события в точке входа компилятора SpiderMonkey

ответ

0

Один обработчик событий может быть разделен между документами с различными принципами (например, с помощью XBL), так вы действительно не знаете принципала во время компиляции. Перед выполнением обработчика он клонируется с правым руководителем.