Focus on second window

B

Benno Bös

If I use the following construct in the frame "main" for a link to an
extern site:

<A HREF="http://www.any.xy" TARGET="extern">

the Browser is creating the window "extern", loading the page
www.any.xy an setting the focus to "extern". But when I go return to
"main" without closing "extern", a click to an other link (e.g.
www.2nd_any.xy) on "main" does not setting the focus to "extern".

For setting the focus to "extern" in the second case, I have used the
following construct:


<A HREF="http://www.any.xy" TARGET="extern"
onClick="setTimeout('extern=window.open(\'\',\'extern\');fremd.focus();',500);">
an example</A>


This construct has worked very well for a few years, but since about
one year, the sesult was the same as using
<A HREF="http://www.any.xy" TARGET="extern">

In this year, I have changed:
win 95 --> win 2000
modem 56k --> DSL
Netscape 4.5 --> Netscape 7.1


Can anybody tell me a possibility setting the focus to "extern" in the
second case? Is the changing of my configuration the reason, that the
construct has failed?

Thanks for your help.
 
L

Lee

=?ISO-8859-1?Q?Benno_B=F6s?= said:
If I use the following construct in the frame "main" for a link to an
extern site:

<A HREF="http://www.any.xy" TARGET="extern">

the Browser is creating the window "extern", loading the page
www.any.xy an setting the focus to "extern". But when I go return to
"main" without closing "extern", a click to an other link (e.g.
www.2nd_any.xy) on "main" does not setting the focus to "extern".

For setting the focus to "extern" in the second case, I have used the
following construct:


<A HREF="http://www.any.xy" TARGET="extern"
onClick="setTimeout('extern=window.open(\'\',\'extern\');fremd.focus();',500);">
an example</A>

As written, that won't work because fremd is undefined.
I'll guess that you meant for it to be extern.focus()

However, the following is simpler and doesn't depend on how long it
takes for your windows to open:

<html>
<body>
<a href="http://www.google.com"
target="extern"
onclick="window.open(this.href,'extern').focus();return false">an example</a>
<br>
<a href="http://www.yahoo.com"
target="extern"
onclick="window.open(this.href,'extern').focus();return false">another
example</a>
<br>
<a href="http://www.gutenberg.org"
target="extern"
onclick="window.open(this.href,'extern').focus();return false">and another
example</a>
</body>
</html>
 
D

DU

Benno said:
If I use the following construct in the frame "main" for a link to an
extern site:

<A HREF="http://www.any.xy" TARGET="extern">

the Browser is creating the window "extern", loading the page
www.any.xy an setting the focus to "extern". But when I go return to
"main" without closing "extern", a click to an other link (e.g.
www.2nd_any.xy) on "main" does not setting the focus to "extern".

What you are pinpointing here is the weakness in the windowing
management of all operating systems. J. Nielsen and many others have
explained this phenomenon. You're pinpointing one of the biggest reason
why opening a new window implies usability burdens. This has been
heavily explained before.
For setting the focus to "extern" in the second case, I have used the
following construct:


<A HREF="http://www.any.xy" TARGET="extern"
onClick="setTimeout('extern=window.open(\'\',\'extern\');fremd.focus();',500);">
an example</A>


This construct has worked very well for a few years, but since about
one year, the sesult was the same as using
<A HREF="http://www.any.xy" TARGET="extern">

In this year, I have changed:
win 95 --> win 2000
modem 56k --> DSL
Netscape 4.5 --> Netscape 7.1


Can anybody tell me a possibility setting the focus to "extern" in the
second case?

Yes with javascript and if the user allows focus() method on existing
windows. Opera 7.x and Mozilla-based browsers have user pref settings
which can neutralize focus() calls. No without javascript.

One way to compensate that windowing flaw is to notify the user fair and
square about the opening (and/or re-using of secondary window) of new
window with the title attribute (1), with a customized cursor (2), with
a custom .gif at the right side of the link. Believe it or not, most
major corporation sites have an icon .gif for this: I posted these about
6 months ago in alt.html.



Is the changing of my configuration the reason, that the
construct has failed?

Thanks for your help.

You probably have Edit/Preferences.../Advanced/Scripts & plugins/Allow
Scripts to:/Raise or lower windows

