469,268 Members | 1,022 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,268 developers. It's quick & easy.

window.opener property affected by IE caching settings

Through some investigation it appears that selecting "Every visit to the
page" for the IE caching setting "Check for new version of stored pages"
causes the window.opener property of child windows to be set to null after
the main page has excuted a postback.

Can anyone explain this or at show that I'm wrong ?

Is this a bug in IE ?
Nov 19 '05 #1
7 2632
HTTP is stateless. The document (opener) that opened the window is unloaded
when the PostBack occurs. It's a bit of ASP.Net magic. The second instance
of the document only LOOKs like the same document. The original opener is
gone.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...
Through some investigation it appears that selecting "Every visit to the
page" for the IE caching setting "Check for new version of stored pages"
causes the window.opener property of child windows to be set to null after
the main page has excuted a postback.

Can anyone explain this or at show that I'm wrong ?

Is this a bug in IE ?

Nov 19 '05 #2
The problem occurs if a child window is opened with window.open() AFTER a
postback has occurred. The child is opened and while it is loading it checks
for "window.opener" to setup communicatiion with its parent, but it is null.

This problem does not involve the child being open while a postback occurs.

Also note that this works fine when IE setting "Check for new version of
stored pages" is set to "Automatically". The problem occurs when the option
"Every visit..." is selected.
"Kevin Spencer" wrote:
HTTP is stateless. The document (opener) that opened the window is unloaded
when the PostBack occurs. It's a bit of ASP.Net magic. The second instance
of the document only LOOKs like the same document. The original opener is
gone.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...
Through some investigation it appears that selecting "Every visit to the
page" for the IE caching setting "Check for new version of stored pages"
causes the window.opener property of child windows to be set to null after
the main page has excuted a postback.

Can anyone explain this or at show that I'm wrong ?

Is this a bug in IE ?


Nov 19 '05 #3
Hmm. No wonder you're having problems. This sounds very odd. It shouldn't
make any difference, as long as the page instance which initially loaded the
new window is still around. The only possible clue I can see is where you
state that the child is opened "while it is loading." Have you tried putting
the script at the END of the page, so that the whole page is loaded before
the child window is opened?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:FC**********************************@microsof t.com...
The problem occurs if a child window is opened with window.open() AFTER a
postback has occurred. The child is opened and while it is loading it
checks
for "window.opener" to setup communicatiion with its parent, but it is
null.

This problem does not involve the child being open while a postback
occurs.

Also note that this works fine when IE setting "Check for new version of
stored pages" is set to "Automatically". The problem occurs when the
option
"Every visit..." is selected.
"Kevin Spencer" wrote:
HTTP is stateless. The document (opener) that opened the window is
unloaded
when the PostBack occurs. It's a bit of ASP.Net magic. The second
instance
of the document only LOOKs like the same document. The original opener is
gone.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...
> Through some investigation it appears that selecting "Every visit to
> the
> page" for the IE caching setting "Check for new version of stored
> pages"
> causes the window.opener property of child windows to be set to null
> after
> the main page has excuted a postback.
>
> Can anyone explain this or at show that I'm wrong ?
>
> Is this a bug in IE ?
>
>


Nov 19 '05 #4
Actually I was referring to when the child was loading. The child window has
some initialization javascript which checks its own window.opener property
which should be a reference to its parent (the window that opened it).

If the parent has not executed a postback at the time it opens the child,
the child will be able to see its parent. However, if the parent has already
executed a postback sometime in the past when it opens the child, the child
will not be able to see its parent.

Keep in mind that the whole setup works fine when the IE cache setting is
set to Automatic, so I know that it works. However, it fails when when the
cache setting is set to "Evey visit".

Why would the cache settings affect the relationship between parent and
child windows?
"Kevin Spencer" wrote:
Hmm. No wonder you're having problems. This sounds very odd. It shouldn't
make any difference, as long as the page instance which initially loaded the
new window is still around. The only possible clue I can see is where you
state that the child is opened "while it is loading." Have you tried putting
the script at the END of the page, so that the whole page is loaded before
the child window is opened?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:FC**********************************@microsof t.com...
The problem occurs if a child window is opened with window.open() AFTER a
postback has occurred. The child is opened and while it is loading it
checks
for "window.opener" to setup communicatiion with its parent, but it is
null.

This problem does not involve the child being open while a postback
occurs.

Also note that this works fine when IE setting "Check for new version of
stored pages" is set to "Automatically". The problem occurs when the
option
"Every visit..." is selected.
"Kevin Spencer" wrote:
HTTP is stateless. The document (opener) that opened the window is
unloaded
when the PostBack occurs. It's a bit of ASP.Net magic. The second
instance
of the document only LOOKs like the same document. The original opener is
gone.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:91**********************************@microsof t.com...
> Through some investigation it appears that selecting "Every visit to
> the
> page" for the IE caching setting "Check for new version of stored
> pages"
> causes the window.opener property of child windows to be set to null
> after
> the main page has excuted a postback.
>
> Can anyone explain this or at show that I'm wrong ?
>
> Is this a bug in IE ?
>
>


