You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Escalada Sergio <se...@yahoo.com.ar> on 2007/08/06 16:15:31 UTC
Browser Back Button
Hello.
I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i
have a requirement mandatory to disable the browser back button while
the user is interacting with the aplication. The requirement is really
serious and compromise the usability of the aplication, can anyone tell
me if it is possible to do anything to avoid the use of the browser back
button?, or at least to control the use of it trying to avoid the
consecuences it carry.
Thanks in advance, sorry for my english.
Re: Browser Back Button
Posted by David Delbecq <de...@oma.be>.
One last suggestion
do all your sbmit using a JSF based AJAX framework (like ajax4JSF). That
way there is no navigation. The bad part are
1) that there is no change in url bar as user navigate
2) You can't use <redirect/> in your JSF navigation
3) You can't submit files (no way to send a file using XmlHttpRequest
for security reasons)
En l'instant précis du 07/08/07 11:18, simon s'exprimait en ces termes:
> On Mon, 2007-08-06 at 15:15 +0100, Escalada Sergio wrote:
>
>> Hello.
>> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i
>> have a requirement mandatory to disable the browser back button while
>> the user is interacting with the aplication. The requirement is really
>> serious and compromise the usability of the aplication, can anyone tell
>> me if it is possible to do anything to avoid the use of the browser back
>> button?, or at least to control the use of it trying to avoid the
>> consecuences it carry.
>>
>> Thanks in advance, sorry for my english.
>>
>
> There's no easy solution to this one AFAIK.
>
> A website (ie html, javascript, etc) is forbidden from modifying browser
> menus, etc for security reasons. The chaos that an evil website could
> create if this was permitted would be huge.
>
> The options are:
> (1) when a user clicks "back", your webapp does the right thing. This is
> surprisingly difficult to achieve, however. For a start you should avoid
> all session-scoped beans.
> (2) when a user clicks "back", you show a page saying "don't do that".
> (3) launch your webapp in a popup window. The popup window can be
> created without a menubar. Note that a user can still use shortcut keys
> to trigger "back", but that takes far more effort.
> (4) use an active-x control (for IE) or similar for firefox etc. to
> disable the back button. I don't know if this is actually feasable, and
> the user will certainly have to "authorise" the control to run. It's
> also browser-specific, ie you'll need to implement the equivalent for
> every browser type you support.
>
> The "auto-forward" solution proposed elsewhere in this thread is
> interesting. I suspect it has interesting side-effects though. You'll
> need to think through carefully whether this will work for your site.
>
> I don't know of any other solution. The problem is the fundamental web
> concept that a browser should never trust a website - and allowing a
> website to disable core browser functionality (back button in this case)
> certainly takes trust.
>
> I've always used option (3) in the end. It's not terribly pretty but it
> works.
>
> Regards,
>
> Simon
>
--
http://www.noooxml.org/
Re: Browser Back Button
Posted by simon <sk...@apache.org>.
On Mon, 2007-08-06 at 15:15 +0100, Escalada Sergio wrote:
> Hello.
> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i
> have a requirement mandatory to disable the browser back button while
> the user is interacting with the aplication. The requirement is really
> serious and compromise the usability of the aplication, can anyone tell
> me if it is possible to do anything to avoid the use of the browser back
> button?, or at least to control the use of it trying to avoid the
> consecuences it carry.
>
> Thanks in advance, sorry for my english.
There's no easy solution to this one AFAIK.
A website (ie html, javascript, etc) is forbidden from modifying browser
menus, etc for security reasons. The chaos that an evil website could
create if this was permitted would be huge.
The options are:
(1) when a user clicks "back", your webapp does the right thing. This is
surprisingly difficult to achieve, however. For a start you should avoid
all session-scoped beans.
(2) when a user clicks "back", you show a page saying "don't do that".
(3) launch your webapp in a popup window. The popup window can be
created without a menubar. Note that a user can still use shortcut keys
to trigger "back", but that takes far more effort.
(4) use an active-x control (for IE) or similar for firefox etc. to
disable the back button. I don't know if this is actually feasable, and
the user will certainly have to "authorise" the control to run. It's
also browser-specific, ie you'll need to implement the equivalent for
every browser type you support.
The "auto-forward" solution proposed elsewhere in this thread is
interesting. I suspect it has interesting side-effects though. You'll
need to think through carefully whether this will work for your site.
I don't know of any other solution. The problem is the fundamental web
concept that a browser should never trust a website - and allowing a
website to disable core browser functionality (back button in this case)
certainly takes trust.
I've always used option (3) in the end. It's not terribly pretty but it
works.
Regards,
Simon
Re: Browser Back Button
Posted by Mike Kienenberger <mk...@gmail.com>.
The complexity of using t:saveState will probably depend on your application.
I've got an application with more than 100 pages, but most of the uses
of those pages are self-contained. The t:saveState needs are either
self-contained in a specific page or only span a small number of
pages.
On 8/9/07, simon <sk...@apache.org> wrote:
> On Wed, 2007-08-08 at 23:53 +0100, Francisco Passos wrote:
> > Simple jsf apps can be written without session-scoped beans,
> > but it
> > takes some effort to avoid them in larger apps. The
> > t:saveState tag
> > doesn't really scale ;-)
> >
> > It's a shame to hear that... :(
> >
> > I guess this means "back to the drawing board".
> >
> > What kind of a scale are we talking about that makes t:saveState not
> > work as efficiently as one would like?
> >
> > And what is the main impact? Bandwidth? Server processing due to
> > constant serialization / desserialization of beans being kept from
> > previous requests?
> >
> > These are things important to take in consideration when deciding what
> > to go for at application design time, because after you commit either
> > to session or saveState, it gets hard to go back pretty quick.
>
> I didn't mean that there was a performance problem with t:saveState;
> there isn't one AFAIK. Although as an app gets more complex, the set of
> backing beans relevant to a page probably increases, and that will of
> course increase the amount of data that needs to be serialized and held
> by the t:saveState component. I guess that there is little impact when
> using server-side JSF state as that data needs to be held in either the
> session or the tree one way or another (though the JSF tree always gets
> serialized while the http session only gets serialized when memory is
> short). However if client-side state is being used then obviously that
> would increase bandwidth.
>
> However when an app gets up to 50 or 100 pages I expect that managing
> state by adding t:saveState tags all over the place will become hard to
> maintain. Some kind of "conversation" scope should be much easier to
> work with.
>
> Regards,
>
> Simon
>
>
>
Re: Browser Back Button
Posted by simon <sk...@apache.org>.
On Wed, 2007-08-08 at 23:53 +0100, Francisco Passos wrote:
> Simple jsf apps can be written without session-scoped beans,
> but it
> takes some effort to avoid them in larger apps. The
> t:saveState tag
> doesn't really scale ;-)
>
> It's a shame to hear that... :(
>
> I guess this means "back to the drawing board".
>
> What kind of a scale are we talking about that makes t:saveState not
> work as efficiently as one would like?
>
> And what is the main impact? Bandwidth? Server processing due to
> constant serialization / desserialization of beans being kept from
> previous requests?
>
> These are things important to take in consideration when deciding what
> to go for at application design time, because after you commit either
> to session or saveState, it gets hard to go back pretty quick.
I didn't mean that there was a performance problem with t:saveState;
there isn't one AFAIK. Although as an app gets more complex, the set of
backing beans relevant to a page probably increases, and that will of
course increase the amount of data that needs to be serialized and held
by the t:saveState component. I guess that there is little impact when
using server-side JSF state as that data needs to be held in either the
session or the tree one way or another (though the JSF tree always gets
serialized while the http session only gets serialized when memory is
short). However if client-side state is being used then obviously that
would increase bandwidth.
However when an app gets up to 50 or 100 pages I expect that managing
state by adding t:saveState tags all over the place will become hard to
maintain. Some kind of "conversation" scope should be much easier to
work with.
Regards,
Simon
Re: Browser Back Button
Posted by Francisco Passos <fr...@gmail.com>.
>
> Simple jsf apps can be written without session-scoped beans, but it
> takes some effort to avoid them in larger apps. The t:saveState tag
> doesn't really scale ;-)
It's a shame to hear that... :(
I guess this means "back to the drawing board".
What kind of a scale are we talking about that makes t:saveState not work as
efficiently as one would like?
And what is the main impact? Bandwidth? Server processing due to constant
serialization / desserialization of beans being kept from previous requests?
These are things important to take in consideration when deciding what to go
for at application design time, because after you commit either to session
or saveState, it gets hard to go back pretty quick.
On 8/7/07, simon <si...@chello.at> wrote:
>
> The server-side support for back buttons in MyFaces only ensures that
> the data held by JSF components doesn't get confused by back-buttons. Of
> course this issue is irrelevant when using client-side state-saving.
>
> However in either case, if there are any session-scoped backing beans
> being used by the app then they get out-of-sync with the GUI when back
> buttons are pressed, regardless.
>
> Simple jsf apps can be written without session-scoped beans, but it
> takes some effort to avoid them in larger apps. The t:saveState tag
> doesn't really scale ;-)
>
> Regards,
> Simon
>
> On Tue, 2007-08-07 at 16:45 -0400, Mike Kienenberger wrote:
> > I'm not entirely certain, but setting this parameter to 1 might solve
> > the problem for you if you use server-side state-saving. However, I
> > use client-side state-saving so I can't say for sure.
> >
> > <context-param>
> > <param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
> </param-name>
> > <param-value>1</param-value>
> > <description>Only applicable if state saving method is
> > "server" (= default).
> > Defines the amount (default = 20) of the latest
> > views are stored in session.
> > </description>
> > </context-param>
> >
> >
> > On 8/6/07, Escalada Sergio <se...@yahoo.com.ar> wrote:
> > > Hello.
> > > I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and
> i
> > > have a requirement mandatory to disable the browser back button while
> > > the user is interacting with the aplication. The requirement is really
> > > serious and compromise the usability of the aplication, can anyone
> tell
> > > me if it is possible to do anything to avoid the use of the browser
> back
> > > button?, or at least to control the use of it trying to avoid the
> > > consecuences it carry.
> > >
> > > Thanks in advance, sorry for my english.
> > >
>
>
Re: Browser Back Button
Posted by simon <si...@chello.at>.
The server-side support for back buttons in MyFaces only ensures that
the data held by JSF components doesn't get confused by back-buttons. Of
course this issue is irrelevant when using client-side state-saving.
However in either case, if there are any session-scoped backing beans
being used by the app then they get out-of-sync with the GUI when back
buttons are pressed, regardless.
Simple jsf apps can be written without session-scoped beans, but it
takes some effort to avoid them in larger apps. The t:saveState tag
doesn't really scale ;-)
Regards,
Simon
On Tue, 2007-08-07 at 16:45 -0400, Mike Kienenberger wrote:
> I'm not entirely certain, but setting this parameter to 1 might solve
> the problem for you if you use server-side state-saving. However, I
> use client-side state-saving so I can't say for sure.
>
> <context-param>
> <param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
> <param-value>1</param-value>
> <description>Only applicable if state saving method is
> "server" (= default).
> Defines the amount (default = 20) of the latest
> views are stored in session.
> </description>
> </context-param>
>
>
> On 8/6/07, Escalada Sergio <se...@yahoo.com.ar> wrote:
> > Hello.
> > I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i
> > have a requirement mandatory to disable the browser back button while
> > the user is interacting with the aplication. The requirement is really
> > serious and compromise the usability of the aplication, can anyone tell
> > me if it is possible to do anything to avoid the use of the browser back
> > button?, or at least to control the use of it trying to avoid the
> > consecuences it carry.
> >
> > Thanks in advance, sorry for my english.
> >
Re: Browser Back Button
Posted by Mike Kienenberger <mk...@gmail.com>.
I'm not entirely certain, but setting this parameter to 1 might solve
the problem for you if you use server-side state-saving. However, I
use client-side state-saving so I can't say for sure.
<context-param>
<param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
<param-value>1</param-value>
<description>Only applicable if state saving method is
"server" (= default).
Defines the amount (default = 20) of the latest
views are stored in session.
</description>
</context-param>
On 8/6/07, Escalada Sergio <se...@yahoo.com.ar> wrote:
> Hello.
> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i
> have a requirement mandatory to disable the browser back button while
> the user is interacting with the aplication. The requirement is really
> serious and compromise the usability of the aplication, can anyone tell
> me if it is possible to do anything to avoid the use of the browser back
> button?, or at least to control the use of it trying to avoid the
> consecuences it carry.
>
> Thanks in advance, sorry for my english.
>
Re: Browser Back Button
Posted by Richard Yee <ry...@cruzio.com>.
Sergio,
Take a look at the Spring WebFlow project.
One of the features of it is:
Receive automatic browser button support (back, forward, refresh) with
no custom coding.
-Richard
Escalada Sergio wrote:
> Hello.
> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and
> i have a requirement mandatory to disable the browser back button
> while the user is interacting with the aplication. The requirement is
> really serious and compromise the usability of the aplication, can
> anyone tell me if it is possible to do anything to avoid the use of
> the browser back button?, or at least to control the use of it trying
> to avoid the consecuences it carry.
>
> Thanks in advance, sorry for my english.
>
>
Re: Browser Back Button
Posted by Rene Guenther <in...@innflow.com>.
It works for Mozilla Firefox and Internet Explorer.
Not 100% sure about this:
By using the back button the browser wont send a new
request to the server. So what could happen?
Rene
On Tue, 7 Aug 2007 10:56:34 +0200
"Michał 'Gandalf' Stawicki" <st...@gmail.com> wrote:
> But this won't prevent any actions that might happen
>because of
> rendering previous page. It just makes sure that after
>rendering
> previous page the next page will be redisplayed.
>
> On 07/08/07, Adrian Mitev <ad...@googlemail.com>
>wrote:
>> Is this working on all browsers?
>>
>> 2007/8/7, Rene Guenther <in...@innflow.com>:
>> > Hi Sergio,
>> >
>> > we use on every JSF page the following javascript
>>code:
>> >
>> > <script>
>> > history.forward();
>> > </script>
>> >
>> > When the user pushes back button he is automatically
>> > forwarded again.
>> >
>> > Just a workaround though.
>> >
>> > Regards
>> > Rene
>> >
>> > On Mon, 06 Aug 2007 15:15:31 +0100
>> > Escalada Sergio <se...@yahoo.com.ar> wrote:
>> > > Hello.
>> > > I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my
>>WEB
>> > >Aplication, and i
>> > > have a requirement mandatory to disable the browser
>>back
>> > >button while the user is interacting with the
>>aplication.
>> > >The requirement is really serious and compromise the
>> > >usability of the aplication, can anyone tell me if it
>>is
>> > >possible to do anything to avoid the use of the
>>browser
>> > >back button?, or at least to control the use of it
>>trying
>> > >to avoid the consecuences it carry.
>> > >
>> > > Thanks in advance, sorry for my english.
>> >
>> >
>>
>>
>
>
> --
> Michał Stawicki
>
> stawicki@gmail.com
> http://stawicki.jasliska.pl
Re: Browser Back Button
Posted by Michał 'Gandalf' Stawicki <st...@gmail.com>.
But this won't prevent any actions that might happen because of
rendering previous page. It just makes sure that after rendering
previous page the next page will be redisplayed.
On 07/08/07, Adrian Mitev <ad...@googlemail.com> wrote:
> Is this working on all browsers?
>
> 2007/8/7, Rene Guenther <in...@innflow.com>:
> > Hi Sergio,
> >
> > we use on every JSF page the following javascript code:
> >
> > <script>
> > history.forward();
> > </script>
> >
> > When the user pushes back button he is automatically
> > forwarded again.
> >
> > Just a workaround though.
> >
> > Regards
> > Rene
> >
> > On Mon, 06 Aug 2007 15:15:31 +0100
> > Escalada Sergio <se...@yahoo.com.ar> wrote:
> > > Hello.
> > > I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB
> > >Aplication, and i
> > > have a requirement mandatory to disable the browser back
> > >button while the user is interacting with the aplication.
> > >The requirement is really serious and compromise the
> > >usability of the aplication, can anyone tell me if it is
> > >possible to do anything to avoid the use of the browser
> > >back button?, or at least to control the use of it trying
> > >to avoid the consecuences it carry.
> > >
> > > Thanks in advance, sorry for my english.
> >
> >
>
>
--
Michał Stawicki
stawicki@gmail.com
http://stawicki.jasliska.pl
Re: Browser Back Button
Posted by Adrian Mitev <ad...@googlemail.com>.
Is this working on all browsers?
2007/8/7, Rene Guenther <in...@innflow.com>:
>
> Hi Sergio,
>
> we use on every JSF page the following javascript code:
>
> <script>
> history.forward();
> </script>
>
> When the user pushes back button he is automatically
> forwarded again.
>
> Just a workaround though.
>
> Regards
> Rene
>
> On Mon, 06 Aug 2007 15:15:31 +0100
> Escalada Sergio <se...@yahoo.com.ar> wrote:
> > Hello.
> > I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB
> >Aplication, and i
> > have a requirement mandatory to disable the browser back
> >button while the user is interacting with the aplication.
> >The requirement is really serious and compromise the
> >usability of the aplication, can anyone tell me if it is
> >possible to do anything to avoid the use of the browser
> >back button?, or at least to control the use of it trying
> >to avoid the consecuences it carry.
> >
> > Thanks in advance, sorry for my english.
>
>
Re: Browser Back Button
Posted by Luka Surija <lu...@iytim.hr>.
But avoiding session scoped beans makes much harder to develop an
application, and application will be slower then using session scoped
beans (especially in combination with EJB3 session beans).
Rene Guenther wrote:
> The disabling of JavaScript is no problem for our intranet
> application, since our application requires JavaScript. Maybe someone
> will argue now that applications should not require javascript, but as
> long as the clients are happy with the application, we are happy :-)
>
> But you are right with the script not working anymore in > 2.0.4. I
> just tested it, the strange thing is, sometimes it works. I dont know
> why though.
>
> If disabling of back button functionallity is not possible, probably
> the best thing is to avoid session scoped beans as mentioned before.
>
> Rene
>
>
>
>
>
> On Tue, 07 Aug 2007 11:37:36 +0200
> David Delbecq <de...@oma.be> wrote:
>> Both plain script a onload fail to prevent history navigation in
>> firefox. 2.0.0.4.
>> The user have to manually 'reload' the previous page to activate the
>> foward script. Once he has reloaded, it always prevent navigation.
>> Untilm user disable javascript and goes back to that page. At that
>> point, he can go back and forth as much as he want, reactivate
>> javascript. It will again not work until user click the reload button.
>>
>> So, i won't build my application assuming user won't be able to use the
>> "back" button. Not to mention users usually don't like to be forbidden
>> the easy to use "back" button.
>> En l'instant précis du 07/08/07 08:35, Rene Guenther s'exprimait en ces
>> termes:
>>> Hi Sergio,
>>>
>>> we use on every JSF page the following javascript code:
>>>
>>> <script>
>>> history.forward();
>>> </script>
>>>
>>> When the user pushes back button he is automatically forwarded again.
>>>
>>> Just a workaround though.
>>>
>>> Regards
>>> Rene
>>>
>>> On Mon, 06 Aug 2007 15:15:31 +0100
>>> Escalada Sergio <se...@yahoo.com.ar> wrote:
>>>> Hello.
>>>> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and
>>>> i have a requirement mandatory to disable the browser back button
>>>> while the user is interacting with the aplication. The requirement is
>>>> really serious and compromise the usability of the aplication, can
>>>> anyone tell me if it is possible to do anything to avoid the use of
>>>> the browser back button?, or at least to control the use of it trying
>>>> to avoid the consecuences it carry.
>>>>
>>>> Thanks in advance, sorry for my english.
>>
>>
>> --
>> http://www.noooxml.org/
>>
>
>
Re: Browser Back Button
Posted by Rene Guenther <in...@innflow.com>.
The disabling of JavaScript is no problem for our intranet
application, since our application requires JavaScript.
Maybe someone will argue now that applications should not
require javascript, but as long as the clients are happy
with the application, we are happy :-)
But you are right with the script not working anymore in >
2.0.4. I just tested it, the strange thing is, sometimes
it works. I dont know why though.
If disabling of back button functionallity is not
possible, probably the best thing is to avoid session
scoped beans as mentioned before.
Rene
On Tue, 07 Aug 2007 11:37:36 +0200
David Delbecq <de...@oma.be> wrote:
> Both plain script a onload fail to prevent history
>navigation in
> firefox. 2.0.0.4.
> The user have to manually 'reload' the previous page to
>activate the
> foward script. Once he has reloaded, it always prevent
>navigation.
> Untilm user disable javascript and goes back to that
>page. At that
> point, he can go back and forth as much as he want,
>reactivate
> javascript. It will again not work until user click the
>reload button.
>
> So, i won't build my application assuming user won't be
>able to use the
> "back" button. Not to mention users usually don't like
>to be forbidden
> the easy to use "back" button.
> En l'instant précis du 07/08/07 08:35, Rene Guenther
>s'exprimait en ces
> termes:
>> Hi Sergio,
>>
>> we use on every JSF page the following javascript code:
>>
>> <script>
>> history.forward();
>> </script>
>>
>> When the user pushes back button he is automatically
>>forwarded again.
>>
>> Just a workaround though.
>>
>> Regards
>> Rene
>>
>> On Mon, 06 Aug 2007 15:15:31 +0100
>> Escalada Sergio <se...@yahoo.com.ar> wrote:
>>> Hello.
>>> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB
>>>Aplication, and
>>> i have a requirement mandatory to disable the browser
>>>back button
>>> while the user is interacting with the aplication. The
>>>requirement is
>>> really serious and compromise the usability of the
>>>aplication, can
>>> anyone tell me if it is possible to do anything to avoid
>>>the use of
>>> the browser back button?, or at least to control the use
>>>of it trying
>>> to avoid the consecuences it carry.
>>>
>>> Thanks in advance, sorry for my english.
>
>
> --
> http://www.noooxml.org/
>
Re: Browser Back Button
Posted by David Delbecq <de...@oma.be>.
Both plain script a onload fail to prevent history navigation in
firefox. 2.0.0.4.
The user have to manually 'reload' the previous page to activate the
foward script. Once he has reloaded, it always prevent navigation.
Untilm user disable javascript and goes back to that page. At that
point, he can go back and forth as much as he want, reactivate
javascript. It will again not work until user click the reload button.
So, i won't build my application assuming user won't be able to use the
"back" button. Not to mention users usually don't like to be forbidden
the easy to use "back" button.
En l'instant précis du 07/08/07 08:35, Rene Guenther s'exprimait en ces
termes:
> Hi Sergio,
>
> we use on every JSF page the following javascript code:
>
> <script>
> history.forward();
> </script>
>
> When the user pushes back button he is automatically forwarded again.
>
> Just a workaround though.
>
> Regards
> Rene
>
> On Mon, 06 Aug 2007 15:15:31 +0100
> Escalada Sergio <se...@yahoo.com.ar> wrote:
>> Hello.
>> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and
>> i have a requirement mandatory to disable the browser back button
>> while the user is interacting with the aplication. The requirement is
>> really serious and compromise the usability of the aplication, can
>> anyone tell me if it is possible to do anything to avoid the use of
>> the browser back button?, or at least to control the use of it trying
>> to avoid the consecuences it carry.
>>
>> Thanks in advance, sorry for my english.
--
http://www.noooxml.org/
Re: Browser Back Button
Posted by Rene Guenther <in...@innflow.com>.
Hi Sergio,
we use on every JSF page the following javascript code:
<script>
history.forward();
</script>
When the user pushes back button he is automatically
forwarded again.
Just a workaround though.
Regards
Rene
On Mon, 06 Aug 2007 15:15:31 +0100
Escalada Sergio <se...@yahoo.com.ar> wrote:
> Hello.
> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB
>Aplication, and i
> have a requirement mandatory to disable the browser back
>button while the user is interacting with the aplication.
>The requirement is really serious and compromise the
>usability of the aplication, can anyone tell me if it is
>possible to do anything to avoid the use of the browser
>back button?, or at least to control the use of it trying
>to avoid the consecuences it carry.
>
> Thanks in advance, sorry for my english.
Re: Browser Back Button
Posted by Luka Surija <lu...@iytim.hr>.
Escalada Sergio wrote:
> Hello.
> I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i
> have a requirement mandatory to disable the browser back button while
> the user is interacting with the aplication. The requirement is really
> serious and compromise the usability of the aplication, can anyone
> tell me if it is possible to do anything to avoid the use of the
> browser back button?, or at least to control the use of it trying to
> avoid the consecuences it carry.
>
> Thanks in advance, sorry for my english.
>
I'm using this solution and it works fine for me:
<tr:document onload="window.history.forward(1)" >
--
Luka Šurija
luka.surija@iytim.hr
+385 98 434 061
I.Y. tim d.o.o.
www.iytim.hr
info@iytim.hr