Explanations:
http://www10.brinkster.com/doctorunclear/Netscape7/Popup/PopupAndNetscape7.html#RaiseLowerSetting

Working example:
http://www10.brinkster.com/doctorunclear/BrowserBugsSection/Opera7Bugs/Opera7Bugs.html

DU
--
(1)
"8. Use link titles to provide users with a preview of where each link
will take them, before they have clicked on it."
Ten Good Deeds in Web Design
http://www.useit.com/alertbox/991003.html

"(...) if your link spawns a new window, or causes another windows to
'pop up' on your display, or move the focus of the system to a new FRAME
or Window, then the nice thing to do is to tell the user that something
like that will happen."
World Wide Web Consortium Accessibility Initiative regarding popups,
http://www.w3.org/WAI/wcag-curric/sam77-0.htm

(2)
there are bugzilla bugfiles on this: bug 90213, bug 169678. Also,
http://www.draig.de/LinkBar
uses customized cursors among which there is one for target="_blank" links.
 
D

DU

Lee said:
=?ISO-8859-1?Q?Benno_B=F6s?= said:



As written, that won't work because fremd is undefined.
I'll guess that you meant for it to be extern.focus()

However, the following is simpler and doesn't depend on how long it
takes for your windows to open:

<html>
<body>
<a href="http://www.google.com"
target="extern"
onclick="window.open(this.href,'extern').focus();return false">an example</a>

Your code will reload entirely all over again the google.com page when
that page already exists, when the code should only give that secondary
extern window the focus to bring it back on top. And when the window is
not created, the code calls the focus() method when it is not needed.
So, I wouldn't say your code is making optimal use of user's system
resources. Finally, your code just ignores the perspective of users
altogether: this is important to address all the time, furthermore if
the user has javascript support disabled and stats indicate that 5% to
10% of users have javascript support disabled.

I'll grant you that your code is better than code in many online
tutorials I've seen before.

DU
 
L

Lee

DU said:
Your code will reload entirely all over again the google.com page when
that page already exists, when the code should only give that secondary
extern window the focus to bring it back on top. And when the window is
not created, the code calls the focus() method when it is not needed.
So, I wouldn't say your code is making optimal use of user's system
resources. Finally, your code just ignores the perspective of users
altogether: this is important to address all the time, furthermore if
the user has javascript support disabled and stats indicate that 5% to
10% of users have javascript support disabled.

I'll grant you that your code is better than code in many online
tutorials I've seen before.

1. In the context of the original post, the same page would never
be refocused without loading new content. Since the content
is cached, that's not a major consideration, anyway.

2. Calling the focus() method when it is not needed costs so close
to nothing that it isn't worth discussing.

3. Explain your comment about ignoring the perspective of users.

4. If Javascript is disabled, it performs exactly as the OP's code
does. The only functionality that is lost is bringing the
existing window to the top. A <noscript> tag might be used to
warn visitors that the popup window may have it's content changed
without being made visible.
 
D

DU

Lee said:
DU said:



1. In the context of the original post, the same page would never
be refocused without loading new content. Since the content
is cached, that's not a major consideration, anyway.