Nov 19 '05 #5
> Why would the cache settings affect the relationship between parent and
child windows?
I have no idea. In fact, it should NEVER work after the parent document has
posted back. Probably a bit of Microsoft magic built into IE just for
ASP.Net pages, but I couldn't guess. However, I CAN guess how it would
behave in virtually any other browser - it wouldn't.

IOW, don't post the parent page back if you want to count on the opener not
being null.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:F0**********************************@microsof t.com... Actually I was referring to when the child was loading. The child window
has
some initialization javascript which checks its own window.opener property
which should be a reference to its parent (the window that opened it).

If the parent has not executed a postback at the time it opens the child,
the child will be able to see its parent. However, if the parent has
already
executed a postback sometime in the past when it opens the child, the
child
will not be able to see its parent.

Keep in mind that the whole setup works fine when the IE cache setting is
set to Automatic, so I know that it works. However, it fails when when
the
cache setting is set to "Evey visit".

Why would the cache settings affect the relationship between parent and
child windows?
"Kevin Spencer" wrote:
Hmm. No wonder you're having problems. This sounds very odd. It shouldn't
make any difference, as long as the page instance which initially loaded
the
new window is still around. The only possible clue I can see is where you
state that the child is opened "while it is loading." Have you tried
putting
the script at the END of the page, so that the whole page is loaded
before
the child window is opened?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:FC**********************************@microsof t.com...
> The problem occurs if a child window is opened with window.open() AFTER
> a
> postback has occurred. The child is opened and while it is loading it
> checks
> for "window.opener" to setup communicatiion with its parent, but it is
> null.
>
> This problem does not involve the child being open while a postback
> occurs.
>
> Also note that this works fine when IE setting "Check for new version
> of
> stored pages" is set to "Automatically". The problem occurs when the
> option
> "Every visit..." is selected.
>
>
> "Kevin Spencer" wrote:
>
>> HTTP is stateless. The document (opener) that opened the window is
>> unloaded
>> when the PostBack occurs. It's a bit of ASP.Net magic. The second
>> instance
>> of the document only LOOKs like the same document. The original opener
>> is
>> gone.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "MrFez" <Mr***@discussions.microsoft.com> wrote in message
>> news:91**********************************@microsof t.com...
>> > Through some investigation it appears that selecting "Every visit to
>> > the
>> > page" for the IE caching setting "Check for new version of stored
>> > pages"
>> > causes the window.opener property of child windows to be set to null
>> > after
>> > the main page has excuted a postback.
>> >
>> > Can anyone explain this or at show that I'm wrong ?
>> >
>> > Is this a bug in IE ?
>> >
>> >
>>
>>
>>


Nov 19 '05 #6
It does work !! It works in FireFox, it works in Opera, and it does work in
Internet Explorer when its Temporary Internet Files setting is set to the
default "Automatic".

The problem is it doesn't work in Internet Explorer when the Temporary
Internet Files setting is set to "Every visit...".
"Kevin Spencer" wrote:
Why would the cache settings affect the relationship between parent and
child windows?


I have no idea. In fact, it should NEVER work after the parent document has
posted back. Probably a bit of Microsoft magic built into IE just for
ASP.Net pages, but I couldn't guess. However, I CAN guess how it would
behave in virtually any other browser - it wouldn't.

IOW, don't post the parent page back if you want to count on the opener not
being null.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:F0**********************************@microsof t.com...
Actually I was referring to when the child was loading. The child window
has
some initialization javascript which checks its own window.opener property
which should be a reference to its parent (the window that opened it).

If the parent has not executed a postback at the time it opens the child,
the child will be able to see its parent. However, if the parent has
already
executed a postback sometime in the past when it opens the child, the
child
will not be able to see its parent.

Keep in mind that the whole setup works fine when the IE cache setting is
set to Automatic, so I know that it works. However, it fails when when
the
cache setting is set to "Evey visit".

Why would the cache settings affect the relationship between parent and
child windows?
"Kevin Spencer" wrote:
Hmm. No wonder you're having problems. This sounds very odd. It shouldn't
make any difference, as long as the page instance which initially loaded
the
new window is still around. The only possible clue I can see is where you
state that the child is opened "while it is loading." Have you tried
putting
the script at the END of the page, so that the whole page is loaded
before
the child window is opened?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:FC**********************************@microsof t.com...
> The problem occurs if a child window is opened with window.open() AFTER
> a
> postback has occurred. The child is opened and while it is loading it
> checks
> for "window.opener" to setup communicatiion with its parent, but it is
> null.
>
> This problem does not involve the child being open while a postback
> occurs.
>
> Also note that this works fine when IE setting "Check for new version
> of
> stored pages" is set to "Automatically". The problem occurs when the
> option
> "Every visit..." is selected.
>
>
> "Kevin Spencer" wrote:
>
>> HTTP is stateless. The document (opener) that opened the window is
>> unloaded
>> when the PostBack occurs. It's a bit of ASP.Net magic. The second
>> instance
>> of the document only LOOKs like the same document. The original opener
>> is
>> gone.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "MrFez" <Mr***@discussions.microsoft.com> wrote in message
>> news:91**********************************@microsof t.com...
>> > Through some investigation it appears that selecting "Every visit to
>> > the
>> > page" for the IE caching setting "Check for new version of stored
>> > pages"
>> > causes the window.opener property of child windows to be set to null
>> > after
>> > the main page has excuted a postback.
>> >
>> > Can anyone explain this or at show that I'm wrong ?
>> >
>> > Is this a bug in IE ?
>> >
>> >
>>
>>
>>


