Intercept Ctrl-N (new browser window) from JavaScript?

[Kai Grossjohann]

It seems that Ctrl-N in Mozilla opens a new empty browser window.
That's fine, I don't need to do anything about it.

But Ctrl-N in IE appears to clone the current window. Is there a way
to intercept the key so that I can do stuff on the server side to make
the new window behave correctly?

(We have a JSP-based webapp which stores state in the session. Now if
two windows access (and modify!) the same session, then madness will
result. So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then they
have two instances of the application that they can interact with
independently.)

Kai

[Richard Cornford]

"Kai Grossjohann" <ka*@emptydomai n.de> wrote in message
news:87******** ****@emptyhost. emptydomain.de. ..

It seems that Ctrl-N in Mozilla opens a new empty browser
window. That's fine, I don't need to do anything about it.

But Ctrl-N in IE appears to clone the current window. Is
there a way to intercept the key so that I can do stuff on
the server side to make the new window behave correctly?

(We have a JSP-based webapp which stores state in the session.
Now if two windows access (and modify!) the same session, then
madness will result.
Does it? Perhaps you should be looking at creating more robust session
interaction code.
So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then
they have two instances of the application that they can interact
with independently.)

Client-side (JavaScript) fixes are not going to help (especially if they
involve intercepting keyboard events) as it is just not that reliable.
So the degree to which it is important to notify the server of the
creation of a new window is also the degree to which it is inappropriate
to attempt to use client side scripting for the task. Fix the
server-side code so that it can cope with multiple window interacting
with the same session.

Richard.

[Markus Ernst]

"Kai Grossjohann" <ka*@emptydomai n.de> schrieb im Newsbeitrag
news:87******** ****@emptyhost. emptydomain.de. ..

It seems that Ctrl-N in Mozilla opens a new empty browser window.
That's fine, I don't need to do anything about it.

But Ctrl-N in IE appears to clone the current window. Is there a way
to intercept the key so that I can do stuff on the server side to make
the new window behave correctly?

(We have a JSP-based webapp which stores state in the session. Now if
two windows access (and modify!) the same session, then madness will
result. So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then they
have two instances of the application that they can interact with
independently.)

It seems that IE opens the new window without a name even if the original
one has a name. So you could try something like (I am sorry I don't know the
JSP syntax):
- Create the session in an entry page before starting the application
- Start the app in a new window with window.open() and use the session id as
window name
- Put a script in the head some like

if(top.name != "[input session id here]") {
location.replac e("[input page name here]?sessionclone=y es");
}

- At the server side you check for the sessionclone getvariable.

HTH
Markus

[Kai Grossjohann]

"Richard Cornford" <Ri*****@litote s.demon.co.uk> writes:

"Kai Grossjohann" <ka*@emptydomai n.de> wrote in message
news:87******** ****@emptyhost. emptydomain.de. ..

(We have a JSP-based webapp which stores state in the session.
Now if two windows access (and modify!) the same session, then
madness will result.
Does it? Perhaps you should be looking at creating more robust session
interaction code.

It seems I was unable to think of a better design. The webapp has
queries and result lists. It provides functionality for showing more
than one query and more than one result list in the same session; an
identifier for the query/result list is stored in the URL.

Lets's say I'm viewing ResultList.jsp? id=foo, which gives the id of
the result list. Now I click on a column heading which means to sort
the result list by that column. Then the webapp modifies the session
attribute to indicate "sorted by column X", then reinvokes
ResultList.jsp? id=foo. That JSP looks in the session for the result
list and visualizes it.

This two-step approach is useful because it means that the reload
button will always work: the URL shown in in the location bar of the
window just reads the current state from the session, all user actions
first modify the session then redirect back to the same
session-display URL.

Now hitting Ctrl-N means that two windows will show the same session
attribute (identified by id=foo). Now the user sorts on a column in
one window and hits reload in another window, and then the other
window will display the sort order set by the user for the first
window.

How to solve this problem?

So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then
they have two instances of the application that they can interact
with independently.)

Client-side (JavaScript) fixes are not going to help (especially if they
involve intercepting keyboard events) as it is just not that reliable.

Actually, I wanted to intercept the creation of a new window, not the
user hitting Ctrl-N... Some browsers might use different kbd
shortcuts.
So the degree to which it is important to notify the server of the
creation of a new window is also the degree to which it is inappropriate
to attempt to use client side scripting for the task. Fix the
server-side code so that it can cope with multiple window interacting
with the same session.

If it was that easy...

Kai

[Kai Grossjohann]

"Markus Ernst" <derernst@NO#SP #AMgmx.ch> writes:

It seems that IE opens the new window without a name even if the original
one has a name. So you could try something like (I am sorry I don't know the
JSP syntax):
- Create the session in an entry page before starting the application
- Start the app in a new window with window.open() and use the session id as
window name
- Put a script in the head some like

if(top.name != "[input session id here]") {
location.replac e("[input page name here]?sessionclone=y es");
}

- At the server side you check for the sessionclone getvariable.

