Permission Denied when accessing window.closed

[alistair_henderson]

Morning All,

I have some code for a website which uses 'window.open' to simulate
modal dialog boxes. I use the window.closed property to decide if the
window object exists at various points. This has been fine until last
week when I started getting javascript 'Permission Denied' errors when
I try to access this property.

I suspect that a windows update has caused this somehow, as this code
has not changed for a very long time. Can anyone confirm if there have
been any windows updates that would cause this? Maybe some browser
security settings have subtely changed, or something?

Its not a huge problem, as I already had my own 'closed' flag to check
as window.closed was not reliable in IE5 anyway, so I may just stop
using window.closed entirely. I would like to be abel to explain the
sudden appearance of the error, though..

Thanks,
Alistair.

[jamesdcunningham]

I am encountering the same thing and I found that when I removed a
recent windows update, Cumulative Security Update for Internet Explorer
for Windows XP (KB918899), the issue went away. Of course, that is not
an option I can present to our clients.

In my scenario the error is being thrown when I check the window.closed
property for a pop-up in a timer interval loop. After the pop-up is
reported as closed the opener then runs a function using the data from
the pop-up.

Playing with the javascript I found that if I delayed checking the
closed property for about 1 second then the closed property reported
back correctly that it was closed. Also, before the pop-up was closed
the property correctly reported back that the window was not closed.

I use this routine,
if (dialog && !dialog.closed) dialog.focus();
in many places to make my pop-ups behave somewhat like a modal dialog
and I would love to hear if there is a security setting or other option
available to avoid the Permission Denied error now that it has become
an issue within IE 6.0.29.

Any insights would be appreciated. Thanks,
James

al****************@email.com wrote:

Morning All,

I have some code for a website which uses 'window.open' to simulate
modal dialog boxes. I use the window.closed property to decide if the
window object exists at various points. This has been fine until last
week when I started getting javascript 'Permission Denied' errors when
I try to access this property.

I suspect that a windows update has caused this somehow, as this code
has not changed for a very long time. Can anyone confirm if there have
been any windows updates that would cause this? Maybe some browser
security settings have subtely changed, or something?

Its not a huge problem, as I already had my own 'closed' flag to check
as window.closed was not reliable in IE5 anyway, so I may just stop
using window.closed entirely. I would like to be abel to explain the
sudden appearance of the error, though..

Thanks,
Alistair.

[Al Henderson]

James,

Thanks for that information - I can confirm that if I remove KB918899
then the problem goes away. As you say, try suggesting that to a
client! I do pretty much the same as you describe, except that I have
an object which encapsulates the window object and already have a
'closed' flag on that object as the window.closed was not being
reported correctly in IE5. I think I may stop using the window.closed
and just rely on my own flag instead.

Thanks,
Al.

ja**************@gmail.com wrote:

I am encountering the same thing and I found that when I removed a
recent windows update, Cumulative Security Update for Internet Explorer
for Windows XP (KB918899), the issue went away. Of course, that is not
an option I can present to our clients.

In my scenario the error is being thrown when I check the window.closed
property for a pop-up in a timer interval loop. After the pop-up is
reported as closed the opener then runs a function using the data from
the pop-up.

Playing with the javascript I found that if I delayed checking the
closed property for about 1 second then the closed property reported
back correctly that it was closed. Also, before the pop-up was closed
the property correctly reported back that the window was not closed.

I use this routine,
if (dialog && !dialog.closed) dialog.focus();
in many places to make my pop-ups behave somewhat like a modal dialog
and I would love to hear if there is a security setting or other option
available to avoid the Permission Denied error now that it has become
an issue within IE 6.0.29.

Any insights would be appreciated. Thanks,
James

al****************@email.com wrote:

Morning All,

I have some code for a website which uses 'window.open' to simulate
modal dialog boxes. I use the window.closed property to decide if the
window object exists at various points. This has been fine until last
week when I started getting javascript 'Permission Denied' errors when
I try to access this property.

I suspect that a windows update has caused this somehow, as this code
has not changed for a very long time. Can anyone confirm if there have
been any windows updates that would cause this? Maybe some browser
security settings have subtely changed, or something?