Nov 19 '05 #7
Well, MrFez, I've lost track of this thread. But I will stand by my advice:
IOW, don't post the parent page back if you want to count on the opener
not
being null.
--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:6C**********************************@microsof t.com...
It does work !! It works in FireFox, it works in Opera, and it does work
in
Internet Explorer when its Temporary Internet Files setting is set to the
default "Automatic".

The problem is it doesn't work in Internet Explorer when the Temporary
Internet Files setting is set to "Every visit...".
"Kevin Spencer" wrote:
> Why would the cache settings affect the relationship between parent and
> child windows?


I have no idea. In fact, it should NEVER work after the parent document
has
posted back. Probably a bit of Microsoft magic built into IE just for
ASP.Net pages, but I couldn't guess. However, I CAN guess how it would
behave in virtually any other browser - it wouldn't.

IOW, don't post the parent page back if you want to count on the opener
not
being null.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"MrFez" <Mr***@discussions.microsoft.com> wrote in message
news:F0**********************************@microsof t.com...
> Actually I was referring to when the child was loading. The child
> window
> has
> some initialization javascript which checks its own window.opener
> property
> which should be a reference to its parent (the window that opened it).
>
> If the parent has not executed a postback at the time it opens the
> child,
> the child will be able to see its parent. However, if the parent has
> already
> executed a postback sometime in the past when it opens the child, the
> child
> will not be able to see its parent.
>
> Keep in mind that the whole setup works fine when the IE cache setting
> is
> set to Automatic, so I know that it works. However, it fails when when
> the
> cache setting is set to "Evey visit".
>
> Why would the cache settings affect the relationship between parent and
> child windows?
>
>
> "Kevin Spencer" wrote:
>
>> Hmm. No wonder you're having problems. This sounds very odd. It
>> shouldn't
>> make any difference, as long as the page instance which initially
>> loaded
>> the
>> new window is still around. The only possible clue I can see is where
>> you
>> state that the child is opened "while it is loading." Have you tried
>> putting
>> the script at the END of the page, so that the whole page is loaded
>> before
>> the child window is opened?
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "MrFez" <Mr***@discussions.microsoft.com> wrote in message
>> news:FC**********************************@microsof t.com...
>> > The problem occurs if a child window is opened with window.open()
>> > AFTER
>> > a
>> > postback has occurred. The child is opened and while it is loading
>> > it
>> > checks
>> > for "window.opener" to setup communicatiion with its parent, but it
>> > is
>> > null.
>> >
>> > This problem does not involve the child being open while a postback
>> > occurs.
>> >
>> > Also note that this works fine when IE setting "Check for new
>> > version
>> > of
>> > stored pages" is set to "Automatically". The problem occurs when
>> > the
>> > option
>> > "Every visit..." is selected.
>> >
>> >
>> > "Kevin Spencer" wrote:
>> >
>> >> HTTP is stateless. The document (opener) that opened the window is
>> >> unloaded
>> >> when the PostBack occurs. It's a bit of ASP.Net magic. The second
>> >> instance
>> >> of the document only LOOKs like the same document. The original
>> >> opener
>> >> is
>> >> gone.
>> >>
>> >> --
>> >> HTH,
>> >>
>> >> Kevin Spencer
>> >> Microsoft MVP
>> >> ..Net Developer
>> >> What You Seek Is What You Get.
>> >>
>> >> "MrFez" <Mr***@discussions.microsoft.com> wrote in message
>> >> news:91**********************************@microsof t.com...
>> >> > Through some investigation it appears that selecting "Every visit
>> >> > to
>> >> > the
>> >> > page" for the IE caching setting "Check for new version of stored
>> >> > pages"
>> >> > causes the window.opener property of child windows to be set to
>> >> > null
>> >> > after
>> >> > the main page has excuted a postback.
>> >> >
>> >> > Can anyone explain this or at show that I'm wrong ?
>> >> >
>> >> > Is this a bug in IE ?
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>


Nov 19 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Renuka | last post: by
4 posts views Thread by Phillip Parr | last post: by
2 posts views Thread by The Athiest | last post: by
19 posts views Thread by Darren | last post: by
21 posts views Thread by alistair_henderson | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.