I'm pretty sure this isn't JS Engine, so please re-assign as needed, thanks. (Perhaps this should go to Nav?) Build ID: 2002-02-04-09, Windows 2000. URL: javascript: d = new Date(); Steps to Reproduce: 1. In Mozilla, type javascript: d = new Date(); 2. Hit Reload. Expected Results: On both IE 6 and Netscape Navigator 4.79, we keep displaying the updated string of the Date object in the window. Actual Results: Error: uncaught exception: Permission denied to set property Window.d In Mozilla, we won't display the current time string until you hit enter in the URL field of the browser.

After the excellent presentation by Phil last week, I tried getting stack information for the variable d which holds the date object in the JS debugger, but nothing is showing up, after hitting return in the URL field, or hitting reload.

Good point - the JS Debugger can't handle javascript: URLs yet... Confirming this bug with any javascript: URL like Stephen's above. For example, I tried this one: 1. Type javascript: s = "Hello"; 2. Hit Reload And got: Error: uncaught exception: Permission denied to set property Window.s As Stephen says, re-hitting Enter gives no problem; only hitting Reload. I also observed that putting the |var| keyword in removes the error: javascript: var d = new Date(); javascript: var s = "Hello"; If you hit Reload on these, you don't get the error! Reassigning to Security:General; also cc'ing jst

I'm puzzled: many aspects of the browser's behavior are different whether or not the |var| keyword is used in the javascript: URL. Why? Syntactically, there is not much difference whether you include |var| or not: it creates a global variable in either case -

A |var| indicates a variable declaration (with initialization, here), which has no value as an expression. Without the var, it's an assignment, which has as expression-value the new value of the assigned-to variable. When there is no |var|, and therefore a value is returned from the script execution, then I believe we generate a document containing the stringification of the result. I suspect that document has a unique domain-principal-thingy, and on reload the new and unique one doesn't match (of course). Most of the behaviour here is what we want: stringification iff there is an expression returned is long-standing Mozilla-family browser behaviour, if not universal. I think the problem may just be in the principal matching between two javascript:-generated documents. But then, it's 0215 and I've been up too long, so I could probably be convinced to think it's caused by the mating habits of HB pencils, too. Mitch? Vend us a clue?

Mike, You've got it. Typing javascript: s = "Hello" in the URL bar defines a variable s on the Window object, then loads a new document containing "Hello." This looks like a bug, because the "Hello" document should have the principal of the previously displayed page, I think, and so should any subsequent documents created by javascript: URLs in the URL bar. However, I think this is a wontfix, or a low-priority bug at least, unless you think this interferes with any real-world applications. What's your opinion on the severity of this problem?

This page demonstrates the permission error when first loaded. When the page is subsequently loaded (either through the menu bar or the File menu), there are no longer permission problems.

In order to minimize the number of "Permission denied" messages generated when setting frame sources to javascript urls, I have found that one must set the initial source of the frame to javascript:void(0). Then, the frame's src must not be modified until either onload has fired, or window.stop() has been called. At this point, it is same to reassign the frame's src without causing an error on reload (ex: myFrame.src = 'javascript:parent.myFunction();'). However, there is always a permissions error *the first time* the page is reloaded: Error: uncaught Exception: Permission denied to get property Window.parent If I do a hard refresh, either through the Address bar or the File menu, subsequent soft reloads do not complain of permission exceptions. I am not sure why the first load causes this, but following loads do not.

I get a similar problem, definitely after Mozilla 1.0. My scenario is: 1) Version: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1b) Gecko/20020717 2) Error message in JavaScript console: "Attempt to load a javascript: URL from one host in a window displaying content from another host was blocked by the security manager." 3) Conditions: - After creating new profile and clearing cache. - Not always reproducible but most of the time. 4) Expected result: Frames loaded with JavaScript generated content 5) Actual result: White flickering frames. Subsequent loading with other content is successful. 6) Pseudo code similar to real life code (not a testcase): var otherHTML ="someOtherHTML"; function someFunction(parm){ return "SomeHTML" + parm; } var s='<FRAMESET rows="117,*,45" frameborder=0 framespacing=0 border=0 onload=init()>'; s+='<FRAMESET cols="1000%,*,*,*">'; s+='<FRAME src="javascript:top.someFunction(top.otherHTML)" name=frame1 scrolling=no marginwidth=1>'; s+='<FRAME src="javascript:top.someFunction(top.otherHTML)" name=frame2 marginwidth=1>'; s+='<FRAME src="javascript:top.someFunction(top.otherHTML)" name=frame3 marginwidth=1>'; s+='<FRAME src="javascript:top.someFunction(top.otherHTML)" name=frame4 marginwidth=1>'; s+='</FRAMESET>'; s+='<FRAME src="javascript:top.someFunction(top.otherHTML)" name=frame5 scrolling=auto marginwidth=1>'; s+='<FRAME src="javascript:top.someFunction(top.otherHTML)" name=frame6 scrolling=no marginwidth=1 marginheight=1>'; s+='</FRAMESET>'; document.write(s);

