Closed Bug 37702 Opened 25 years ago Closed 25 years ago

self.frame1.document.open() --> "Access to property denied"

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bht237, Assigned: security-bugs)

Details

(Whiteboard: [nsbeta3+])

Attachments

(4 files)

Test case
1.58 KB, text/html
Details
slightly simplified testcase for self.frame1.document.open()
399 bytes, text/html
Details
break in JS_ReportError, full stack trace, build from 7/2
15.29 KB, text/plain
Details
testcase for self.frame1.location="..."
298 bytes, text/html
Details
A javasript:'...' URL normally initialises a dynamic window/document object in a frame instead of loading a dummy HTML file e.g. "blank.htm" over the network. <FRAME name=A1 src="javascript:'<BODY bgcolor=#FFFFFF></BODY>'"> This works with all major JavaScript capable browsers (including HotJava 3.0) Although JavaScript functions don't appear to get executed within the scope of <FRAMESET...</FRAMESET, the "javascript:" URL appears to get passed on as a literal and executed in the same way as if it was typed in the location field: Type "javascript:'<BODY bgcolor=green>'" and you get a green window. See attached test case
Attached file Test case —
over to DOM for a look.
Assignee: asadotzler → jst
Component: Browser-General → DOM Level 1
QA Contact: jelwell → gerardok
QA Contact: gerardok → desale
Confirming bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Looks like this doesn't work due to the security problems with javascript: url's, reassigning to mstoltz@netscape.com
Assignee: jst → mstoltz
OS: Windows 95 → All
Hardware: PC → All
Is this a dup of bug 31818? /be
*** This bug has been marked as a duplicate of 31818 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Reopening. This can't be a duplicate because bug 31818 is verified fixed. On PC/Linux, build 2000070721, the behaviour of the attached testcase still differs from the 4.x behaviour. Adding 4xp keyword. Also nominating for nsbeta2. See comments from bht@actrix.gen.nz in bug 39176 for the reasons.
Status: RESOLVED → REOPENED
Keywords: 4xp, nsbeta2
Resolution: DUPLICATE → ---
The security aspect has been fixed (I think) so I'm bouncing this back to DOM. If I'm wrong, please send it back.
Assignee: mstoltz → jst
Status: REOPENED → NEW
QA Contact: desale → gerardok
Putting on [nsbeta2-] radar. Not critical to beta2. Please give specific reasons in this bug and renominate if you think this is critical for beta2. Bug 39176 was a crash bug and this one is not.
Whiteboard: [nsbeta2-]
Not a crash. Right. But I can't test 39176 without this one fixed. Please see my comments in 39176. So it's a blocker for me. I have logged 39176 AND this and BOTH were by mistake marked duplicates of other bugs. I can only offer my help as a tester and suggest to fix this one before the beta comes out. That way I can help verify that the JavaScript window.location problem is fixed. And if there are indeed other location bugs, then it is VERY likely that I will find them with little effort. If these are then not fixed before the beta - fine. But at least beta bugs then can be marked duplicates and a lot of extra analysis work is avoided.
changing severity to "blocker" based on reporters comments.
Severity: normal → blocker
CC self. jpatel@netscape.com wrote: > Please give specific reasons in this bug and renominate if you think this is > critical for beta2. Re-nominating. See comments from bht@actrix.gen.nz above (in *this* bug). As far as I understand it, the specific reasons are: - Some real-world complex sites use javascript in a cross-browser way. - Because of bugs in other browsers, they can only use the simplest commands. - Currently even these simple commands don't work with mozilla (-> this bug). - So these sites can't test mozilla. - The whole purpose of beta is testing mozilla with real-world sites. --> Conclusion: This bug is critical for beta.
Whiteboard: [nsbeta2-]
The newly added testcase creates two frames, one black and one white. The frameset onload handler then paints one of them red using self.frame1.document.{open,write,close} : <HTML> <HEAD> <SCRIPT> function ini() { self.frame1.document.open(); self.frame1.document.write('<BODY bgcolor=red />'); self.frame1.document.close(); } </SCRIPT> </HEAD> <FRAMESET rows="50%,*" onload="ini()"> <FRAME name="frame1" src="javascript:'<BODY bgcolor=black />'" /> <FRAME name="frame2" src="javascript:'<BODY bgcolor=white />'" /> </FRAMESET> </HTML> This works in 4.x, but mozilla keeps the black & white frames and prints this: JavaScript error: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11462 line 5: JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11462 Line: 5"] Re-assigning to mstoltz@netscape.com because it still looks like a security problem. If you need further information, please tell us how we can help. Note that the following replacement for self.frame1.document.{open,write,close} works fine even with mozilla: self.frame1.document.location="javascript:'<BODY bgcolor=red />'"; Also note that alert(self.frame1.document.open); works fine and displays function open() { [native code] }
Assignee: jst → mstoltz
Re-summarizing from <FRAME src="javascript:'...'" attribute does not init window to self.frame1.document.open() --> "Access to property denied"
Summary: <FRAME src="javascript:'...'" attribute does not init window → self.frame1.document.open() --> "Access to property denied"
I forgot: Testing was done on PC/Linux, build 2000071408. By the way, a similar problem is described in bug 45099: Javascript "Access to property denied" exception
Putting on [nsbeta2-] radar. Not critical to beta2. If you know of any top100 sites that show this behavior, please list them and renominate.
Whiteboard: [nsbeta2-]
QA Contact: gerardok → desale
Top 100 sites, in fact all commercial sites must use the lowest common denominator of even the most fundamental browser features. Why beta if a fundamental feature supported by IE3, HotJava 3, NN3, NN4 does not work here? I can offer Netscape highly relevant test cases for bugs that will never be encountered in "top 100" sites but I cannot do this if fundamental version 3 features are not supported. In this case there is no workaround because it is just too fundamental. I will hit another bug if I remove the code for this. JavaScript with frames in browsers is in a real mess and I would hate to see another problem added to the mix.
I'm looking at it.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
I tried to debug this a little on a PC/Linux build from 7/2: nsScriptSecurityManager::CheckPermissions is called, see http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#1487 The SubjectPrincipal and the ObjectPrincipal are saved in `subject' and `object' (both are non-null), and in line 1500 we discover that they are different. Thus we proceed calling subjectCodebase->SameOrigin(object, &isSameOrigin) in line 1506, which returns false. Since "about:blank" doesn't have anything to do with our case, and we aren't a signed script, we proceed further and end up calling JS_ReportError in line 1541. So the first question is: where in this function should we discover that in this case the permissions are ok? subject == object or SameOrigin() ? All I know is that nsAggregatePrincipal::SameOrigin is called, which calls nsCodebasePrincipal::SameOrigin (see http://lxr.mozilla.org/seamonkey/source/caps/src/nsCodebasePrincipal.cpp#164 ), which returns false because in line 191 the two schemes are different: scheme1 = "javascript" scheme2 = "http"
I was wrong in one of my comments above: self.frame1.location="..." has the same problem.
Andreas, We should be seeing SameOrigin == true in ScriptSecurityManager. The object codebase should not be "javascript:..." but rather the URL of the page which loaded the Javascript URL (the frameset). I'm tracking down where this codebase gets assigned; there's probably a case (involving frames) where we fail to set it correctly. Javascript URLs are supposed to inherit principals from the referring page; that's not happening here.
Nominating nsbeta3.
Keywords: nsbeta2 → nsbeta3
Whiteboard: [nsbeta2-]
Whiteboard: [nsbeta3+]
Trouble: I don't see JS_ClearWatchPointsForObject being called on the window object before each document load: http://lxr.mozilla.org/mozilla/search?string=ClearWatchPointsForObject It should be, or this bug and others will bite. Mitch, where do you see a clear issuing from -- what's the full backtrace? /be
Sorry, I updated the wrong bug -- please ignore my last commment, it is now in bug 38959 where it belongs. /be
I am encountering this same problem with a web site that I created several years ago. The site has been working fine for NS3.x, NS4.x, IE4.x, IE5.x. It has worked fine on Mozilla up until M17. Then it stopped working. It doesn't even work in file mode. I agree with the comment by "bht@actrix.gen.nz" on 2000-07-17 16:05: "Why beta if a fundamental feature supported by IE3, HotJava 3, NN3, NN4 does not work here?" This is a major bug that should be corrected before the beta. Otherwise the beta will be useless to me (and, I'm sure, others).
Fix checked in, maring FIXED. Chris, can you help us out by posting a reproducible sample of the code that isn't working for you? THis will help us make sure that we've fixed the problem. Thanks.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You can use the example at the following URL for testing: http://www.geocities.com/cplarosa/Images/Planets/index.htm This is not a simplified test case, but it does clearly reproduce the problem. After going to the URL above, simply click on the link "earth.jpg". This is supposed to open a new window and display a picture of the earth with a control panel for advancing through the pictures. In Mozilla M17, the window opens and the control panel is displayed properly, but the picture is not displayed. In all other browsers (including previous Mozilla milestones), the picture is displayed properly. Sorry about all the pop-up windows that GeoCities adds, but there's nothing I can do about that. I hope this helps. If you need me to create a more simplified test case, I can try to do that.
A reduced testcase would definitely help. Should this bug be REOPENED? Thanks, /be
I ran my example on the latest nightly build (Build ID: 2000081508) and it works! It looks like the bug has been fixed.
Verified fixed - using Mozilla tip builds 2000-08-15 on WinNT, Linux; Mac commercial build 2000081413 Verified all three attached testcases, plus the geocities URL given above at comment 2000-08-15 12:54. Note that geocities uses layers at one point, which are not supported by Mozilla. That is why this URL shows an error in the JavaScript console : JavaScript error: http://a372.g.a.yimg.com/f/372/27/1d/www.geocities.com/js_source/ygNSLib6.js line 46: document.yl0 has no properties (The element "yl0" is a LAYER element.) This is unrelated to this issue, and is not a bug ... Verified fixed -
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: