Closed Bug 163410 Opened 22 years ago Closed 15 years ago

JavaScript error: "Security Error: Content at http://{xxx} may not load data from {yyy}."


(Core :: Security, defect)

Not set





(Reporter: sascha, Assigned: dveditz)




(Keywords: regression)

Mozilla 1.1b exhibits this behaviour that Javascript restricts the access from a
page located on "" to another document located at "".
This worked with Mozilla 1.1a and all earlier versions.

The full error message on the Javascript console:

Error: uncaught exception: Security Error: Content at may
not load data from

When I select copy, the string "PAagpI32" is copied.

The scenario consists of a input form and a Javascript "framework" which are
handled/generated by two distinct web servers on the same machine.
Reassigning to Security:General; cc'ing dveditz -
Assignee: rogerl → mstoltz
Component: JavaScript Engine → Security: General
QA Contact: pschwartau → bsharma
I very much believe this to be the intended behavior. This is also the actual 
and implemented behavior of Internet Explorer since at least 4.0:

"About Cross-Frame Scripting and Security"

Scripting between pages is explicitly forbidden when these pages are not on the 
same protocol, domain and port.
The text at the referenced URL does not even mention the word "port". Further
evidence is the fact that MSIE executes the Javascript as expected without any

The documents are all loaded from the same domain (*

According to the URL you quoted, "The range of permissible access for a page can
be expanded when a script assigns the document.domain property to a suffix of
the site name space [..]"

Well, we do that and it has stopped to work in Mozilla 1.1. It works in Mozilla
1.0 and earlier, as well as MSIE/NS 4+.

if (navigator.appCodeName == 'Mozilla' 
       && parseFloat(navigator.appVersion) >= 5.0)
    document.domain = '';
Because of the ability to abuse document.domain to spider inside someone's
firewall (bug 154930) document.domain was changed to require *both* pages
involved to set the domain explicitly or you do not get the expanded access.
Microsoft has said that they also will be taking this approach when they release
SP1 for IE 6.0, and the page Thor referenced implies that.

In many cases document.domain had to be set on both pages anyway (pages from and, but for pages which otherwise inherit the correct
document.domain value you'll have to explicitly set it, as a kind of signal "I'm
willing to share my data with my subdomain".
The site is working correctly with Mozilla 1.2a, so I assume that the bug has
been fixed since 1.1a. Thanks!
Closed: 22 years ago
Resolution: --- → FIXED
Marking verified as per above developer comments.
This bug has resurfaced in Mozilla 1.2.1.  This might be related to the
(unusual?) code flow.

The JS console displays:

Error: uncaught exception: Permission denied to call method HTMLDocument.writeln

All involved documents contain these lines:

    if (navigator.appCodeName == 'Mozilla'
            && parseFloat(navigator.appVersion) >= 5.0)
        document.domain = '';

1. invokes a function in the top frameset, loaded from This works.

2. The called function ( starts a timer

    top.setTimeout("go_real()", 200);

This works too.

3. The function go_real (from tries to modify the contents of a
frame. This raises the above exception.;
    window.display.document.writeln(buf); <-- exception here

The frame window.display was loaded from
Resolution: FIXED → ---
As an addendum, Mozilla 1.3a exposes the same behaviour.
(In the following case, only the domain changes, protocol and port are unchanged.)

	** Expected behaviour

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312]
 [Also: "Netscape® Communicator 4.8" (en, 20020722)]

G1. <>
   (redirects to <>)
G2. Click on OPCVM in the left menu (=
G2a. A new window opens (empty for now)
G2b. Prompts for outdated (2003.02.26) certificate: Click "OK"
G2c. Prompts for secure/insecure mix: accept it
   (redirects to

G3. In upper left (of the new window), search for "afer"
G4. A new window opens:

	** Broken behaviour

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4b) Gecko/20030507]

B2a-B2b. The new windows briefly opens, and closes immediately.

JS Error:
Security Error: Content at may not
load data from about:blank.

B3. In upper left (of the initial window), search for "afer"
B4. A list of 3 items is displayed on the right: click any of the links.

B4a. get JS Error:
Security Error: Content at
may not load data from about:blank.

B4b. Repeat step B4

First, you get G2a and G2b, then B4a instead G2c.

NB: In fact, repeating B4, either lead to B4a or B4b "at random".


I already add "4xp" keyword, and change OS from 'Linux' to 'All';
and only wait a little before adding 'Regression' keyword, upping Severity to
'Major', and confirming ('New') bug.

From the comments so far:
 *up to v1.1a/Linux: Works
 *v1.1b/Linux: Broken
 *v1.2a: Works
 *v1.2.1: Broken
 *v1.3a: Broken
 *v1.3/W95: Works
 *v1.4b/W95: Broken

The Works <-> Broken changes by themselves are very odd !
Then we'll have to settle for which behaviour we should actually have...

I can already say that if "Broken" is the intended behaviour, the JS Error is
not enough for a end user, we need a popup to tell what is going on (with may be
a checkbox to accept the security risk).
Or, at the very least, to add a sentence to the JS Error like "Contact the
Webmaster to have him redesign its site(s) behaviour according to xxx policy".

I'll test later (= tomorrow for me) with IEv6sp1/W2K.!.
Keywords: 4xp
OS: Linux → All
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507]

Addition to comment 9:

Confirming testcase on W2K.

Case B4b may be a timing consequence on my slow W95 computer:
I don't see it with my fast W2K.

--> MsIE v6.0sp1 (on W2K): follow the Expected behaviour (= G case) !! <--

Severity: Normal -> Major
Summary: (text update)
Keywords: adding Regression
Flags: blocking1.4?
Status: Unconfirmed -> New
Severity: normal → major
Ever confirmed: true
Flags: blocking1.4?
Keywords: regression
Summary: Security Error: Content at domain.dom may not load data from domain.dom:9000 → JavaScript error: "Security Error: Content at http://{xxx} may not load data from {yyy}."
not seeing this problem in high-profile sites or reported frequently. not going
to block 1.4 for this.
Flags: blocking1.4? → blocking1.4-
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3.1) Gecko/20030425]

