open.window() and passing URL string

[wayne]

Hey there... I'm having some problems passing url parameters with an
open.window command. I'm not terribly familiar with java script but
here is the code below.

When executed it opens the window properly but does not pass the
parameter.

(this is part of a coldfusion template)

<a href="##"
onClick="window.open('photopage#.htm?region=#slave.region#','prop1','location,menubar,height=600,width=800,scrollbars,resizable,toolbar=yes');
return false;"><img src="#trim(photodir)#/#photoname4#" width="90"
height="60" hspace="2" vspace="2" border="2"></a>


Thanks,
Wayne

 

[RobG]

Hey there... I'm having some problems passing url parameters with an
open.window command. I'm not terribly familiar with java script but
here is the code below.

When executed it opens the window properly but does not pass the
parameter.

(this is part of a coldfusion template)

<a href="##"
onClick="window.open('photopage#.htm?region=#slave.region#','prop1','location,menubar,height=600,width=800,scrollbars,resizable,toolbar=yes');
return false;"><img src="#trim(photodir)#/#photoname4#" width="90"
height="60" hspace="2" vspace="2" border="2"></a>

Are all those hashes '#' from coldfusion? Your link above will do
nothing in a browser with JavaScript disabled or not available. Put
your URL into the href attribute and open the popup using something like:


<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>


Now the link will open in a pop-up whether the user has scripting or
not. If scripting is available, the window may have your suggested
attributes. If scripting is not available, the URL will open in a
standard pop-up.

 

[ASM]

Hey there... I'm having some problems passing url parameters with an
open.window command. I'm not terribly familiar with java script but
here is the code below.

When executed it opens the window properly but does not pass the
parameter.

if browser reads : <img src="#trim(photodir)#/#photoname4#"
and #trim(photodir)# or #photoname4#
are coldFusion entries, there is a problem with your coldFusion code ...
or your ColdFusion Server

Which parameter(s) do you want to send ?
region=#slave.region# ->
region's value is #slave.region# or slave.region ?
because # has signification in an url (anchor)

I would have done, and you would have to get in browser :
photopage.htm?region=slave.region#somewhere
where :
- photopage.htm is the page to load
- region is a parameter
- slave.region is the parameter value
- somewhere is an anchor on the page to scroll to

photopage.htm?region=slave.region&city=Small-Town#somewhere
- region = 'slave.region'
- city = 'Small-Town'

in my test, in popup window, location bar displays exactly :
photopage.htm?region=slave.region&city=Small-Town#somewhere

parameters well are send (no coldFusion used)

(this is part of a coldfusion template)

<a href="##"
onClick="window.open('photopage#.htm?region=#slave.region#','prop1','location,menubar,height=600,width=800,scrollbars,resizable,toolbar=yes');
return false;"><img src="#trim(photodir)#/#photoname4#" width="90"
height="60" hspace="2" vspace="2" border="2"></a>

