Submit to parent.opener

I have a popup which contains a frame set; one of the frames contains a
form. When the form is submitted, I want it to go back to the opener of the
popup. I have:

document.forms[0].target = parent.opener;

But on submit it opens a new window. If I put:

document.write(parent.opener.name);

it gives me the correct value, so I know I'm pointing to the right place.
Any idea why this doesn't work and/or how to get it to?

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: Submit to parent.opener

Alan Little wrote:[color=blue]
> I have a popup which contains a frame set; one of the frames
> contains a form. When the form is submitted, I want it to
> go back to the opener of the popup. I have:[/color]

So you are not writing something suited to Internet use.
[color=blue]
> document.forms[0].target = parent.opener;[/color]

The - target - property of forms is a string, - parent.opener - will be
a reference to an object (a window object) (or null). When you assign -
parent.opener - the object will be type-converted into a string, and
that string will be, for example, "[object]" in IE and similarly
unhelpful values in other browsers.
[color=blue]
> But on submit it opens a new window. If I put:[/color]

Yes, you have targeted a window with a name like "[object]" and when no
such window exists a new one is created.
[color=blue]
> document.write(parent.opener.name);
>
> it gives me the correct value, so I know I'm pointing to
> the right place. Any idea why this doesn't work and/or how
> to get it to?[/color]

The value you should assign to the - target - is the (string) name of
the window, and that name value is available as - parent.opener.name -,
so that is the value you assign:-

document.forms[0].target = parent.opener.name;

Richard.

re: Submit to parent.opener

Carved in mystic runes upon the very living rock, the last words of
Richard Cornford of comp.lang.javascript make plain:
[color=blue]
> Alan Little wrote:
>[color=green]
>> I have a popup which contains a frame set; one of the frames
>> contains a form. When the form is submitted, I want it to
>> go back to the opener of the popup. I have:[/color]
>
> So you are not writing something suited to Internet use.[/color]

Perhaps not.
[color=blue][color=green]
>> document.forms[0].target = parent.opener;[/color]
>
> The - target - property of forms is a string, - parent.opener - will be
> a reference to an object (a window object) (or null). When you assign -
> parent.opener - the object will be type-converted into a string, and
> that string will be, for example, "[object]" in IE and similarly
> unhelpful values in other browsers.[/color]

Ah, I see.
[color=blue]
> The value you should assign to the - target - is the (string) name of
> the window, and that name value is available as - parent.opener.name -,
> so that is the value you assign:-
>
> document.forms[0].target = parent.opener.name;[/color]

Yes, that works. Thank you.

--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/

re: Submit to parent.opener

Alan Little wrote:[color=blue]
> Carved in mystic runes upon the very living rock, the last words of
> Richard Cornford of comp.lang.javascript make plain:
>[color=green]
>>Alan Little wrote:
>>
>>[color=darkred]
>>>I have a popup which contains a frame set; one of the frames
>>>contains a form. When the form is submitted, I want it to
>>>go back to the opener of the popup. I have:[/color]
>>
>>So you are not writing something suited to Internet use.[/color]
>
> Perhaps not.[/color]

I have a slight problem with that particular mindset: What about evolution?

Do we want the web to stay where it is, or do we want it to continue to
evolve?

re: Submit to parent.opener

Tony wrote:[color=blue]
> Alan Little wrote:[color=green]
>> Richard Cornford wrote:
>>[color=darkred]
>>>So you are not writing something suited to Internet use.[/color]
>>
>> Perhaps not.[/color]
>
> I have a slight problem with that particular mindset: What
> about evolution?
>
> Do we want the web to stay where it is, or do we want it
> to continue to evolve?[/color]

It is the evolution of the Internet that has bought us to a position
where a design predicated upon the ability to open new browser windows
is unreliable by design. Five years ago if a script could verify the
existence of a window.open method you were pretty much guaranteed that
calling it would result in the opening of a new window, and almost total
control over the position and chrome of that window.

Then we witnessed a spate of pop-up abuse getting so extreme that users
demanded that the facility be withdrawn or restricted, and now a growing
use of pop-up blockers brings us to a position where creating a public
Internet design that requires pop-up windows is recklessly stupid.