v1.3.1 works fine, as v1.3 does. (with v1.3 profile, at least)
Is there a setting that can be modified to allow pages from http://blah1 (xml
pages) to have access to pages from http://blah2 (xsl stylesheets) (like the one
in IE)?  This a critical issue for us!
Re: comment #13: can you give real examples of the two domain names?  Would it
help if they both ended in .com, and a script in each page were to set
document.domain = "com"?

This happens with's javascrip messenger window.   Briefly opens a
blank placeholder popup window then dissapears.   Javaconsole shows this error:

Security Error: Content at
may not load data from about:blank.
Re: comment 14
For an example of xml rendering where xml & xsl files are from different
domains, see
(both are domains)
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624] (v1.4rc3)

Bug still there. (case B2a-B2b)
Addition to comment 17:

In v1.4rc3 at least, it seems that while I get the errors, the pages are not
actually blocked !

(This is another testcase, even if it may not last too long: since the
europerformance site seems broken since a few days.)

1. <> (with cookies-JS prefs on)
2. click on the 'ISIN' link (in bottom left frame)
3. the page does load in a new window, after getting the error:
Security Error: Content at may
not load data from

That's surprising ... but, at least, it should allow me to actually stop using
v1.3.1 (besides bug regression tests) :-)
Addition to comment 18, and update of comment 9:

I confirm that v1.4rc3/v1.4 do load the pages, even if they still generate the
JS messages. (This behaviour changed _after_ v1.4b...)

New URLs (a '3' has been added) and messages are:

Security Error: Content at may not
load data from about:blank.
Security Error: Content at may not
load data from

4) <>
Security Error: Content at may not
load data from about:blank.
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030925] (v1.5rc2) (W98SE)

Bug still there (as in comment 19): confirming on W98SE.

Security Error: Content at|702439
may not load data from about:blank.
Recent reports here involving (comment 15 onward) seem likely to be
dups of bug 220421.

Re comment 21:

Agreed: reproduced with both cases in bug 220421 comment 2 testcase.

Adding (at least untill I can check v1.5_final):
*(Depends on): bug 220421
Depends on: 220421
Try today's trunk build, the patch landed there first.

Depends on: 238093
Assignee: security-bugs → dveditz
QA Contact: bsharma → toolkit
I have the same problem with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210 GranParadiso/3.0a7

And Firefox 3 can't import a external xml file in xsl stylesheet via document() function.

<xsl:variable name="i18n" select="document('http://myServer/myFile.xml')" />

In the error console I have this message:
Security Error: Content at about:blank may not load data from http://myServer/myFile.xml.

It works well for Firefox version >=1.5
Why is it a security problem for Firefox 3?

Thanks for your answer.
I think this got fixed.

Comment 24 is a different problem because some of the handling for about:blank pages was changed. If that's still a problem it needs to go into a new bug.
Closed: 22 years ago15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.