The testcase should display a black "page". In my case if I load it from the local filesystem, I get one exception for each frame and a white page. Netscape 4, IE etc. are ok.

Futuring.

Future?. I am confused. How can this slip through as future? Where is QA? This is a nasty regression that so far has not appeared in any previous milestone/release.

This should be fixed, it's a bad regression from years' worth of shipping browsers that had and (IE) have market share. Correct me if I'm wrong and IE does not faithfully implement what JS has done from Nav2.0-4.x. When did this regress, anyway? /be

This bug also interferes with quite a few Bookmarklets, such as my AutoGoogler. With spaces added between statements for formatting and clarity: javascript:q=(document.getSelection)? document.getSelection(): document.selection.createRange().text; for(i=0;i<frames.length;i++) {if(q)break; q=(document.getSelection)? frames[i].document.getSelection(): frames[i].document.selection.createRange().text;} if(!q)q=prompt('Search',''); location='http://www.google.com/search?q='+escape(q) I use this all the time for quick lookups. But in recent builds (probably after the switch to Mach-O), I can no longer go either Back or Forward to my Google results. "Error: uncaught exception: Permission denied to set property Window.q" I've tried throwing void() statements around various parts, with no effect. If this bug is going to be Futured for a while, could someone tell me a workaround that will fix my bookmarklet?

adt: nsbeta1-

setting blocking 1.4?, since this error didn't occure to me in version 1.3 error occures when function in frame loaded from pokecp.azet.sk function KopniUsera(param) { window.parent.panel.location.href='http://pokecps.azet.sk/in.p?i9=177a605d21ac9bb82cfdbf42bedadcc3&u='+param; } want to set location of frame loaded from www.pokec.sk Error: Error: uncaught exception: Permission denied to get property Function.href ----- I'm curios why this worked in 1.3 and does not in 1.4. If there is some new security restriction, there should be GUI alert and pref to disable it. ---- Another error in JS console (probably caused by JS trying to open some sort of popup): Security Error: Content at http://pokecs.azet.sk/pokec.phtml?i9=177a605d21ac9bb82cfdbf42bedadcc3&lok=5 may not load data from http://rp.azet.sk/fposta.phtml?i9=177a605d21ac9bb82cfdbf42bedadcc3&i=1052768970.

->brendan

Probable dup of bug 206026. /be

shouldn't that be vice versa?

I didn't mark the dup yet. "probably dup of" is a symmetric relation, anyway. What's more, sometimes "dup'ing forward [toward the higher bug number]" wins. /be

jst and I have tested this. It works for us. Someone give more precise instructions if a bug remains here. /be

Problem still occurs. Changing an iframe's src from an initial javascript: url to another javascript: url causes errors on refresh. Enclosing test case, which IE handles.

I get the same behaviour in both IE and Mozilla with that testcase, both on Windows and Linux, builds from yesterday. What build are you using?

Agreed. Works correctly under Windows 1.4b.

Brendan, Johnny, I now get this: Error: uncaught exception: [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: javascript: d = new Date() :: <TOP_LEVEL> :: line 1" data: no] when doing: javascript: d = new Date(); in the URL bar. and the string "Fri Jun 04 2004 02:28:43 GMT-0500 (US Eastern Standard Time)" isn't updated as it is in IE, such as: Fri Jun 4 02:29:22 EST 2004 (reload) Fri Jun 4 02:29:23 EST 2004 IE seems to update down to seconds... Reopen? Or file a new bug on the exception thrown?

Reopening. Please see comment 24, above.

This ain't my baby. I agree it should be fixed. Jst, peterv, any ideas? Maybe a new bug should have been filed. /be

All testcases seem to be working fine for me now with build 2006-06-19-10 of SeaMonkey trunk under Windows XP. Can anyone hazard a guess at which bug(s) fixed this?

The patch in bug 389274 fixed this (though that landed after stephend's comment, so I dunno what the deal there was). Leaving open for now pending me writing a test.

Landed the test.

Verified FIXED using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090720 Minefield/3.6a1pre; sorry it took so long :-)

Any ideas why eagerly generating the about:blank doc in newly-created docshells would break the test here? ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug123696.html | Reload should have reloaded correctly! - got "change", expected "change2"

Presumably either session history gets confused about which thing it should be reloading or something else goes awry.... My bet is on the session history thing.