The future may see the situation settling down again, with pop-up
blockers coalescing around predictable behaviour to the extent that you
declare a consistent notion of a 'requested' pop-up and know the
circumstances when such was viable, and maybe consistently returning
null form calls to window-open when a pop-up was blocked, so a script
could know when it was having its window opening requests refused, but
that is not the current situation.

Richard.

re: Submit to parent.opener

Richard Cornford wrote:[color=blue]
> Tony wrote:
>[color=green]
>>Alan Little wrote:
>>[color=darkred]
>>>Richard Cornford wrote:
>>>
>>>
>>>>So you are not writing something suited to Internet use.
>>>
>>>Perhaps not.[/color]
>>
>>I have a slight problem with that particular mindset: What
>>about evolution?
>>
>>Do we want the web to stay where it is, or do we want it
>>to continue to evolve?[/color]
>
> It is the evolution of the Internet that has bought us to a position
> where a design predicated upon the ability to open new browser windows
> is unreliable by design. Five years ago if a script could verify the
> existence of a window.open method you were pretty much guaranteed that
> calling it would result in the opening of a new window, and almost total
> control over the position and chrome of that window.[/color]

OK, so the answer is "don't push the limits"? Do we throw out that
evolution simply because it caused some hiccups along the way?

Maybe we should apply that to video recording technology? Or perhaps the
adoption of HDTV?

Different vendors responded differently. Just like with biological
evolution - not all mutations survive. Those that are more robust, for
whatever reason, survive, and will impact the future of the species.

But that evolution BEGINS with a demand for more.
[color=blue]
> Then we witnessed a spate of pop-up abuse getting so extreme that users
> demanded that the facility be withdrawn or restricted, and now a growing
> use of pop-up blockers brings us to a position where creating a public
> Internet design that requires pop-up windows is recklessly stupid.[/color]

Evolution: adapt or die.
[color=blue]
> The future may see the situation settling down again, with pop-up
> blockers coalescing around predictable behaviour to the extent that you
> declare a consistent notion of a 'requested' pop-up and know the
> circumstances when such was viable, and maybe consistently returning
> null form calls to window-open when a pop-up was blocked, so a script
> could know when it was having its window opening requests refused, but
> that is not the current situation.[/color]

It is NOT possible to force a plethora of web developers and browser
publishers to do everything exactly the same. And there will be web
developers who want to push the limits - to do something beyond the
current state of the art. When enough developers desire the same thing,
the browser companies will respond - probably in different ways. Those
who produce a good solution are more likely to survive. Those who
produce a poor solution are more likely to fail, unless they adopt one
of the good (accepted) solutions quickly. Things change. Some adapt. I,
for one, am glad of it.

Thus goes evolution.

re: Submit to parent.opener

Tony wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue][color=green]
>> It is the evolution of the Internet that has bought us to a position
>> where a design predicated upon the ability to open new browser
>> windows is unreliable by design. ...[/color]
>
> OK, so the answer is "don't push the limits"?[/color]

What does the practical unreliability of trying to open new browser
windows have to do with pushing limits?
[color=blue]
> Do we throw out that evolution simply because it caused
> some hiccups along the way?[/color]

And what is being thrown out? The observation that a particular action
has become too unreliable to be sensible implies no more than the need
to find a different approach.
[color=blue]
> Maybe we should apply that to video recording technology?
> Or perhaps the adoption of HDTV?[/color]

It has already happened, the television design invented by John Logie
Baird (the one with the spinning wheels) proved too unreliable and was
abandoned in favour of a better alternative.

<snip>[color=blue]
> But that evolution BEGINS with a demand for more.[/color]

So how does designing systems that are predictably unreliable at the
time they are designed represent satisfying a demand for 'more'? Indeed,
given that virtually anything that can be done with a pop-up window can
also be done without one, what has the got to do with anything?
[color=blue][color=green]
>> ... brings us to a position where creating a public
>> Internet design that requires pop-up windows is
>> recklessly stupid.[/color]
>
> Evolution: adapt or die.[/color]

I don't see your point as stopping doing the recklessly stupid thing is
adapting.

<snip>[color=blue]
> And there will be web developers who want to push the
> limits - to do something beyond the current state of the art.[/color]
<snip>

Opening pop-up windows was old hat at the turn of the century, what is
your point?

Richard.

re: Submit to parent.opener

Richard Cornford wrote:[color=blue]
> what is your point?[/color]

I have a feeling you and I are having two entirely different
conversations :)