Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Security errors writing to an iframe in a signed script

7 views
Skip to first unread message

Bryan White

unread,
Apr 28, 2008, 11:10:52 AM4/28/08
to
I maintain a set of signed XUL jar apps for our company Intranet. In a
few places the XUL page contains an IFRAME tag and the Javascript code
needs to write an HTML document to it.

The code that does this looks like this:

var elem = document.getElementById(id);
netscape.security.PrivilegeManager
.enablePrivilege("UniversalXPConnect");
var doc = elem.contentDocument;
doc.open();
doc.write(html);
doc.close();

Ever since Firefox 2.0.0.13 this code fails. It throws an exception in
the doc.open() call:
[Exception... "Security Manager vetoed action" nsresult: "0x80570027
(NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "JS frame ::
jar:https://isengard.arcamax.com:2020/db/jar/gallerybuilder.jar!/lib.js
:: ShowHTML :: line 584" data: no]

Note that there is no problem in Firefox 2.0.0.12 and Firefox 3 Beta 5.
It fails in 2.0.0.13 and 2.0.0.14.

I have a similar problem in a related context. In that case I need to
examine the contents of an element inside the I frame. It seems as if
any access to an iframe contentDocument is now disallowed.

I would like to find a work-around for these issues.

Bryan

Boris Zbarsky

unread,
Apr 28, 2008, 10:06:03 PM4/28/08
to
Bryan White wrote:
> netscape.security.PrivilegeManager
> .enablePrivilege("UniversalXPConnect");

Hmm. It's really odd that you're getting NS_ERROR_XPC_SECURITY_MANAGER_VETO
after that.

I assume you can't really make a testcase available that would demonstrate the
problem, right? Would you be able to hunt down a one-day regression range using
the 1.8.0 builds from <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/>?
For example,
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-03-28-04-mozilla1.8.0/
has builds from March 28, 2008. There are also 2008/ and 2007/ directories for
older builds....

Given a one-day range, it should be possible to figure out which exact code
change caused the behavior change and see what's going on...

-Boris

Bryan White

unread,
Apr 29, 2008, 7:15:08 AM4/29/08
to

The test case is here:

http://www.arcamax.com/testcase/

this works:
http://ftp.mozilla.org/pub/mozilla.org
/firefox/nightly/2008/03/2008-03-06-12-mozilla1.8
/firefox-2.0.0.13pre.en-US.win32.installer.exe

this fails:
http://ftp.mozilla.org/pub/mozilla.org
/firefox/nightly/2008/03/2008-03-07-03-mozilla1.8
/firefox-2.0.0.13pre.en-US.win32.installer.exe

Bryan

Boris Zbarsky

unread,
Apr 29, 2008, 1:04:35 PM4/29/08
to
Bryan White wrote:
> The test case is here:
>
> http://www.arcamax.com/testcase/

Thanks! It looks like you're hitting
<https://bugzilla.mozilla.org/show_bug.cgi?id=390788>, which should really have
made it onto the branch but didn't....

-Boris

0 new messages