Its not a huge problem, as I already had my own 'closed' flag to check
as window.closed was not reliable in IE5 anyway, so I may just stop
using window.closed entirely. I would like to be abel to explain the
sudden appearance of the error, though..

Thanks,
Alistair.

[ramesh.kale]

Hi All,

I am having same problem in my application. Please let me if you work
auornd some to approach to fix the IE Issue.

We are using folllowing code in our application -
function _closeStatusWindow()
{
if(g_statusWindow && !g_statusWindow.closed)
g_statusWindow.close();
}

Thanks in Advanace,
Ramesh

[bostonsqd]

Same here... I confirmed that KB918899 caused this problem.
I used a pop-up dialog to get data...
When I click on OK button, and eventually will close the dialog... when
the code try to access the data, it said "permission denied".

Here is the function I handle the ok button clicked, the data look fine
in here:
function okBtn()
{
outputArgs.newList =
copyArray(document.entityDialogForm.curSel.options );
top.close(); <--- to close the dialog.
}

but when I get the data else where.. it will "permission denied".
I heard that someone said delay the close dialog will work.. How is
this work? Can someone share some lights here... ???

Any suggestions out there?
Thanks.

[Richard Cornford]

bo*******@gmail.com wrote:

Same here... I confirmed that KB918899 caused this
problem.
I used a pop-up dialog to ...

<snip>

Any suggestions out there?

For at least the last 4 years it has been commonly recommended on this
group (and a fair few other web development related technical Usenet
groups) that people not design Internet and Intranet systems that depend
on the ability to open new browser windows. There have of course been
plenty of people who knew better, insisted the opening new browser
windows as necessary, desirable, useful, etc., and went ahead and
created such systems. Meanwhile the people who paid attention and
understood why opening new browser windows was rapidly becoming
non-viable set about investigating how the achieve similar results
without them.

The practical upshot of this is that there will not be much interest in
solving problems arising with the opening of new browser windows among
the people most qualified to tackle the subject, as the more
interested/considerate javascript authors no longer face those problems.

Richard.

[Andrew Poulos]

Richard Cornford wrote:

The practical upshot of this is that there will not be much interest in
solving problems arising with the opening of new browser windows among
the people most qualified to tackle the subject, as the more
interested/considerate javascript authors no longer face those problems.

What does one do when a client, for whom you work as a maintenance
programmer, asks you to remedy the following:
- a very, very expensive LMS can no longer open e-learning courses
because pop-up blockers are (rightly) in place,
- Flash 8 no longer communicates with JavaScript, in locally installed
courses, because of "new" security precautions in Flash,
- IE 7 and FF do not allow the hiding of the address and status bars
thus "ruining" carefully crafted designs?

The replies I've received, after I politely explain how the world now
works, are usually along the lines of:
- we've paid you to solve our problems
- it's been working for years
- no, we won't change security restrictions
- you are most likely incompetent
Andrew Poulos

[Trond Michelsen]

Richard Cornford wrote:

For at least the last 4 years it has been commonly recommended on this
group (and a fair few other web development related technical Usenet
groups) that people not design Internet and Intranet systems that depend
on the ability to open new browser windows. There have of course been
plenty of people who knew better, insisted the opening new browser
windows as necessary, desirable, useful, etc., and went ahead and
created such systems. Meanwhile the people who paid attention and
understood why opening new browser windows was rapidly becoming
non-viable set about investigating how the achieve similar results
without them.

Right, but what do you do when it IS necessary to open new windows? Ask
all your users to accept popups from your site?

I'm developing an interactive map, where the user can click on the map
to open related "applications" (as in another webpage with forms and
javascript (including XMLHttpRequest)). Many of these applications will
require a considerable portion of the screen, and it's also desirable
that it's possible to continue using the map.

A floating DIV (perhaps with an iframe) with minimize-functionality gets
fairly close to what I need, but a new window works a lot better, IMO.

--
Trond Michelsen

[Richard Cornford]

Trond Michelsen wrote:

Richard Cornford wrote:

>For at least the last 4 years it has been commonly recommended
on this group (and a fair few other web development related
technical Usenet groups) that people not design Internet and
Intranet systems that depend on the ability to open new browser
windows. ...

Right, but what do you do when it IS necessary to open new
windows?

<snip>

It is not necessary, which is a good thing as it is not practical.

Richard.

[Richard Cornford]

Andrew Poulos wrote:

Richard Cornford wrote:

>The practical upshot of this is that there will not be much
interest in solving problems arising with the opening of new
browser windows among the people most qualified to tackle the
subject, as the more interested/considerate javascript authors
no longer face those problems.

What does one do when a client, for whom you work as a maintenance
programmer, asks you to remedy the following:
- a very, very expensive LMS can no longer open e-learning courses
because pop-up blockers are (rightly) in place,
- Flash 8 no longer communicates with JavaScript, in locally
installed courses, because of "new" security precautions in Flash,
- IE 7 and FF do not allow the hiding of the address and status
bars thus "ruining" carefully crafted designs?

If the system was based on fundamentally flawed design there is a limit
to what can be achieved by tinkering with it. At some point someone is
going to have to re-design the system so that it can work (and not
repeat the mistakes of the past so it will continue to work in the
future).

The replies I've received, after I politely explain how the
world now works, are usually along the lines of:
- we've paid you to solve our problems

So let them pay you to re-design the system in a way that is likely to
be reliable in the long term. (assuming you can).

- it's been working for years

It has actually been failing for years, but the rate of failure has been
increasing over time and is only now getting to the point where it is
obvious to the non-technically informed.

- no, we won't change security restrictions

That is completely reasonable. An appropriate design should not raise
unmanageable security issues.

- you are most likely incompetent

Well ... the questions you have been asking here over the last months
would not encourage me to believe that you were qualified to work as a
'maintenance programmer' on anything but the simplest of web site.
Though from what you say above it looks like some charlatan took the
money and ran, leaving you with a task that would be impossible for
anyone.

Richard.

[Cookie Monster]

I have worked around the issue with the following:
if (dialog
&& typeof(dialog.closed)!='unknown'
&& !dialog.closed)
dialog.focus();

*** Sent via Developersdex http://www.developersdex.com ***

[Sean]

Thanks for you opinion, Dick.
Richard Cornford wrote:

Andrew Poulos wrote:

Richard Cornford wrote:

The practical upshot of this is that there will not be much
interest in solving problems arising with the opening of new
browser windows among the people most qualified to tackle the
subject, as the more interested/considerate javascript authors
no longer face those problems.

What does one do when a client, for whom you work as a maintenance
programmer, asks you to remedy the following:
- a very, very expensive LMS can no longer open e-learning courses
because pop-up blockers are (rightly) in place,
- Flash 8 no longer communicates with JavaScript, in locally
installed courses, because of "new" security precautions in Flash,
- IE 7 and FF do not allow the hiding of the address and status
bars thus "ruining" carefully crafted designs?

If the system was based on fundamentally flawed design there is a limit
to what can be achieved by tinkering with it. At some point someone is
going to have to re-design the system so that it can work (and not
repeat the mistakes of the past so it will continue to work in the
future).

The replies I've received, after I politely explain how the
world now works, are usually along the lines of:
- we've paid you to solve our problems

So let them pay you to re-design the system in a way that is likely to
be reliable in the long term. (assuming you can).

- it's been working for years

It has actually been failing for years, but the rate of failure has been
increasing over time and is only now getting to the point where it is
obvious to the non-technically informed.

- no, we won't change security restrictions

That is completely reasonable. An appropriate design should not raise
unmanageable security issues.

- you are most likely incompetent

Well ... the questions you have been asking here over the last months
would not encourage me to believe that you were qualified to work as a
'maintenance programmer' on anything but the simplest of web site.
Though from what you say above it looks like some charlatan took the
money and ran, leaving you with a task that would be impossible for
anyone.

Richard.

[James]

I dropped in from google with the same problem and just had to deliver
this important message:

Richard is an asshat. I think my smugness detector just burst into
flames.

Brilliant suggestion: offer to re-write the entire system for the
client, when the problem at hand can be changed in a single line of
code. Very business savvy.

