Closed
Bug 440572
Opened 16 years ago
Closed 16 years ago
"Permission denied to get property Window.content" when referencing frame top.content from another website
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: alex, Assigned: jst)
References
()
Details
(4 keywords)
Attachments
(2 files)
540 bytes,
application/zip
|
Details | |
3.64 KB,
patch
|
mrbkap
:
review+
mrbkap
:
superreview+
samuel.sidler+old
:
approval1.9.0.2+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 If a child frame is loaded from a different server than the parent frame, and the child frame's name is "content", any attempt to access the frame top.content using JavaScript inside the child throws a security exception. The specific error is "Permission denied to get property Window.content" This problem is new to Firefox 3.0. Previous versions do not exhibit this behaviour. Reproducible: Always Steps to Reproduce: 1. On web host 1, create a page containing a frameset with a frame named "content". The source for this frame should be a page on web host 2. 2. On web host 2, create the page referred to by #1. This page should contain JavaScript which accesses the variable top.content 3. Execute the JavaScript. Actual Results: Security exception thrown: "Permission denied to get property Window.content" Expected Results: Frame name is successfully resolved, and access granted. I have set up a pair of web hosts to demonstrate this problem. The following page creates a child frame called "content" and then proceeds to load a child frame from a different server. The child frame attempts to reference the frame called top.content, and hits a security exception: http://www.varju.ca/ff3/broken.html This exact same HTML works when the parent and child frames are on the same server: http://www.tnmc.ca/ff3/broken.html Changing the HTML slightly to use the frame name "content1", while still loading the child frame from a remote server also works: http://www.varju.ca/ff3/works.html
Reporter | ||
Updated•16 years ago
|
Version: unspecified → 3.0 Branch
Comment 1•16 years ago
|
||
Regression range is: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196739660&maxdate=1196740679 with two bugs in it, bug 406671 and bug 406692.
Blocks: 406671
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Keywords: regression,
testcase
Product: Firefox → Core
QA Contact: general → general
Version: 3.0 Branch → Trunk
Updated•16 years ago
|
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
Similar issue if a frameset references an html file of the parent directory: Open attached frameset.htm *locally* (not from a web server). Error Console shows: "Error: Permission denied to get property Location.href"
Hi, We'd like to know if the FF team considers this a bug or not as soon as possible so that we can take the necessary actions on our end to deal with this issue if it is not considered a bug and won't be fixed. Thanks.
Comment 4•16 years ago
|
||
After reviewing this with jst and sicking, current behavior in Firefox 3 is the desired behavior. Invalid.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Comment 5•16 years ago
|
||
On more discussion, there's actually an issue specific to content here. Reopening, and stay tuned.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Assignee | ||
Comment 6•16 years ago
|
||
This turned out to be a problem with the interaction between XOWs and a performance optimization that I landed for the nsWindowSH::GetProperty() hook. The reason this code works w/o this fix for names that are not also defined in our IDL interfaces for our window objects is that the XOW's resolve code ends up defining frames by their name on the XOWs and when the getProperty() hook call does nothing we simply use the values defined in the resolve hook, which is generally correct, but in the case where the name is also defined in our IDL, the IDL property ends up shadowing the already defined frame, which leads to security checks failing down the road.
Assignee: nobody → jst
Status: REOPENED → ASSIGNED
Attachment #326402 -
Flags: superreview?(mrbkap)
Attachment #326402 -
Flags: review?(mrbkap)
Comment 7•16 years ago
|
||
Johnny, is this something that should go in 1.9.0.1?
Assignee | ||
Comment 8•16 years ago
|
||
IMO it should indeed go into 1.9.0.1.
Flags: blocking1.9.0.1? → blocking1.9.0.1+
Comment 9•16 years ago
|
||
Wow. Thanks for the snappy turn around!
Comment 10•16 years ago
|
||
Comment on attachment 326402 [details] [diff] [review] Fix. Yeah, makes sense.
Attachment #326402 -
Flags: superreview?(mrbkap)
Attachment #326402 -
Flags: superreview+
Attachment #326402 -
Flags: review?(mrbkap)
Attachment #326402 -
Flags: review+
Updated•16 years ago
|
Attachment #326402 -
Flags: approval1.9.0.1?
Updated•16 years ago
|
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1-
Flags: blocking1.9.0.1+
Assignee | ||
Comment 11•16 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Attachment #326402 -
Flags: approval1.9.0.1? → approval1.9.0.2?
Comment 12•16 years ago
|
||
Comment on attachment 326402 [details] [diff] [review] Fix. Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #326402 -
Flags: approval1.9.0.2? → approval1.9.0.2+
Comment 14•16 years ago
|
||
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008082105 GranParadiso/3.0.2pre. I verified using the test sites in Comment 0.
Keywords: fixed1.9.0.2 → verified1.9.0.2
Comment 15•15 years ago
|
||
Landed before 1.9.1 branched
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•