Closed Bug 440572 Opened 12 years ago Closed 12 years ago
"Permission denied to get property Window
.content" when referencing frame top .content from another website
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.
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.
After reviewing this with jst and sicking, current behavior in Firefox 3 is the desired behavior. Invalid.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
On more discussion, there's actually an issue specific to content here. Reopening, and stay tuned.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Johnny, is this something that should go in 220.127.116.11?
IMO it should indeed go into 18.104.22.168.
Flags: blocking22.214.171.124? → blocking126.96.36.199+
Wow. Thanks for the snappy turn around!
Comment on attachment 326402 [details] [diff] [review] Fix. Yeah, makes sense.
Attachment #326402 - Flags: approval188.8.131.52?
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Attachment #326402 - Flags: approval184.108.40.206? → approval220.127.116.11?
Comment on attachment 326402 [details] [diff] [review] Fix. Approved for 18.104.22.168. Please land in CVS. a=ss
Attachment #326402 - Flags: approval22.214.171.124? → approval126.96.36.199+
Fix landed in CVS.
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52pre) Gecko/2008082105 GranParadiso/3.0.2pre. I verified using the test sites in Comment 0.
Landed before 1.9.1 branched
Flags: blocking1.9.1? → blocking1.9.1+
You need to log in before you can comment on or make changes to this bug.