Last Comment Bug 317366 - Cross frame scripting to nested iframe from same domain fails. Was working in earlier versions
: Cross frame scripting to nested iframe from same domain fails. Was working in...
: fixed1.8.0.4, regression, testcase, verified1.8.1
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
P3 major (vote)
: mozilla1.9alpha1
Assigned To: Blake Kaplan (:mrbkap)
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2005-11-21 17:28 PST by Marcus Doemling
Modified: 2006-10-11 09:58 PDT (History)
13 users (show)
dveditz: blocking1.8.1+
dveditz: blocking1.8.0.1-
dveditz: blocking1.8.0.2-
dveditz: blocking1.8.0.4+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix (1.29 KB, patch)
2006-03-23 22:52 PST, Blake Kaplan (:mrbkap)
jst: review+
jst: superreview+
jst: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Splinter Review

Description User image Marcus Doemling 2005-11-21 17:28:23 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

There is a nested IFRAME with the following setup:

   Main page (domain A)
      -> IFRAME 1 (domain B)
          -> IFRAME 2 (domain A)

Cross frame scripting from the main page to IFRAME 2 should be possible but fails. In past Firefox versions this was possible and IFRAME 2 could be accessed e.g. via top.frames[0].frames[0]. This worked despite the fact that scripting from main to IFRAME 1 was not possible. Now trying to access the frames[0] property of top.frames[0] causes an exception. The exception caused is "Permission denied to set property Window.0". Note that it says "set" not "get".

Since both the main page and FRAME 2 are from the same domain they should be allowed to do cross scripting!

Reproducible: Always
Comment 1 User image Martijn Wargers [:mwargers] 2005-11-22 01:55:20 PST
Could you attach a testcase or give an url that shows the bug?
Comment 3 User image allan mcdougall 2005-11-30 12:02:47 PST
Similar problem with cross frame scripting with FF 1.5

Frameset set hosted on client's machine, content frames from our server.

FRAMESET (domain A)
 - FRAME 1 (domain B)
 - FRAME 2 (domain B)

Communication between FRAME 1 and FRAME 2 now reports "Permission denied to set property Window.0" , worked in previous firefox versions where frame 1 and frame 2 had same document.domain .
Comment 4 User image Andrew Zhuravok 2005-12-02 04:27:14 PST
Hello All

We have found this problem in FireFox 1.5 (rather our customers have submitted it).

Same problem (as described earlier) appears in frameset:
If the frameset is in and frames are in domain.two an attempt to access frame1 from frame2 (and any other combination) will generate - Error: uncaught exception: Permission denied to set property Window.X. (You can test it at - just click any "try" button and open JavaScript console to review the error – only in FireFox 1.5 – no exception in any previous versions)

It looks like the problem is in frames collection of window. It seems that in IE, Safari and all previous versions of Mozilla this collection is some kind of "public": attempt to access to other properties of the parent window generate an "access denied", but access to frames collocation always success.

It seems that the same problem was already happens when Netscape released version 4.5 of their browser – that version have same problem as described above and this problem was fixed very soon in version 4.51.

The bug was reproduced on Windows/Linux/Macintosh, - I assume it exists on all platforms.

So I have some questions to developers: is this bug has enough importance? Is there plans to fix it soon or we need update our application to separately support this version of FireFox browser (not a good idea, IMHO)? What are the plans for further versions of FireFox browser  - do these versions will have a cross-domain/cross-frame navigation ability or it will be disabled as in version 1.5?

Andrew Zhuravok
AOL: azhuravok
ICQ: 18688386
Comment 5 User image Daniel Veditz [:dveditz] 2006-01-04 11:03:01 PST
This is clearly a bug and a regression, but I'm not sure it rises to the level of blocker.
Comment 6 User image Daniel Veditz [:dveditz] 2006-02-07 15:59:16 PST
blocking denied, not a regression, no trunk-baked patch.

We can reconsider if a safe patch appears.
Comment 7 User image Marcus Doemling 2006-02-09 09:29:40 PST
I found another clue for this bug. When accessing the nested iframe using the iframe name instead of the index the access works! With the following setup:

   Main page (domain A)
      -> IFRAME 1 (domain B)
         -> IFRAME 2 (domain A)

The access from IFrame 1 to IFrame 2 works when using the name of IFrame2,
the exception occurs when using the IFrame index (window.frames[0]). The access from the main page to IFrame 1 can be done either way.

Here is another test page showing both IFrame access versions:

Hope this will help somebody to find the cause and fix it.
Comment 8 User image Darin Fisher 2006-03-23 09:05:09 PST
jst: Is this something you plan on fixing for  Is it something you think we should try to fix?  Any suggestion on who might be able to help?
Comment 9 User image Blake Kaplan (:mrbkap) 2006-03-23 22:47:24 PST
This is easy to fix.
Comment 10 User image Blake Kaplan (:mrbkap) 2006-03-23 22:52:50 PST
Created attachment 216086 [details] [diff] [review]

Compare this code to the code that resolves frame names as opposed to indices.
Comment 11 User image Johnny Stenback (:jst, 2006-03-23 22:57:12 PST
Comment on attachment 216086 [details] [diff] [review]

Yeah, this is what we want. r+sr=jst
Comment 12 User image Blake Kaplan (:mrbkap) 2006-03-24 10:38:25 PST
Fix checked into trunk.
Comment 13 User image Darin Fisher 2006-04-10 12:19:17 PDT
mrbkap, jst: Can you guys comment on the risk associated with this patch?  Also, it'd be good to land this on the MOZILLA_1_8_BRANCH to maximize bake time before we take this on the MOZILLA_1_8_0_BRANCH.  Thanks!
Comment 14 User image Blake Kaplan (:mrbkap) 2006-04-10 13:18:05 PDT
(In reply to comment #13)
> mrbkap, jst: Can you guys comment on the risk associated with this patch? 

This patch should be extremely safe. It uses pre-existing code to disable overly cautious security checks during a call into the JS engine. There is similar code a couple of lines down (that also can act as a workaround for this bug). This doesn't open any security holes, since the call into the JS engine will not run any user code, and we're defining a known property with a known value.
Comment 15 User image Blake Kaplan (:mrbkap) 2006-04-11 13:30:35 PDT
Fix checked into the 1.8 branch.
Comment 16 User image Daniel Veditz [:dveditz] 2006-04-19 12:10:22 PDT
Comment on attachment 216086 [details] [diff] [review]

approved for 1.8.0 branch, a=dveditz for drivers
Comment 17 User image Blake Kaplan (:mrbkap) 2006-04-21 13:48:55 PDT
Checked into the 1.8.0 branch.

By the way, thanks for the great testcases, Marcus.
Comment 18 User image Bob Clary [:bc:] 2006-10-11 09:58:29 PDT
verified 1.8 20061010 1.9 20061011 windows/linux on both testcases.

Note You need to log in before you can comment on or make changes to this bug.