Worst of all, you took the time to drop in and contribute to a thread
started by somebody with a real problem and let everybody know that
they're Maintenance Programmers, that you have no solution for them but
you're very smart so this problem doesn't affect you. Thank-you so
much.

Seriously, you're a classic.

- jn

*** Sent via Developersdex http://www.developersdex.com ***

[Andrew Watson]

Personally, I would shy away from using another testing method for the
window.closed property (eg typeof(dialog.closed)!='unknown'), because
then you just might hit a timing issue (the window closes between the
test of the property and the use... I know it would be rare, but it
could happen.

The better solution is to put it in a try catch block...
eg

try {
if(dialog && !dialog.closed)
dialog.focus();
} catch (ex) {
dialog = null;
}

that way you don't have a timing issue, and it still solves the problem,
and will still be relevant the next time MS change something that causes
an error.

Happy coding!
*** Sent via Developersdex http://www.developersdex.com ***

[Andrew Watson]

Andrew Paulos,

For pop-up blockers, you need to test if the window.open call was
successful and provide a link alternative...

eg something like

function open_win (url) {
var win = window.open (url, "WinName", "width=400,height=400");

if (win)
{
win.focus();
} else {
document.write('<span>Sorry your browser is blocking popups, <a
href="javascript:open_win(' + url + ');">click here</ato
continue</span>');
}
}
open_win("http://www.developersdex.com");

(note - not debugged, but you get the idea)
It could be something like showing a div which includes a link, or
something else, but you have to allow the user to initiate the action
with a click, rahter than have the window, auto-run it.

The Flash 8 thing is a pest, you can get around it by changing security
settings see:
http://www.macromedia.com/support/do...ayer/help/sett
ings_manager04.html

I know that is most likely not an answer for you either, but I think it
is the only one for now.

As for the inability to hide status bars etc, all I can say, is design
around it you can't fight it... the way I figure it, create the content
for a size that will fit regardless of whether they have the status bars
on or not and try to launch without them.

Sorry I couldn't be of more assistance.

Andrew

*** Sent via Developersdex http://www.developersdex.com ***

[Richard Cornford]

Andrew Watson wrote:

For pop-up blockers, you need to test if the window.open call
was successful and provide a link alternative...

eg something like

function open_win (url) {
var win = window.open (url, "WinName", "width=400,height=400");

if (win)
{
win.focus();
} else {
document.write('<span>Sorry your browser is blocking popups, <a
href="javascript:open_win(' + url + ');">click here</ato
continue</span>');
}
}
open_win("http://www.developersdex.com");

(note - not debugged, but you get the idea)

Not only not debugged but presumably not even tested with a pop-up
blocking mechanism (and certainly not the range of such that would be
necessary before a reliable strategy could be approached).

The observed responses to a - window.open - call on systems using
pop-up blockers include null, references to the current window, a
javascript object (which may, more or less, fake the features of an
actual window object), throwing an exception and returning a reference
to a newly created window object (where the pop-up blocker is external
an asynchronous so the new window will be closed in the near future).
Your testing has only accounted for one of these possibilities.

In addition, a - document.write - following the initial loading of the
page will clear the excising page and replace it. Removing all the
objects from the javascript environment along the way. As a result your
proposed "link alternative" (apart from its unwise use of a javascript
pseudo-protocol HREF) is going to be attempting to call a function that
will no longer be available. Not that there is much point (or much
"alternative" in calling the same function again as it will likely be
subject to the same pop-up blocking.

A more reasonable design might be to trigger the window opening with
the onclick handler of a link and cancel the default action of the link
(the navigation) when the window opening attempt could be verified to
be successful (with the link, when not cancelled) just being allowed to
navigate the browser as the "alternative". Though as verifying the
success of window opening against asynchronous, external pop-up
blockers, or the more window object-imitating return values from
content inserting/re-writing proxy style pop-up blockers makes the
verifying of the success of window opening too troublesome to be
reliable in that context.

A much more sensible approach is to design systems that do not require
the opening of new browser window, and so avoid all the issues of
pop-up blocking (present and future) at a stroke.

Richard.

[Trond Michelsen]

Richard Cornford wrote:

In addition, a - document.write - following the initial loading of the
page will clear the excising page and replace it. Removing all the
objects from the javascript environment along the way. As a result your
proposed "link alternative" (apart from its unwise use of a javascript
pseudo-protocol HREF) is going to be attempting to call a function that
will no longer be available.

Sure, but I didn't mind that figuring out how to replace document.write
with element.innerHTML was left as an exercise to the reader. The
important, and IMO very helpful, part of his reply was that one should
check the return value of window.open() and offer an explicit link if
it's false.

I also appreciate your list of additional return values one should check
for.

Not that there is much point (or much
"alternative" in calling the same function again as it will likely be
subject to the same pop-up blocking.

This does not match my observations (although, I've only tested with
Firefox 1.0 on Linux and Firefox 1.5 on Windows, in both cases using the
internal popup-blocker).

--
Trond Michelsen

[Richard Cornford]

Trond Michelsen wrote:

Richard Cornford wrote:

>In addition, a - document.write - following the initial loading of the
page will clear the excising page and replace it. Removing all the
objects from the javascript environment along the way. As a result
your proposed "link alternative" (apart from its unwise use of a
javascript pseudo-protocol HREF) is going to be attempting to
call a function that will no longer be available.

Sure, but I didn't mind that figuring out how to replace
document.write with element.innerHTML was left as an exercise
to the reader.

Yes, it is always a good idea for people to pose example code that just
cannot work as a consequence of the logic it employs. Everyone learns
more from only seeing examples that don't work.

The important, and IMO very helpful, part of his reply was that
one should check the return value of window.open() and offer an
explicit link if it's false.

A more important consideration is to realise that testing the return
value is hardly a new idea (why else would I be able to list half a
dozen possible values off the top of my head?). Many testing strategies
have been considered and discussed here over the years. Some going well
beyond the pedestrian example posted here and even some attempting to
tackle the problem of external pop-up blockers. Yet none of these many
attempts have been seen as sufficiently satisfactory for their use to
be recommended in any way, and so the general recommendation remains to
design systems so that they do not need to open new browser windows.

I also appreciate your list of additional return values one should
check for.

It was not a comprehensive list, only the things I remembered off the
top of my head.

>Not that there is much point (or much "alternative")
in calling the same function again as it will likely be
subject to the same pop-up blocking.

This does not match my observations (although, I've only tested with
Firefox 1.0 on Linux and Firefox 1.5 on Windows, in both cases using
the internal popup-blocker).

You are observing window opening functions failing to open new windows
on the first attempt and then opening them on the second?

Richard.

[Michael Winter]

Richard Cornford wrote:

Trond Michelsen wrote:

>Richard Cornford wrote:

[snip]

>>Not that there is much point (or much "alternative")
in calling the same function again as it will likely be
subject to the same pop-up blocking.

This does not match my observations (although, I've only tested with
Firefox 1.0 on Linux and Firefox 1.5 on Windows, in both cases using
the internal popup-blocker).

You are observing window opening functions failing to open new windows
on the first attempt and then opening them on the second?

I should think that the observations were limited to Firefox in its
default configuration where it only blocks "unrequested" pop-ups.

As the previously posted code tried to open a new window as the document
was loaded, Firefox (and others) would block that initial attempt, but
would permit opening a window as a result of activating the link
(assuming a default configuration).

Had the observations included other pop-up blockers, or alternative
settings, the results would be quite different.

Mike

[leandro camargo]

I don't know if *closed* property is cross-browser, but you can try
something more simple/relieble like this:

....
if(win && !win.close) { ... }
....
 

I simply test if the windows's *close* method exists...

al****************@email.com wrote:

Morning All,

I have some code for a website which uses 'window.open' to simulate
modal dialog boxes. I use the window.closed property to decide if the
window object exists at various points. This has been fine until last
week when I started getting javascript 'Permission Denied' errors when
I try to access this property.

I suspect that a windows update has caused this somehow, as this code
has not changed for a very long time. Can anyone confirm if there have
been any windows updates that would cause this? Maybe some browser
security settings have subtely changed, or something?

Its not a huge problem, as I already had my own 'closed' flag to check
as window.closed was not reliable in IE5 anyway, so I may just stop
using window.closed entirely. I would like to be abel to explain the
sudden appearance of the error, though..

Thanks,
Alistair.

[Trond Michelsen]

Richard Cornford wrote:

Trond Michelsen wrote:

>Richard Cornford wrote:

>>In addition, a - document.write - following the initial loading of the
page will clear the excising page and replace it. Removing all the
objects from the javascript environment along the way. As a result
your proposed "link alternative" (apart from its unwise use of a
javascript pseudo-protocol HREF) is going to be attempting to
call a function that will no longer be available.

Sure, but I didn't mind that figuring out how to replace
document.write with element.innerHTML was left as an exercise
to the reader.

Yes, it is always a good idea for people to pose example code that just
cannot work as a consequence of the logic it employs. Everyone learns
more from only seeing examples that don't work.

Well, to be fair, the example did work as posted (well, almost - the
link needed a couple of &quot; entities), if it was simply wrapped in a
script-tag and placed somewhere in an html-page. But it wouldn't work if
you invoked open_win() after the page had been completely loaded.

>The important, and IMO very helpful, part of his reply was that
one should check the return value of window.open() and offer an
explicit link if it's false.

A more important consideration is to realise that testing the return
value is hardly a new idea

I perfectly aware of that, which is why the entire floor at the office
could hear my hand hit my forehead when I read Andrew's post.

Many testing strategies
have been considered and discussed here over the years. Some going well
beyond the pedestrian example posted here and even some attempting to
tackle the problem of external pop-up blockers. Yet none of these many
attempts have been seen as sufficiently satisfactory for their use to
be recommended in any way, and so the general recommendation remains to
design systems so that they do not need to open new browser windows.

I realize that, but I'm still of the opinion that the functionality I
want works best in a separate window. (Basically, the new content takes
up pretty much as much space on the screen as the the old content, and
it's desirable to still be able to use the old page after loading the new)

I know that I'll probably not be able to create something that will
actually open a window for all possible popup-blockers. But if I can
detect that the popup failed (for most users), then I can provide
alternatives for them.

>I also appreciate your list of additional return values one should
check for.

It was not a comprehensive list, only the things I remembered off the
top of my head.

Sure. But it's enough to get me started. I don't mind using Google,
Google Groups and some empirical testing with datadumping.

>>Not that there is much point (or much "alternative")
in calling the same function again as it will likely be
subject to the same pop-up blocking.

This does not match my observations (although, I've only tested with
Firefox 1.0 on Linux and Firefox 1.5 on Windows, in both cases using
the internal popup-blocker).

You are observing window opening functions failing to open new windows
on the first attempt and then opening them on the second?

Yes. But as I said, I've only tested this with the default popup-blocker
on (two versions of) Firefox, so it's hardly a comprehensive test.

--
Trond Michelsen

[Kevin Worth]

Umm, no the problem is that .closed, .close, .open, .anything are all not
accessable (thanks to a Microsoft update) for not quite a second of time
after the window closes.

"leandro camargo" <le********@gmail.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...

>I don't know if *closed* property is cross-browser, but you can try
something more simple/relieble like this:

...
if(win && !win.close) { ... }
...
 

I simply test if the windows's *close* method exists...

al****************@email.com wrote:

>Morning All,

I have some code for a website which uses 'window.open' to simulate
modal dialog boxes. I use the window.closed property to decide if the
window object exists at various points. This has been fine until last
week when I started getting javascript 'Permission Denied' errors when
I try to access this property.

I suspect that a windows update has caused this somehow, as this code
has not changed for a very long time. Can anyone confirm if there have
been any windows updates that would cause this? Maybe some browser
security settings have subtely changed, or something?

Its not a huge problem, as I already had my own 'closed' flag to check
as window.closed was not reliable in IE5 anyway, so I may just stop
using window.closed entirely. I would like to be abel to explain the
sudden appearance of the error, though..

Thanks,
Alistair.