123696 - "Permission denied" error on reloading javascript: URL

Status: VERIFIED FIXED

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

Description

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 2

[Phil Schwartau]

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

Comment 3

[Phil Schwartau]

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 -

Comment 4

[Mike Shaver (:shaver emeritus)]

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?

Comment 5

[Mitchell Stoltz (not reading bugmail)]

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?

Comment 6

[Adam Zell]

Attachment: Test case for initial error

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.

Comment 7

[Adam Zell]

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.

Comment 8

[bht237]

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);

Comment 9

[bht237]

Attachment: Framesetter with javascript: urls that throw "..uncaught exception: Permission denied.."

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.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

Futuring.

Comment 11

[bht237]

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.

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Frankie]

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?

Comment 14

[Samir Gehani]

adt: nsbeta1-

Comment 15

[Ivan Tarapcik]

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.

Comment 16

[Asa Dotzler [:asa]]

->brendan

Comment 17

[Brendan Eich [:brendan]]

Probable dup of bug 206026.

/be

Comment 18

[Frankie]

shouldn't that be vice versa?

Comment 19

[Brendan Eich [:brendan]]

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

Comment 20

[Brendan Eich [:brendan]]

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

/be

Comment 21

[Adam Zell]

Attachment: Changing iframe src causes error on soft reload.

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.

Comment 22

[Johnny Stenback (:jst)]

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?

Comment 23

[Adam Zell]

Agreed.  Works correctly under Windows 1.4b.

Comment 24

[Stephen Donner [:stephend] Not actively reading bugmail]

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?

Comment 25

[Stephen Donner [:stephend] Not actively reading bugmail]

Reopening.  Please see comment 24, above.

Comment 26

[Brendan Eich [:brendan]]

This ain't my baby.  I agree it should be fixed.  Jst, peterv, any ideas?

Maybe a new bug should have been filed.

/be

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

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?

Comment 28

[Boris Zbarsky [:bzbarsky]]

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.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Attachment: A test

Comment 30

[Boris Zbarsky [:bzbarsky]]

Landed the test.

Comment 31

[Stephen Donner [:stephend] Not actively reading bugmail]

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 :-)

Comment 32

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

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"

Comment 33

[Boris Zbarsky [:bzbarsky]]

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.