I think you don't understand. Whatever the code we're talking about, if
a window only needs to be brought back on top, then the code should be
agile enough, smart enough to do just that; not to send an http request
and reload the content again. Your code (and the OP's code; whoever's
code, that's not the issue) does not just bring the window on top; it
sends an http request to the server and reloads the content all over
again when it is obviously not needed.
2. Calling the focus() method when it is not needed costs so close
to nothing that it isn't worth discussing.

If it's not needed, then why including it?
If it's not needed, then removing it certainly won't cost anything and
can not cost anything on the user's system resources. Agreed?
My post was mostly oriented toward making a code to be the best adjusted
to the needs of a webpage.

3. Explain your comment about ignoring the perspective of users.

Use title, cursor, icon to notify in advance that clicking a link will
open a new window or will recycle an already opened window. I gave
examples, demo pages in another post in this thread. I'm referring to J.
Nielsen recommendations, WAI recommendations and to many other usability
gurus, sites, tutorials here.
4. If Javascript is disabled, it performs exactly as the OP's code
does.

Yes.

The only functionality that is lost is bringing the
existing window to the top. A <noscript> tag might be used to
warn visitors that the popup window may have it's content changed
without being made visible.

Well, then that would be an attempt to address the perspective of users
regarding reusing secondary windows.
If clicking a link opens up a new window without the user being informed
in advance, notified somehow, then the user can not, will not associate
an action (his left mouse button click on a link) with the result. He
becomes unsure about his understanding of a technology.

DU
 
L

Lee

DU said:
Lee wrote:

I think you don't understand. Whatever the code we're talking about, if
a window only needs to be brought back on top, then the code should be
agile enough, smart enough to do just that; not to send an http request
and reload the content again. Your code (and the OP's code; whoever's
code, that's not the issue) does not just bring the window on top; it
sends an http request to the server and reloads the content all over
again when it is obviously not needed.

In my experience, it's very rare for a person to want to bring
the same link up immediately. Particularly if they know that
the window is already open. They're much more likely to click
one of the other links, first. Also, it doesn't have to reload
the content all over again, because it's cached. The extra
code required to decide whether or not the page should be
loaded, vs simply refocused introduces more chances of errors
or of running into browser incompatibilities.

If it's not needed, then why including it?
If it's not needed, then removing it certainly won't cost anything and
can not cost anything on the user's system resources. Agreed?

No, I don't agree. The alternative is to test to see if
it is needed, which is much less efficient.

Use title, cursor, icon to notify in advance that clicking a link will
open a new window or will recycle an already opened window.

Certainly, but that's beyond the scope of the OP's request.
My example wasn't intended to be a fully released web page.
It's just an example of how to open windows.
 
D

DU

Lee said:
DU said:



In my experience, it's very rare for a person to want to bring
the same link up immediately. Particularly if they know that
the window is already open.

Well, right here, usability studies don't support your understanding
experience. A significant minority of users do not notice that a new
window has been opened.

"(...) Users often don't notice that a new window has opened, especially
if they are using a small monitor where the windows are maximized to
fill up the screen. So a user who tries to return to the origin will be
confused by a grayed out Back button."
Jakob Nielsen, The Top Ten New Mistakes of Web Design: 2. Opening New
Browser Windows, May 30, 1999
http://www.useit.com/alertbox/990530.html

"(...) spawning second browser windows can completely throw users off
track because it removes the one thing they are sure how to use: the
'Back' button.(...) In another recent study, six out of 17 users had
difficulty with multiple windows, and three of them required assistance
to get back to the first window and continue the task."
Carolyn Snyder, Seven tricks that Web users don't know: 7. Second
browser windows, June 2001
http://www-106.ibm.com/developerworks/web/library/us-tricks/#h22470

"Research shows that most users don't like to run more than one
application at a time. In fact, many users are confused by multiple
applications."
Windows User Experience team,
Microsoft Windows User Experience Frequently Asked Questions: Why is the
taskbar at the bottom of the screen?,
March 2001
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/winuifaq.asp


They're much more likely to click
one of the other links, first.

It depends on the page. Here we don't have any clue on how such page is
working. If a link is going to re-use an already opened secondary
window, then the user ought to know about that in advance. If a link is
going to open a new separate, secondary window, then the user ought to
know that in advance.

Also, it doesn't have to reload
the content all over again, because it's cached.

It does reload the *cached* content all over again when it should not.
It does send an http request to the server when it should not, when
there is no need for that.

The extra
code required to decide whether or not the page should be
loaded,

Your approach brings more code to execute, in particular code that don't
need to be executed to begin with. A code should be smart enough to meet
the webpage needs.

vs simply refocused introduces more chances of errors
or of running into browser incompatibilities.

I can demonstrate otherwise. I have not find any browser
incompatibilities regarding focus() support and window object reference
support with NS 6.x, NS 7.x, Mozilla 1.x, Opera 7.x, MSIE 6, K-meleon
0.8.x and any/all browsers I could find on this.
No, I don't agree. The alternative is to test to see if
it is needed, which is much less efficient.

LOL!! I can't believe my eyes!!

DU
 
D

DU

Lee wrote:

The extra
code required to decide whether or not the page should be
loaded, vs simply refocused introduces more chances of errors
or of running into browser incompatibilities.

Here's an interactive demo that I posted more than 1 year ago where one
can bring back on top a secondary window. You can look around to find a
browser which won't support that interactive demo: I have failed to find
a single one.

http://www10.brinkster.com/doctorunclear/Netscape7/Popup/PopupAndNetscape7.html#RaiseLowerSetting

DU
 
L

Lee

DU said:
Lee wrote:


Well, right here, usability studies don't support your understanding
experience. A significant minority of users do not notice that a new
window has been opened.

Think about that in the context of what we're talking about.
If they click on a link, and the popup opens, they may not
be able to find their way back to the page with the links
on it. That means that they're not going to be clicking on
any more links, anyway, so it's not relevant.

Your cites are arguing against using popup windows at all,
which is a valid consideration, but out of scope of this
discussion.


Also, it doesn't have to reload

It does reload the *cached* content all over again when it should not.
It does send an http request to the server when it should not, when
there is no need for that.

The extra

Your approach brings more code to execute, in particular code that don't
need to be executed to begin with. A code should be smart enough to meet
the webpage needs.

Show me your alternative that uses less code.

vs simply refocused introduces more chances of errors

I can demonstrate otherwise. I have not find any browser
incompatibilities regarding focus() support and window object reference
support with NS 6.x, NS 7.x, Mozilla 1.x, Opera 7.x, MSIE 6, K-meleon
0.8.x and any/all browsers I could find on this.

Any code that you have to write to avoid a single focus()
call is too much.

LOL!! I can't believe my eyes!!

That's a pretty poor excuse for an argument.
How would you ensure that the correct window is on top in
a way that executes less code than a single focus()?
 
T

Thomas 'PointedEars' Lahn

Lee said:
DU said:
Lee said:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return false">an
example</a>
[...] And when the window is not created, the code calls the focus()
method when it is not needed.

2. Calling the focus() method when it is not needed costs so close to
nothing that it isn't worth discussing.

I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by another
method, without checking if the reference is valid and without checking
if the object returned has the former method, is error-prone. So I
strongly recommend to write at least

var w = window.open(...); if (w && !w.closed && w.focus) { w.focus(); };

instead.

Besides, both of you violate Internet standards (namely RFCs 1036 and
2822) by using non-existing "From:" addresses and, not less important,
you disregard the rules of this newsgroup described in its FAQ which
say that you should trim your quotes to the absolute necessary.


PointedEars
 
L

Lee

Thomas 'PointedEars' Lahn said:
DU said:
Lee wrote:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return false">an
I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by another
method, without checking if the reference is valid and without checking
if the object returned has the former method, is error-prone.

Only if it's possible for the method to fail to return a valid
object. I don't believe that can happen in this case. If it
does, the page has more serious problems than simply calling a
non-existant method.


Besides, both of you violate Internet standards (namely RFCs 1036 and
2822) by using non-existing "From:" addresses and, not less important,
you disregard the rules of this newsgroup described in its FAQ which
say that you should trim your quotes to the absolute necessary.

There's nothing wrong with my From address, if you can figure out
what part to remove. Mail to that address is rarely read, though.
I do trim quotes to what I believe is necessary.
 
T

Thomas 'PointedEars' Lahn

Lee said:
Thomas 'PointedEars' Lahn said:
Lee said:
DU said:
Lee wrote:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return
false">an

I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by
another method, without checking if the reference is valid and
without checking if the object returned has the former method, is
error-prone.

Only if it's possible for the method to fail to return a valid
object.

No. From JavaScript version 1.5 on, "window" is removed from the core
language and becomes a host object. As client-side host objects are
part of the UA's DOM and those DOMs are different (although there are
some mutualities called "DOM Level 0"), their methods are different.
Since JScript never contained

I don't believe that can happen in this case.

What you believe is irrelevant. What specs and references say is
relevant. window.open() returns a reference to a Window object if
successful, `null' or at least not a Window object otherwise:

<http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/window.html#1202731>
Besides, both of you violate Internet standards (namely RFCs 1036
and 2822) by using non-existing "From:" addresses [...]

There's nothing wrong with my From address, [...]

IBTD!

| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]
(RFC 1036 "Standard for interchange of USENET messages", section 2.1.1)

| A mailbox receives mail. [...]
(RFC 2822 "Internet Message Format", section 3.4.)

| - Forging of news articles is generally censured. [...]
(RFC 1855 "Netiquette Guidelines", section 3.1.3)

| The standards upon which Usenet is built, that is, the specification
| for the system's operation, requires that the poster use a legitimate
| email address. Making exceptions to standards simply for short-term
| convenience is unwise at best. At worst, it jeopardizes the Internet's
| long-term viability to continue the same level of utility that it has
| enjoyed.
|
| Allowing standards to be broken is contradictory to the philosophy
| behind the Internet [...]
(<http://www.interhack.net/pubs/munging-harmful/>)

| From: Lee <[email protected]>
(<[email protected]>)

$ host -t mx cox.net
cox.net MX 100 mx.east.cox.net
cox.net MX 100 mx.west.cox.net
$ telnet mx.east.cox.net smtp
Trying 68.1.17.3...
Connected to mx.east.cox.net.
Escape character is '^]'.
220 lakermmtai17.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:54:42 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 lakermmtai17.cox.net ESMTP server closing connection
Connection closed by foreign host.
$ telnet mx.west.cox.net smtp
Trying 68.6.19.3...
Connected to mx.west.cox.net.
Escape character is '^]'.
220 fed1rmmtai19.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:55:38 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 fed1rmmtai19.cox.net ESMTP server closing connection
Connection closed by foreign host.

| *Acceptable Use Policy*
| Updated 2/4/04
|
| 14. *Newsgroups.* [...]
| *Forging, altering or removing header information is prohibited.*
| [...]
| *Cox reserves the right to discontinue access to any Usenet newsgroup
| at any time for any reason.*
| [...]
| *How to Contact Cox.* For any questions regarding this AUP, complaints
| of violations, or cancellation notices, please contact Cox at one of
| the following:
|
| E-mail: (e-mail address removed)
| [...]
(<http://www.cox.com/policy/#aup_14>)


There is *anything* wrong with your From "address".


PointedEars
 
T

Thomas 'PointedEars' Lahn

Lee said:
Thomas 'PointedEars' Lahn said:
Lee said:
DU said:
Lee wrote:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return
false">an

I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by
another method, without checking if the reference is valid and
without checking if the object returned has the former method, is
error-prone.

Only if it's possible for the method to fail to return a valid
object.

No. From JavaScript version 1.5 on, "window" is removed from the core
language and becomes a host object. As client-side host objects are
part of the UA's DOM and those DOMs are different (although there are
some mutualities called "DOM Level 0"), their methods are different.

I don't believe that can happen in this case.

What you believe is irrelevant. What specs and references say is
relevant. window.open() returns a reference to a Window object if
successful, `null' or at least not a Window object otherwise:

<http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/window.html#1202731>
Besides, both of you violate Internet standards (namely RFCs 1036
and 2822) by using non-existing "From:" addresses [...]

There's nothing wrong with my From address, [...]

IBTD!

| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]
(RFC 1036 "Standard for interchange of USENET messages", section 2.1.1)