Beautiful!

Kai

[Michael Winter]

Kai Grossjohann wrote on 12 Dec 2003 at Fri, 12 Dec 2003 11:11:49
GMT:

It seems that Ctrl-N in Mozilla opens a new empty browser
window. That's fine, I don't need to do anything about it.

But Ctrl-N in IE appears to clone the current window. Is there
a way to intercept the key so that I can do stuff on the server
side to make the new window behave correctly?

(We have a JSP-based webapp which stores state in the session.
Now if two windows access (and modify!) the same session, then
madness will result. So I'd like to clone the server-side
session, as well. That way, users can do what they expect --
they hit Ctrl-N and then they have two instances of the
application that they can interact with independently.)

What good will that do? They can still do it from the menu bar. Opera
users can duplicate a page from the menu bar or using the default
Ctrl+Shift+N keystroke[1] so your block won't work. What if I opened
a link in another window, then went back to the page in the original
window? What if I use another browser that uses Ctrl+N for a
completely different function and you block it?

I think the only reliable solution is to add concurrency to your
pages.

Mike
[1] I say default because I could change it to anything I want.

--
Michael Winter
M.******@blueyo nder.co.invalid (replace ".invalid" with ".uk")

[Kai Grossjohann]

Michael Winter <M.******@bluey onder.co.invali d> writes:

What good will that do? They can still do it from the menu bar.

I'm sorry. Of course, I wanted to intercept the *operation*, not the
*keystroke*. But there's nothing "of course" about it for you as a
reader.

Kai

[Richard Cornford]

"Kai Grossjohann" <ka*@emptydomai n.de> wrote in message
news:87******** ****@emptyhost. emptydomain.de. ..
<snip>

It seems I was unable to think of a better design. The webapp
has queries and result lists. It provides functionality for
showing more than one query and more than one result list in
the same session; an identifier for the query/result list is
stored in the URL.

Lets's say I'm viewing ResultList.jsp? id=foo, which gives the
id of the result list. Now I click on a column heading which
means to sort the result list by that column. Then the webapp
modifies the session attribute to indicate "sorted by column X",
then reinvokes ResultList.jsp? id=foo. That JSP looks in the
session for the result list and visualizes it.

This two-step approach is useful because it means that the
reload button will always work: the URL shown in in the
location bar of the window just reads the current state
from the session, all user actions first modify the session
then redirect back to the same session-display URL.

Now hitting Ctrl-N means that two windows will show the same
session attribute (identified by id=foo). Now the user sorts
on a column in one window and hits reload in another window,
and then the other window will display the sort order set by
the user for the first window.

How to solve this problem?
As I read it the problem stems from the decision to sort the data stored
in the session, and I am unsure why you are doing this at all. I would
have been inclined to store the data in the session in a form that
facilitated its efficient storage and ordered retrieval, but have the
script that generated the HTML output make the decision about what order
to present the information in. Storing/sending the sorting criteria and
direction in the URL with the id of the results list, i.e.:-

ResultList.jsp? id=foo&sortCol= 3&sordDirection =up

As a result refreshing would work because the user would get the date
back in the form they last specified in the URL. The back button would
work, as they would get the date in the form specified in the previous
URL. And it would not matter if the user had half a dozen browsers
simultaneously accessing id=foo as they would all be getting the data
sorted in the way they asked for individually.

In addition, with appropriate caching and expires headers, the server
load could be reduced because any response to -
ResultList.jsp? id=foo&sortCol= 3&sordDirection =up - would have identical
content to other request for the same URL so the browser could (and so
should) be able to re-use a cached page if it had one. While as you have
it now the server must re-sort the data in the session on each and every
occasion that the user requests a change in the order of presentation,
even if that is just a return to the order in which they previously
requested it.

<snip>Actually, I wanted to intercept the creation of a new window,
not the user hitting Ctrl-N... Some browsers might use
different kbd shortcuts.

There is no window/tab opening/creation/cloning/etc event to intercept.
While keyboard events can be responded to, but as you say that would
depend on a lot of invalid assumptions about the meaning of key
sequences and also be subject to all of the unreliability of client-side
scripting in general and mechanisms aimed at preventing the antisocial
use of scripts to destroy normal browser UI features (no right click and
so on). There is no client-side solution and Markus Ernst's proposal
would introduce more problems than it could hope to solve while still
not suitably addressing your window cloning problem, no matter how
"Beautiful" it may seem at first.

Richard.

[Markus Ernst]

"Richard Cornford" <ri*****@litote s.demon.co.uk> schrieb im Newsbeitrag
news:br******** **@sparta.btint ernet.com...
<snip>

There is no client-side solution and Markus Ernst's proposal
would introduce more problems than it could hope to solve while still
not suitably addressing your window cloning problem, no matter how
"Beautiful" it may seem at first.

My proposal is not a solution for the actual problem. It is just a
workaround for some cases:

Case 1: UA is not Internet Explorer. There is no problem, as a new window
will be empty.