wouldn't something be missing :
window.open('photopage#.htm?region=#slave.region#
insteed of :
window.open('#photopage#.htm?region=#slave.region#

 

[wayne]

Thanks Rob... worked great!

Hey? is there a way to bring a window (opened with an open.window
script) back in to focus should it get buried under another window. It
seems to be a common problem. A user opens a window with the
open.window script then the user clicks somewhere on their desktop and
the window disappears under another application. From that point on
any subsquent clicks on the original link with the open.window command
delivers the content to the window but since it's buried the user
doesn't know.

Thanks,
Wayne

 

[RobG]

Thanks Rob... worked great!

It's usual practice to quote what you are replying to so we know what
worked great ... but thanks for the glory! ;-)

Hey? is there a way to bring a window (opened with an open.window
script) back in to focus should it get buried under another window.

Yes. Test the window.closed property, if it's false, the window has
been closed. An example below:


<script type="text/javascript">

var aWin;

function popWin( u, n, atts ){
if ( aWin && ! aWin.closed ) {
if ( aWin.location.href != u ) {
aWin.location.href = u;
}
aWin.focus();
} else {
aWin = window.open( u, n, atts);
aWin.focus();
}
}

</script>

 

[Gérard Talbot]

RobG wrote :

<script type="text/javascript">

var aWin;

function popWin( u, n, atts ){
if ( aWin && ! aWin.closed ) {
if ( aWin.location.href != u ) {
aWin.location.href = u;
}
aWin.focus();
} else {
aWin = window.open( u, n, atts);
aWin.focus();

Can you explain why you need this instruction on the line above?
The way I see this is: if the window pointer is inexistent in memory or
if the window has been closed, then create the window. Now, why would
you need to focus it right after creating it?

}
}

</script>

Gérard

 

[Gérard Talbot]

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?
Also, note that the requested window will not be resizable and will not
render scrollbars if needed, if content overflows requested window
dimensions. Also the window.open() call tries to disable status bar. For
many reasons, none of this is recommendable.

Gérard

 

[Randy Webb]

Gérard Talbot said the following on 8/26/2005 6:17 PM:

RobG wrote :


Why not target="prop1" ?

<a href="...." target="myWindow"
onclick="popWin(this.href,this.target .....); return false"..


Is definitely a preferred way, especially from a maintenance standpoint.

 

[ASM]

RobG wrote :


Why not target="prop1" ?

because return false;

Also, note that the requested window will not

Wasn't it what wanted ?

For
many reasons, none of this is recommendable.

Which reasons ?

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area
So, f you know which space you need,
why not to freeze a naked window to this size ?


(*) http://developer.mozilla.org/en/docs/DOM:window.open

 

[RobG]

RobG wrote :


Why not target="prop1" ?
Indeed.

Also, note that the requested window will not be resizable and will not
render scrollbars if needed, if content overflows requested window
dimensions. Also the window.open() call tries to disable status bar. For
many reasons, none of this is recommendable.

The OP can attempt to set whatever attributes he wants. I reduced the
attributes to width and height for brevity.

In regard to your post above regarding the superfluous focus(), yeah,
it's superfluous.

 

[RobG]

because return false;

That just stops the default window opening if scripting is available, it
does not preclude giving the window some other name.

Wasn't it what wanted ?



Which reasons ?

Because browsers put messages in the status bar that users like to read,
it annoys users if they can't. For example, Safari tells me if a link
will (attempt to) open a new window, so I can put it into a tab instead.

From the page you referenced:

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area

Maybe you misunderstood the notes on height. The article is not
suggested that the height be set to full screen, it just documented the
fact that you can do it.

Browser vendors have a need to supply the same features as their
competitors, even if they may feel it's not a good feature. If you read
some of the entries in bugzilla you'll see that there is constant debate
about whether or not Mozilla should support various Microsoft
proprietary IE features (e.g. element IDs as global variables, support
for document.all).

So, f you know which space you need,
why not to freeze a naked window to this size ?

(*) http://developer.mozilla.org/en/docs/DOM:window.open

Opening a window to 'full screen' size is not polite - let the user
decide what size they want it.

 

[ASM]

That just stops the default window opening if scripting is available, it
does not preclude giving the window some other name.

Right ! alors ceci :

<a href="photopage#.htm?region=#slave.region#" target="prop1"

? popWin() { aWin = window.open() }

will 'aWin' not be the name of popup ?

for me : 'prop1' is the target of the window 'aWin'
(seen a kind of spec. spelling 'name' for both 'name' and 'target'
I don't agree with this confusioning
even knowing one of name is for JS and other for HTML)

Because browsers put messages in the status bar that users like to read,
it annoys users if they can't. For example, Safari tells me if a link
will (attempt to) open a new window, so I can put it into a tab instead.

Hu ... anyway Safari doesn't accept to close its status bar, no ?
(and fiew others do so)
To open a tab in a small popup unresizable is it a good idea ?

Maybe you misunderstood the notes on height. The article is not
suggested that the height be set to full screen, it just documented the
fact that you can do it.

by viewing area I did mean the free area inside the browser's window
(think in ref.d url(*) they call it like that)
they suggest that height and width attributes of window.open() are
these of free area (viewing area) of popup
(NC4, NC6, Moz, IE, Opera)

Browser vendors have a need to supply the same features as their
competitors, even if they may feel it's not a good feature.

it is a real headache !
http://www.quirksmode.org/viewport/compatibility.html
(and NC4 is no more referenced here. iCab, Safari ignored)

Opening a window to 'full screen' size is not polite - let the user
decide what size they want it.

Never I did suggest a full screen
and did stay to your own example (800/600)
even if I can understand a full screen *popup* using during a short time

full screen != unresizable (except IE with ist fullscreen attribute ?)

 

[Gérard Talbot]

RobG wrote :

The OP can attempt to set whatever attributes he wants. I reduced the
attributes to width and height for brevity.

Ok.

In regard to your post above regarding the superfluous focus(), yeah,
it's superfluous.

Ok.

Gérard

 

[Gérard Talbot]

ASM wrote :

because return false;

return false cancels the default action of the element, here it cancels
the default action of the link. In case javascript is disabled, then the
link should open the photopage#.htm?region=#slave.region# resource in a
named window called "prop1". This is important if you want to maximize
the resources your code uses from the users' system resources.
Re-opening and re-using/re-cycling an already opened secondary window is
the most efficient way to use the user's system resources.

"The purpose of the return false in the code is to cancel default action
of the link: if the onclick event handler is executed, then there is no
need to execute the default action of the link. But if javascript
support is disabled or non-existent on the user's browser, then the
onclick event handler is ignored and the browser loads the referenced
resource in the target frame or window (...)"
http://developer.mozilla.org/en/docs/DOM:window.open#Best_practices

Wasn't it what wanted ?



Which reasons ?

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area

No. Read again. When the web developer codes the window.open() call and
the height and width windowFeature, he's requesting some particular
value for the height and width of the browser window viewport of that
new window to be.

Everything is nicely explained at
http://developer.mozilla.org/en/docs/DOM:window.open#height

So, f you know which space you need,
why not to freeze a naked window to this size ?

Without knowing it, you are exactly making my point regarding always
ensuring that a window is resizable and renders scrollbar(s) if content
exceeds, overflows requested window dimensions. In this case, if the web
developer goes wrong with the requested width and/or height, then a
normal, standard fallback mechanism should prevail and should let the
user adjust the size of that new window according to his needs. Failure
to do so makes the window inaccessible, difficult to use, frustrating to
the user.
Often, the user gets a new window without knowing it in advance; and
often, he gets a crippled window. The result is easy to figure out: the
user closes the stupid window and leaves the web developer's site
without him never knowing about his bad work.

(*) http://developer.mozilla.org/en/docs/DOM:window.open

Gérard

 

[ASM]

ASM wrote :


return false cancels the default action of the element

[snip]

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)