| A mailbox receives mail. [...]
(RFC 2822 "Internet Message Format", section 3.4.)

| - Forging of news articles is generally censured. [...]
(RFC 1855 "Netiquette Guidelines", section 3.1.3)

| The standards upon which Usenet is built, that is, the specification
| for the system's operation, requires that the poster use a legitimate
| email address. Making exceptions to standards simply for short-term
| convenience is unwise at best. At worst, it jeopardizes the Internet's
| long-term viability to continue the same level of utility that it has
| enjoyed.
|
| Allowing standards to be broken is contradictory to the philosophy
| behind the Internet [...]
(<http://www.interhack.net/pubs/munging-harmful/>)

| From: Lee <[email protected]>
(<[email protected]>)

$ host -t mx cox.net
cox.net MX 100 mx.east.cox.net
cox.net MX 100 mx.west.cox.net
$ telnet mx.east.cox.net smtp
Trying 68.1.17.3...
Connected to mx.east.cox.net.
Escape character is '^]'.
220 lakermmtai17.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:54:42 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 lakermmtai17.cox.net ESMTP server closing connection
Connection closed by foreign host.
$ telnet mx.west.cox.net smtp
Trying 68.6.19.3...
Connected to mx.west.cox.net.
Escape character is '^]'.
220 fed1rmmtai19.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:55:38 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 fed1rmmtai19.cox.net ESMTP server closing connection
Connection closed by foreign host.

| *Acceptable Use Policy*
| Updated 2/4/04
|
| 14. *Newsgroups.* [...]
| *Forging, altering or removing header information is prohibited.*
| [...]
| *Cox reserves the right to discontinue access to any Usenet newsgroup
| at any time for any reason.*
| [...]
| *How to Contact Cox.* For any questions regarding this AUP, complaints
| of violations, or cancellation notices, please contact Cox at one of
| the following:
|
| E-mail: (e-mail address removed)
| [...]
(<http://www.cox.com/policy/#aup_14>)


There is *anything* wrong with your From "address".


PointedEars

Xref: uni-berlin.de comp.lang.javascript:446174
Thomas 'PointedEars' Lahn said:
Lee said:
DU said:
Lee wrote:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return
false">an

I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by
another method, without checking if the reference is valid and
without checking if the object returned has the former method, is
error-prone.

Only if it's possible for the method to fail to return a valid
object.

No. From JavaScript version 1.5 on, "window" is removed from the core
language and becomes a host object. As client-side host objects are
part of the UA's DOM and those DOMs are different (although there are
some mutualities called "DOM Level 0"), their methods are different.
Since JScript never contained

I don't believe that can happen in this case.

What you believe is irrelevant. What specs and references say is
relevant. window.open() returns a reference to a Window object if
successful, `null' or at least not a Window object otherwise:

<http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/window.html#1202731>
Besides, both of you violate Internet standards (namely RFCs 1036
and 2822) by using non-existing "From:" addresses [...]

There's nothing wrong with my From address, [...]

IBTD!

| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]
(RFC 1036 "Standard for interchange of USENET messages", section 2.1.1)

| A mailbox receives mail. [...]
(RFC 2822 "Internet Message Format", section 3.4.)

| - Forging of news articles is generally censured. [...]
(RFC 1855 "Netiquette Guidelines", section 3.1.3)

| The standards upon which Usenet is built, that is, the specification
| for the system's operation, requires that the poster use a legitimate
| email address. Making exceptions to standards simply for short-term
| convenience is unwise at best. At worst, it jeopardizes the Internet's
| long-term viability to continue the same level of utility that it has
| enjoyed.
|
| Allowing standards to be broken is contradictory to the philosophy
| behind the Internet [...]
(<http://www.interhack.net/pubs/munging-harmful/>)

| From: Lee <[email protected]>
(<[email protected]>)

$ host -t mx cox.net
cox.net MX 100 mx.east.cox.net
cox.net MX 100 mx.west.cox.net
$ telnet mx.east.cox.net smtp
Trying 68.1.17.3...
Connected to mx.east.cox.net.
Escape character is '^]'.
220 lakermmtai17.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:54:42 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 lakermmtai17.cox.net ESMTP server closing connection
Connection closed by foreign host.
$ telnet mx.west.cox.net smtp
Trying 68.6.19.3...
Connected to mx.west.cox.net.
Escape character is '^]'.
220 fed1rmmtai19.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:55:38 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 fed1rmmtai19.cox.net ESMTP server closing connection
Connection closed by foreign host.

| *Acceptable Use Policy*
| Updated 2/4/04
|
| 14. *Newsgroups.* [...]
| *Forging, altering or removing header information is prohibited.*
| [...]
| *Cox reserves the right to discontinue access to any Usenet newsgroup
| at any time for any reason.*
| [...]
| *How to Contact Cox.* For any questions regarding this AUP, complaints
| of violations, or cancellation notices, please contact Cox at one of
| the following:
|
| E-mail: (e-mail address removed)
| [...]
(<http://www.cox.com/policy/#aup_14>)


There is *anything* wrong with your From "address".


PointedEars
 
T

Thomas 'PointedEars' Lahn

Lee said:
Thomas 'PointedEars' Lahn said:
Lee said:
DU said:
Lee wrote:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return
false">an

I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by
another method, without checking if the reference is valid and
without checking if the object returned has the former method, is
error-prone.

Only if it's possible for the method to fail to return a valid
object.

No. From JavaScript version 1.5 on, "window" is removed from the core
language and becomes a host object. As client-side host objects are
part of the UA's DOM and those DOMs are different (although there are
some mutualities called "DOM Level 0"), their methods are different.

I don't believe that can happen in this case.

What you believe is irrelevant. What specs and references say is
relevant. window.open() returns a reference to a Window object if
successful, `null' or at least not a Window object otherwise:

<http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/window.html#1202731>
Besides, both of you violate Internet standards (namely RFCs 1036
and 2822) by using non-existing "From:" addresses [...]

There's nothing wrong with my From address, [...]

IBTD!

| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]
(RFC 1036 "Standard for interchange of USENET messages", section 2.1.1)

