Using browser BACK button causes Internal Error in WC

Hi all,

Our application UI is structured so that a “main” form is used as a “shell” and all other application forms are displayed in a tabless panel on that form. This approach works great in Smart Client and allows us to achieve the application UI requirements. However, when the application is used in a Web Client, any usage of the browser BACK button (or an accidental press of the backspace key while a form field is not focused, which basically results in the browser executing the BACK action) results in an “Internal Error”. In some cases, end-users can “recover” from that error but most commonly the client session becomes unusable and end-users need to close the browser and start a new session.

We do use the SolutionModel quite a bit and dynamically change or create the UI of the forms which are then displayed in the tabless panel. The browser BACK action is basically destroying all that. Looking at the server log, almost always the issues start with an error similar to:

[ERROR] Caught unhandled exception: java.lang.IllegalArgumentException: A child with id 'sv_F6AE0E8D_6A55_49E9_9937_E577EDE58454' already exists: [MarkupContainer [Component id = servoywebform]]

or

org.apache.wicket.markup.MarkupException: Unable to find component with id 'webform' in [MarkupContainer [Component id = sv_517AB063_CF72_49A6_9DC1_B97370DB76B7]]. This means that you declared wicket:id=webform in your markup, but that you either did not add the component to your page at all, or that the hierarchy does not match.

What can be done to resolve this issue?
Ideally, there should be an event at the solution level which is fired when the browser BACK action is invoked which we can use to provide application-specific behavior/handling.

Does your solution require login? Maybe the back button is getting your users back to the loginform and something breaks up.

The best solution for the back browser issue (ad especially the backspace issue) is to embed the webclient in an iFrame so that the browser loads an html page containing the iframe with web client and any back in history command is passed to the html page and not to the webclient.

Have a look at my Advanced WebClient Presentation for Servoy World 2008: http://www.sintpro.com/downloads_eng.php

ngervasi:
Does your solution require login? Maybe the back button is getting your users back to the loginform and something breaks up.

The best solution for the back browser issue (ad especially the backspace issue) is to embed the webclient in an iFrame so that the browser loads an html page containing the iframe with web client and any back in history command is passed to the html page and not to the webclient.

Have a look at my Advanced WebClient Presentation for Servoy World 2008: http://www.sintpro.com/downloads_eng.php

The solution does require login but the back button does not get the user all the way back to the login.
Thanks for the suggestion of using an iFrame, unfortunately it does not work - both a backspace and the browser BACK button still break the embedded Servoy Web Client if any modifications are made using the SolutionModel.

That’s weird, I tested it opening a new tab, loading the main google page then loading a webpage containing the webclient inside an iFrame; whenever I hit the back button I go back to google, if I go forward I get back to the servoy page and webclient is still working fine.
Maybe you are using the solution model in some onShow method and that method is triggered again when you go forward in history?

the back button should just work, it should go back to the previous main form
If you have an example where it doesn’t go well, please make a case for this

jcompagner:
the back button should just work, it should go back to the previous main form
If you have an example where it doesn’t go well, please make a case for this

The scenario which we have where the BACK button does not work involves a “main” or a shell form which does not change. In other words, the application has one main form which never changes. On it there is a panel where at runtime different forms are displayed, but they in turn are “hosted” on another “panel” form which is being modified using the SolutionModel.

The runtime behavior is something like this:

State 1: Shell Form [ Panel Form with header and footer visible [App Form 1] ]
State 2: Shell Form [ Panel Form with header and footer not visible [App Form 2] ]

While in State 2, if the the user clicks the BACK button, the UI changes to show the App Form 1, however the Panel Form (which was modified in State 2 to hide its header/footer) is not in its expected state and fails with the errors which I listed in my first post. From that point on, the users are getting Internal Errors. Unfortunately, we cannot “revert” programmatically the Panel Form as it should be in State 1 because no event is fired when the user hits the BACK button. The same issue happens if we do not use a Panel Form but instead change the Shell Form through the SolutionModel when transitioning from State 1 to State 2

if your main form never changes, then your url in the browser should never change when in the app
So the back button does nothing then, except going back the the page before the solution really loads (so that is the solution loader page or the quick redirect that you see to get all the browser info (the “loading…” page))

jcompagner:
if your main form never changes, then your url in the browser should never change when in the app
So the back button does nothing then, except going back the the page before the solution really loads (so that is the solution loader page or the quick redirect that you see to get all the browser info (the “loading…” page))

This is not the behavior which we are seeing. Every time a form is loaded in the Panel Form, the URL changes:

State 1: http://server:8080/servoy-webclient/?x= … qKkjdS20xA
State 2: http://server:8080/servoy-webclient/?x= … 8jURUBMSuQ

Note the ?x=… part of the URL - it changes constantly with every click/callback to the server which loads a new form in the panel

that is then very weird, because every click is an ajax request that just updates the contents of the page, its not a redirect to another page… that only should happen if you change the main form.

if you can create a sample solution that shows that please make a case