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 ? 7 2737
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 ?
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 ?
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 ? > >
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 ? > >
> 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 ? >> > >> > >> >> >>
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 ? >> > >> > >> >> >>
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 ? >> >> > >> >> > >> >> >> >> >> >> >> >> >> This discussion thread is closed Replies have been disabled for this discussion. Similar topics
8 posts
views
Thread by Renuka |
last post: by
|
6 posts
views
Thread by Don |
last post: by
|
4 posts
views
Thread by Phillip Parr |
last post: by
|
2 posts
views
Thread by The Athiest |
last post: by
|
4 posts
views
Thread by ...D. |
last post: by
|
19 posts
views
Thread by Darren |
last post: by
|
4 posts
views
Thread by Davey |
last post: by
|
1 post
views
Thread by MrFez |
last post: by
|
21 posts
views
Thread by alistair_henderson |
last post: by
| | | | | | | | | | |