No. Read again.

I do not speak english very well but it is writen :
[ height
Specifies the height of the content area,
viewing area of the new secondary window in pixels
^^^^^^^^^^^^
.... ] ^---- I do speak of this area

Everything is nicely explained at
http://developer.mozilla.org/en/docs/DOM:window.open#height

What have I to understand ?
I think they speak of inside height (free height to display)
in oposite of 'outerHeight' that is the complete height

Without knowing it, you are exactly making my point regarding always
ensuring that a window is resizable and renders scrollbar(s) if content
exceeds,

of course.

 

[Randy Webb]

ASM said the following on 8/27/2005 8:51 PM:

ASM wrote :



return false cancels the default action of the element

[snip]

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)

Not sure I agree with that since what you are saying is that if I do this:

<a href="someWhere.html" target="prop1" onclick="someFunction(this.href,
this.target, props here);return false">Some text</a>

Then the function will ignore the target and it won't. It will open the
resource in the window named prop1 and open that window if it's not open.

Or, is there a browser you have that doesn't follow that behavior?

The major disadvantage of target="_blank" is that if the user clicks on
10 different links (or even the same link 10 times), they get 10 new
windows. Where if the target is the same for all links, and the script
picks up this.target, then the user only gets 1 window.

The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up. If you specify
names in both places, you have to change 2 places in the code, instead of 1.

 

[Gérard Talbot]

ASM wrote :

ASM wrote :



return false cancels the default action of the element

[snip]

return false canceling the element (link) do abort link target too,

Have you tried this? Have you verified this? You can create a little
webpage and verify this yourself, you know..

so having same target in your open.window() is of no use
(that's what I said)

You can read the documentation on all this yourself. And if you don't
understand the documentation or don't believe the documentation, then
you can try the parameters with a webpage.

Gérard

 

[Gérard Talbot]

ASM wrote :

RobG wrote :

[snipped]

For many reasons, none of this is recommendable.

Which reasons ?

I mentioned resizability of the window, scrollbar(s) presence if content
exceeds requested window dimensions, statusbar presence which is forced
now by MSIE 6 SP 2.

The reasons are mentioned at the very URL you have provided.

(*) http://developer.mozilla.org/en/docs/DOM:window.open

Gérard

 

[ASM]

I mentioned resizability of the window, scrollbar(s) presence if content
exceeds requested window dimensions, statusbar presence which is forced
now by MSIE 6 SP 2.

If I have a doc sized (i.e. photo)
correct sized popup will not need scrollbars
and statusbar (not only IE-6-SP-2 force this, Opera, Safari ...)
doesn't enter in window.opens' height

The reasons are mentioned at the very URL you have provided.

of course if doc to display in popup can't be set in absolutly known
sizes, at least popup resizability has to be planed

 

[ASM]

ASM said the following on 8/27/2005 8:51 PM:


Not sure I agree with that since what you are saying is that if I do this:

<a href="someWhere.html" target="prop1" onclick="someFunction(this.href,
this.target, props here);return false">Some text</a>

Then the function will ignore the target and it won't. It will open the
resource in the window named prop1 and open that window if it's not open.

because 'return false' and because popWin open a window nammed 'aWin',
even with 10 clicks, you'll get an alone popup (if JS is enabled)
(as I don't know what does someFunction, I can't judge its doing)

The major disadvantage

or advantage, depends what you want

of target="_blank" is that if the user clicks on
10 different links (or even the same link 10 times), they get 10 new
windows. Where if the target is the same for all links, and the script
picks up this.target, then the user only gets 1 window.

Yes ... but ... no need to have same target in html and JS

The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up.

function pop(h,t,p) { truc=window.open(h,'',p) }
doesn't need to refer to the link target

and
function pop(h,t,p) { truc=window.open('',t,p) }
will need to refer to the link target
and will not need to refer to he href

usualy, I use something like last example