Case 2: UA is Internet Explorer, and Javascript turned on. Here the solution
I proposed works as it creates a new session. Note that I did not discuss
the question if that is desirable or not. There are types of applications
where this is undoubtedly not desirable, for example a shopping cart. If you
create a new session there, you will confuse the user by giving two
different shopping carts which is definitely not desirable. But this is not
the type of application that the OP was related to.

Case 3: UA is Internet Explorer, and Javascript turned off. Here you have 2
possibilities:
a) You open the applicaton with window.open() as I proposed to prevent
non-Javascript users from opening it at all. This is ok if Javascript is
crucial in other parts of your application, too - for example select boxes
with Javascript-created dynamic option field sets or whatever. Of course you
have to tell your users to activate Javascript, and some will be angry about
you.
b) You provide a way to open the application without Javascript (<a
href="myapp.jsp " target="[session id]"> will do the same as the
window.open() I proposed). So a very small part of users will have the
cloned session problem, as I think most people who have installed Internet
Explorer don't care about disabling Javascript.

You could even hide the whole thing from non-IE browsers by using the 3b)
solution by doing a serverside browser sniff and write the target attribute
only to IE browsers. So all popup blocker and broken back button issues will
not occur on non-IE browsers.

Maybe my proposal introduces more problems that I don't see, then I am very
interested to know about them.

--
Markus

[Kai Grossjohann]

"Richard Cornford" <ri*****@litote s.demon.co.uk> wrote in message news:<br******* ***@sparta.btin ternet.com>...

"Kai Grossjohann" <ka*@emptydomai n.de> wrote in message
news:87******** ****@emptyhost. emptydomain.de. ..
<snip>

This two-step approach is useful because it means that the
reload button will always work: the URL shown in in the
location bar of the window just reads the current state
from the session, all user actions first modify the session
then redirect back to the same session-display URL.

Now hitting Ctrl-N means that two windows will show the same
session attribute (identified by id=foo). Now the user sorts
on a column in one window and hits reload in another window,
and then the other window will display the sort order set by
the user for the first window.

How to solve this problem?
As I read it the problem stems from the decision to sort the data stored
in the session, and I am unsure why you are doing this at all. I would
have been inclined to store the data in the session in a form that
facilitated its efficient storage and ordered retrieval, but have the
script that generated the HTML output make the decision about what order
to present the information in. Storing/sending the sorting criteria and
direction in the URL with the id of the results list, i.e.:-

ResultList.jsp? id=foo&sortCol= 3&sordDirection =up

As a result refreshing would work because the user would get the date
back in the form they last specified in the URL. The back button would
work, as they would get the date in the form specified in the previous
URL. And it would not matter if the user had half a dozen browsers
simultaneously accessing id=foo as they would all be getting the data
sorted in the way they asked for individually.

(Aside: the data as stored in the session is not necessarily sorted,
we just store the sorting criteria in the session, along with the data
itself.)

One reason for not putting this information (which way is the data
sorted) into the URL is that it causes inconsistencies with frames.
Our application uses frames heavily. Now if one subframe changes its
URL, and people hit the web browser's reload button, then madness will
result.

You might say that the madness results from using frames in the first
place. I agree. However, "thou shalt make that it looketh like this
Windows app over here", management decreed. And that Windows app has
resizable, err, I think they're called panes in the Windows world.
Rather than trying to emulate drag and drop in JavaScript, I opted for
using frames.

Another reason is that users might enter a new query into the query
form. Then our app stores a new result list under the old id. I
think you can quickly see how cloning a window, typing a new query in
one window, then hitting reload in the other one, will lead to
problems ;-) There are reports from real-world users who have result
lists containing thousands of items, so storing the result lists
themselves in the URL is not practical.
In addition, with appropriate caching and expires headers, the server
load could be reduced because any response to -
ResultList.jsp? id=foo&sortCol= 3&sordDirection =up - would have identical
content to other request for the same URL so the browser could (and so
should) be able to re-use a cached page if it had one. While as you have
it now the server must re-sort the data in the session on each and every
occasion that the user requests a change in the order of presentation,
even if that is just a return to the order in which they previously
requested it.
Well, surely storing the sort order information in the session, rather
than the URL, does not prevent us from using clever caching, if that
proves necessary.
<snip>

Actually, I wanted to intercept the creation of a new window,
not the user hitting Ctrl-N... Some browsers might use
different kbd shortcuts.

There is no window/tab opening/creation/cloning/etc event to intercept.
While keyboard events can be responded to, but as you say that would
depend on a lot of invalid assumptions about the meaning of key
sequences and also be subject to all of the unreliability of client-side
scripting in general and mechanisms aimed at preventing the antisocial
use of scripts to destroy normal browser UI features (no right click and
so on). There is no client-side solution and Markus Ernst's proposal
would introduce more problems than it could hope to solve while still
not suitably addressing your window cloning problem, no matter how
"Beautiful" it may seem at first.

Can you give examples of the problems that might result, or is it just
a general gut feeling? I share the general gut feeling, but then
there are these nasty requirements on what I have to do...

Kai