| A mailbox receives mail. [...]
(RFC 2822 "Internet Message Format", section 3.4.)

| - Forging of news articles is generally censured. [...]
(RFC 1855 "Netiquette Guidelines", section 3.1.3)

| The standards upon which Usenet is built, that is, the specification
| for the system's operation, requires that the poster use a legitimate
| email address. Making exceptions to standards simply for short-term
| convenience is unwise at best. At worst, it jeopardizes the Internet's
| long-term viability to continue the same level of utility that it has
| enjoyed.
|
| Allowing standards to be broken is contradictory to the philosophy
| behind the Internet [...]
(<http://www.interhack.net/pubs/munging-harmful/>)

| From: Lee <[email protected]>
(<[email protected]>)

$ host -t mx cox.net
cox.net MX 100 mx.east.cox.net
cox.net MX 100 mx.west.cox.net
$ telnet mx.east.cox.net smtp
Trying 68.1.17.3...
Connected to mx.east.cox.net.
Escape character is '^]'.
220 lakermmtai17.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:54:42 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 lakermmtai17.cox.net ESMTP server closing connection
Connection closed by foreign host.
$ telnet mx.west.cox.net smtp
Trying 68.6.19.3...
Connected to mx.west.cox.net.
Escape character is '^]'.
220 fed1rmmtai19.cox.net ESMTP server (InterMail vM.6.01.03.02
201-2131-111-104-20040324) ready Tue, 15 Jun 2004 14:55:38 -0400
mail from:<[email protected]>
250 Sender <[email protected]> Ok
rcpt to:<[email protected]>
550 Invalid recipient: <[email protected]>
quit
221 fed1rmmtai19.cox.net ESMTP server closing connection
Connection closed by foreign host.

| *Acceptable Use Policy*
| Updated 2/4/04
|
| 14. *Newsgroups.* [...]
| *Forging, altering or removing header information is prohibited.*
| [...]
| *Cox reserves the right to discontinue access to any Usenet newsgroup
| at any time for any reason.*
| [...]
| *How to Contact Cox.* For any questions regarding this AUP, complaints
| of violations, or cancellation notices, please contact Cox at one of
| the following:
|
| E-mail: (e-mail address removed)
| [...]
(<http://www.cox.com/policy/#aup_14>)


There is *everything* wrong with your From "address".


PointedEars
 
L

Lee

Thomas 'PointedEars' Lahn said:
What you believe is irrelevant. What specs and references say is
relevant. window.open() returns a reference to a Window object if
successful, `null' or at least not a Window object otherwise:

That specification doesn't say that any browser will ever
actually return null under any circumstances. It just says
that that is what they should do if they cannot open a window.

If I believed that it was at all likely for a browser to be
unable to open a window and for my page to still be useful
under those circumstances, it would be worth adding additional
tests.

There's nothing wrong with my From address, [...]

IBTD!

| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]
(RFC 1036 "Standard for interchange of USENET messages", section 2.1.1)

My From line does contain the electronic mailing address of the
person who sent the message, but in a different syntax. One that
requires the human who wants to send me mail to use common sense
to make the necessary modification. Certainly you're not going
to deny that this satisfies the intent of the RFC, are you?

I'm not going to change it, even if you do.
 
G

Grant Wagner

Lee said:
Thomas 'PointedEars' Lahn said:
DU said:
Lee wrote:
[...] <a href="http://www.google.com" target="extern"
onclick="window.open(this.href,'extern').focus();return false">an
I don't agree with DU's other statements, however:

Calling a method for an object, whose reference is returned by another
method, without checking if the reference is valid and without checking
if the object returned has the former method, is error-prone.

Only if it's possible for the method to fail to return a valid
object. I don't believe that can happen in this case. If it
does, the page has more serious problems than simply calling a
non-existant method.

<!-- THE FOLLOWING IS AUTO-GENERATED
BY SOMELAMEPOPUPBLOCKER(tm) -->
<SCRIPT Language="JavaScript">
<!-- HIDE FROM OLDER BROWSERS
window.open = null;
// -->
</ScripT>
....

Given the popup block attempt above, the following generates an error:
<a href="..." target="..."
onclick="
window.open(this.href, this.target, ...).focus();return false;
">

This code (an embelishment on Thomas' original suggestion) not only does not
generate an error, it provides reliable fall-back to an HTML-only approach
to open the new window
<a href="..." target="..."
onclick="
if (window.open) {
var w=window.open(this.href, this.target, ...);
if (w && !w.closed && w.focus) {
w.focus();
return false;
}
}
return true;
">

Although it's unlikely that any modern popup blocking mechanism would be so
horribly implemented, the additional tests for !w.closed and w.focus may in
fact notice other attempts (such as window.open = function() { return {}; })
and will provide the HTML-only fall-back behaviour for those as well.
Obviously any popup blocking attempt that allows the window to open, returns
a viable window object and closes the window will (or may) not be caught by
this code. As wouldn't any highly sophisticated popup blocking attempt that
returned something that appeared to be a true window object but did not
actually do anything.

However, the above demonstrates why it's a wise choice to test all objects
returned from methods before using them (and in fact why it's a wise idea to
test components of the DOM before use as well), it also demonstrates that
the simple act of checking for errors provides _additional_ functionality
which was not initially planned for (noticing _some_ popup blocking).

Obviously you can't catch everything, but what's the harm in trying? Now,
rather then coding the above everytime you need to open a popup, why not:

function openWindow(lnk, attributes, shouldFocus) {
if (window.open) {
var w = window.open(lnk.href, lnk.target, attributes);
if (w && !w.closed && w.focus) {
if (shouldFocus) {
w.focus();
}
return false;
}
}
return true;
}

<a href="..." target="..."
onclick="return openWindow(this, '<attributes>', true);">

As your coding skills and perhaps our ability to detect popup blockers
improves, additional code can be added to "openWindow()" without affecting
the existing functionality of pages that use it.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html
 
G

Grant Wagner

Thomas said:
There's nothing wrong with my From address, [...]

IBTD!

| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]
(RFC 1036 "Standard for interchange of USENET messages", section 2.1.1)

<snip>
There is *everything* wrong with your From "address".

So you blasted this newsgroup with 70 lines of OFF-TOPIC material (with 3 posts no less) to
complain about the fact that you don't like his From: header? What's the matter with you, don't you
see how totally _insane_ that is?

It's like complaining about what the guy in front of you in a movie theatre is wearing by screaming
at the top of your lungs. What he's wearing doesn't hurt you or impact you _directly_, it doesn't
change his fashion sense, and it tends to annoy the other movie-goers.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
* http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html
* Internet Explorer DOM Reference available at:
* http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp
* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html
 
L

Lee

Grant Wagner said:
Obviously you can't catch everything, but what's the harm in trying?

Because trying to code defensively against such obscure
situations is likely to lead to more problems than not.
Look at how many more lines of code you've added.

You need to draw a line in a reasonable place and accept
that if the browser can't handle that level of code, the
user must certainly be aware of its defects.

I test for features that aren't supported in some of the
more common browsers, and test for failure of methods to
return objects when there seems to be a reason to suspect
that they might fail, but I don't find it reasonable to
test to see if the user has sabotaged his own browser.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,059
Latest member
cryptoseoagencies

Latest Threads

Top