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  2859 
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***@discussi ons.microsoft.c om> wrote in message
news:91******** *************** ***********@mic rosoft.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.ope ner" 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***@discussi ons.microsoft.c om> wrote in message
news:91******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:FC******** *************** ***********@mic rosoft.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.ope ner" 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***@discussi ons.microsoft.c om> wrote in message
news:91******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:FC******** *************** ***********@mic rosoft.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.ope ner" 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***@discussi ons.microsoft.c om> wrote in message
news:91******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:F0******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:FC******** *************** ***********@mic rosoft.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.ope ner" 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***@discussi ons.microsoft.c om> wrote in message
>> news:91******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:F0******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:FC******** *************** ***********@mic rosoft.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.ope ner" 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***@discussi ons.microsoft.c om> wrote in message
>> news:91******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:6C******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
news:F0******** *************** ***********@mic rosoft.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***@discussi ons.microsoft.c om> wrote in message
>> news:FC******** *************** ***********@mic rosoft.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.ope ner" 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***@discussi ons.microsoft.c om> wrote in message
>> >> news:91******** *************** ***********@mic rosoft.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 thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Renuka |
last post by:
I have a confirmation page with an OK button. If this window has an
opener then this browser window needs to go to another URL or else the
window must close.
Thus I have the following javascript to achieve the above which does
not work:
<script language="jscript">
function PageRedirection()
{
if(!opener)
|
by: Don |
last post by:
Hi,
I have the following script that displays a popup window centered in the
middle of the screen. I am getting a script error in both IE and Netscape
but I don't know what it means. Thanks in advance.
The error is
------------
Error: win has no properties
Line 13 below ( win.window.focus(); )
|
by: Phillip Parr |
last post by:
Hello, I have a nice system where someone clicks on a picture to show the
full version. This pops up in a window.open box. It works great, the only
problem is that if the user clicks a second picture before closing the first
then the new picture loads into the original popup box which is often a
different size. How can i make them open in their own popup windows?
Thanks
|
by: The Athiest |
last post by:
Hi,
I have the following JavaScript function which works fine in IE, Opera and
Firefox. I can't get it to work in Netscape 7.2
Here is the code:
/**************************************************/
/* Display a popup window centered on the screen. */
/* Width and Height are supplied by the caller. * /
|
by: ...D. |
last post by:
OK. I am halfway decent with HTML. Now I want to try javascript for some
things that HTML cannot do. I have looked over a tutorial & all.
What I want to do is create a button, that when pressed, closes the window
it is in, and launches a URL. The window the button is in is actually just
a sub-page of the main website page, launched with target="blank", but I
just do not want to close the window as I said, I want to launch a website...
| | |
by: Darren |
last post by:
I have a page that opens a popup window and within the window, some databse
info is submitted and the window closes. It then refreshes the original
window using window.opener.location.reload(). The problem is that after the
reload, it brings you right to the top of the page. When I click 'refresh"
on the original page, it brings me back to the original viewing position.
Is there a way to duplicate this in from the popup window.
Also,...
|
by: Davey |
last post by:
I have a website which has a popup window (this only opens when the user
chooses to open it). In the popup window I have a <select> control which
lists a selection of "classes". Each class has a description and a class_id
(stored in the value attribute of each option). The user will then select a
class from the drop-down list.
What I want to do is have a control in the parent browser window which can
store the class_id and the...
|
by: MrFez |
last post by:
I have an webform from which I open a child window to display a calendar.
When a date is selected in the calendar window it attempts to set the value
of a textbox in the main (parent) window by using the window.opener property
to reference the textbox.
Everything works fine initially. However if the the main window does a
postback and the calendar is re-opened, its window.opener property will
always be null.
So: BEFORE main window...
|
by: alistair_henderson |
last post by:
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...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
