Verj.io provides explicit support for the browser back button. The studio specifies for each form whether or not that particular form supports use of the back button.

When back button support is enabled, the end user can use the browser back button to navigate to a previously displayed page and then continue execution from that point. Each time a page is displayed (in any circumstance, including the back button), it is refreshed with the latest content from the server so the user always sees the latest data for a page. Before activating back button support, the designer should be satisfied that the logic of the form’s processing can support the arrival of input from an unexpected page. For example, a user might navigate a sequence of pages PAGE1, PAGE2, PAGE3, PAGE4, then use the back button to return to PAGE1 and click a link to display PAGE10. From the perspective of the executing form, it has just displayed PAGE4 then receives input from PAGE1. This can easily lead to failures unless the form has been designed with this in mind.

The user can also use the back button to navigate to a previous form so long as that form is in the current “call stack” i.e. the form state is still held by the server (see below). When the user uses the back button to display a form page where the form is not in the current call stack, the invalid page error page is displayed. At this point, the user can return to the current (working) form by clicking the browser forward button.

When back button support is disabled, the user won’t be able to return to a previous page (note: with the exception of Opera – see below). The implementation of this varies according to browser:

Firefox: calls to form pages or new forms are not added to the browser history. The back button, if clickable (i.e. not greyed out) will return to the page that invoked the first form.
Internet Explorer: same as Firefox
Chrome: calls to form pages or new forms are added to the browser history. Therefore the back button is clickable, but when used, it simply redisplays the latest page of the current form; any data entered by the user but not yet posted to the server will disappear when the page is redisplayed.
Safari : same as Chrome
Opera: of the major browsers, Opera is the exception. It differs from the others in that each page is not refreshed immediately when the user clicks the back button. See below.

Please bear in mind that this information on how individual browsers work may well change as new versions are released.

A back button event is supplied to allow a form to perform any processing that may be necessary when the back button is used e.g. reset flags etc.

How specified

The default for browser back button support is specified in the Form Options tab of Studio Preferences for each studio. If this parameter is not specified, the default is false i.e. back button support is disabled. This default can be overridden at form level with property Browser Back Button Support in the General tab of form properties as shown below.

Back button support can also be enabled and disabled programatically using system variable $BACK_BUTTON_SUPPORTED.

How it works (all browsers except Opera)

In normal operation (i.e. when the back button is not used), the Verj.io system uses as technique called Post-Redirect-Get. With this technique, each user request is divided into two messages: the first request is an HTTP POST and transmits the browser page to the server and runs any events. The server replies with a very short redirect message which causes the browser to transmit an HTTP GET request. The server then displays the page.

The result is that each page is actually displayed in response to a HTTP GET request. Hence, when the user returns to a page via the browser back (or forward) button, the GET request is re-fired and displays that page. A key aspect of this technique is that each page is always refreshed from the server so the user always sees the latest state of a page – the user is never out of synch with the server. A side effect of this technique is that when the same page is displayed many times e.g. a search page, the user will only see the latest results and is unable to back button to a previous search.

When back button support is enabled, parameters are attached to the GET request which specify the display of a specific page. However, when back button support is disabled, these parameters are omitted and the URL is always exactly the same for all pages, and is interpreted by the server as a request to display the current page.

How it works (Opera)

Opera differs from the other browsers (described in the previous section) in that when the back or forward button is clicked, the browser does not re-fire the URL to refresh the page with the latest contents from the server. However, when the user clicks on something on that page e.g. a button, the Verj.io server receives a request and then behaves like this:

Back button support enabled: the page is refreshed with the latest contents from the server; any input from the user at this point is ignored. Form the user’s perspective, they have paged backwards, clicked on something and it seems as if that click has been ignored. However, if the user then repeats the click, it will then work as expected.
Back button support disabled: the user is returned to the current page of the current form, any input is ignored.

This behaviour is not ideal, and it is to be hoped that Opera will eventually behave the same as the other browsers.

Back button and Ajax

When the Ajax option is enabled for a form, the Post-Redirect-Get mechanism described above is only used when a change of page or form occurs. For requests that result in a re-display of the same page, an Ajax post mechanism is used instead. These Ajax requests are not treated by browsers as regular requests and are not added to the browser history so use of the back button is not applicable.

A side effect of this browser behaviour occurs when the user uses the back button to return to a page and then clicks buttons/links etc on that page which are implemented as Ajax posts. The browser does not consider that these requests are normal posts that should change the history stack, so the forward button is still enabled. Here is an illustration:

User displays PAGE1, fills in some data
Moves forwards to PAGE2 via a next page button and fills in some more data
User clicks back button to return to PAGE1
Then adds/changes data on PAGE1 using buttons/links that result in Ajax posts
User clicks the forward button to return to PAGE2
Then adds/changes data on PAGE2 using buttons/links that result in Ajax posts

The user can be changing data on two or more pages and navigating between these pages just using the browser back/forward buttons. This situation can occur normally when back button support is enabled and is certainly something that developers should be aware of. If this is a problem, the only way to stop it is by disabling either back button support or Ajax support for the form.

Invalid pages

The server is only able to display a page when the page is part of a form which is still held in the server’s memory. This is the case for the “current” form and for all forms in the “current stack” e.g. in the following scenario:

FORM1 calls..

FORM2 calls..

FORM3 calls..

FORM4

All forms – FORM1, FORM2, FORM3 and FORM4 - are in memory and all pages for these forms can be displayed, so the user can use the back/forward buttons to navigate from FORM4 to any of the other forms.

However, in the following scenario:

FORM1 calls..

FORM2 calls..

FORM3 returns..

FORM2 calls..

FORM4

an attempt by the user to use the back button to navigate from FORM4 to one of the pages in FORM3 will be unsuccessful because FORM3 is no longer in memory. There are a number of these scenarios where the target page is part of a form that is no longer accessible to the server because the referenced form has terminated and been removed from the server’s memory. This occurs in the following circumstances:

A form’s final page has been displayed.
An FPL GOTO FORM command (API WebForm.gotoForm() method) has been issued.
A GOTO URL command (API WebForm.gotoForm() method) has been issued.
A RETURNFROM FORM command (API WebForm.returnFromForm() method) has been issued. This is the second scenario shown above.

In all of these circumstances, the system displays the invalid page error page – this is a customizable JSP. At this point, the user can return to their working application by reversing their action – usually by clicking the browser forward button. The display of this page should be considered as “normal operation” as opposed to an error situation.

Back button event

When the system detects that a post has been received from a page or a form out of the expected sequence, the form’s back button event, if configured, is executed. This event is provided so that a form can execute any cleanup processing that may be needed e.g. reset field values that are used to control the form’s processing etc. The back button event is executed after any input from the new page is processed, but before any other events.

This event fires in the following circumstances:

when use of the back button leads to a change of the current page or form

and

the user then clicks on something e.g. a button or link, on the page they have returned to

So the back button event is not triggered just by the user using the browser back or forward button, it is triggered when the user does this and then clicks on something on the new page.

System variables

A number of system variables are provided to help with back button processing.

$BACK_BUTTON_USED	Contains either ‘Y’ or ‘N’ to indicate whether or not the user has clicked the back button. This variable is read only. This information is also available for API based languages using method Client.isBackButtonUsed().
$BACK_BUTTON_FROM_PAGE	The name of the current page prior to the user clicking the back button. This variable is read only.
$BACK_BUTTON_TO_PAGE	The name of the back button target page i.e. the new page. This variable is read only.
$BACK_BUTTON_FROM_FORM	The name of the current form prior to the user clicking the back button. This is only provided when the back button is used to return from a called form to an earlier form. This variable is read only.
$BACK_BUTTON_SUPPORTED	Contains either ‘Y’ or ‘N’ to indicate whether the back button is currently supported. This variable can also be set to dynamically enable or disable use of the back button. This information is also available for API based languages using method WebForm.isBackButtonSupported().

Variables $BACK_BUTTON_FROM_PAGE, $BACK_BUTTON_TO_PAGE and $BACK_BUTTON_FROM_FORM only contain the information described above when processing the back button event. Variable $BACK_BUTTON_USED only contains value ‘Y’ when executing the back button event.

URLs

A URL is generated by Verj.io when the first page of a form is requested, and is inserted into the address bar of the user’s browser. It will contain the id of the current form as well as all fields in the form that have been designated as URL Parameters and have a non-null value. Additionally, the URL may contain a variety of other parameters that Verj.io uses internally to keep track of the user’s session and their place within a form.

This URL generation takes place after the first page has readied itself for output, meaning that changes made to the URL parameter fields before then will be reflected in the URL. Once the URL has been generated, the values of each field will not change for the duration of the user’s interaction with that specific form instance regardless of whether the field’s values are subsequently changed. It is important to note that this applies to a specific instance of the form as it means the Call Form functionality (see the Javascript API for more information) can be used to call the form with the same id (i.e. the same form), thereby creating a new instance of the form which will go through the URL generation.

In practice this means that for the first page of a form:

· If the request URL contains values for URL parameter fields, the form will initialize them to those values and they will be reflected in the generated URL.

· If a URL parameter field is not in the request URL it will be set to its default value and once again this will be reflected in the generated URL.

· If a script (triggered from the Before Form Event or the page’s Before Page Event for example) changes the value of a URL parameter field then the generated URL will reflect the new value rather than the initialized or default one.

The figures below show examples of this:

In Figure 1, Verj.io receives a GET request from a user’s browser specifying the id of the Form to open (Form1) and that Field1 (a URL Parameter) should be initialized to One. Page 1 is a simple page and shows the current value of Field1. A URL is generated using the values of its URL parameter fields and inserted into the user’s browser’s address bar. Next the user clicks a Next Page Button and navigates to the Page 2 where we show Field1 and its value. Notice that the URL in the address bar still contains the same URL parameter.

In Figure 2, Verj.io receives the same GET request and so opens the Form Form1 and initializes Field1 to One. This time we have a Before Form Event which updates the value of Field1 to Two. Page 1 shows this changed value as does the URL inserted into the address bar. Now when the user clicks the Next Page Button a configured On Click Event is executed and changes the value of Field1 to Three. This new value is displayed on Page 2 but as the URL is only generated for the first page it still has the parameter Field1 set to Two.

In the above examples the form is requested via a URL from the user’s browser (from a bookmark for example) but the same is true when navigating from one Verj.io form to another (including a form with the same id) using the Call Form functionality.

Tip: If you want to update the URL for each separate page then one way of achieving this would be to create a separate form for each page as and then use the Call Form functionality to navigate between them.

These URLs can be bookmarked or emailed to someone and Verj.io will open the first page of the specified form and initialize the corresponding URL parameter fields. These initialized fields can be used to ensure the page displays appropriate information. For example, if you have a Product Information page as the first page of a form you can create a URL parameter field to represent the id of the product knowing that when the URL is bookmarked and subsequently used it will contain this id, so giving you the opportunity to load the details of the product from a database before displaying the page to the user.

The URL is generated in the same way on forms where the back button is enabled and disabled but with one difference (aside from a slight change in the parameters Verj.io uses internally): when using the Call Form functionality to navigate between two forms both of which have the back button disabled, the URL is not changed – it is the same as before the Call Form functionality is used. This is in order to preserve the back button functionality (when it’s been disabled it can’t change, otherwise the user will be able to travel back to the previous page/form via the browser’s back button – see above for more information). In these cases adding the URL as a bookmark will result in the first page of the previous form being opened.

Cookies

This section provides documentation on the use of cookies by the Verj.io system. The system can operate when support for cookies is disabled in client browsers, but with some restrictions. The system checks whether a browser client supports cookies when a new session is detected. Therefore, if the support for cookies is changed using browser options, it is necessary to close all browser windows and reconnect to the Verj.io system.

Within the European Union, legislation exists to control the use of cookies. To meet the EU legislation, cookies should not be stored on client systems unless the user has agreed to this, though there are exceptions where this does not apply – most notably if the cookie is “strictly necessary” to the operation of the application. To meet the requirements of this legislation it is generally sufficient to place a link on your site’s landing page explaining your organization’s cookie policy.

Details of the cookies used by the Verj.io system and how these are impacted by this legislation are given below.

Application server sessions

Application servers e.g. Tomcat use a JSESSIONID cookie to maintain the session between the browser and the server. When cookies are disabled, the JSESSIONID parameter is added to the URL.

This information is sensitive and could be used by a potential hacker to steal a user’s session. This cookie is exempt from the EU cookie legislation as its purpose is solely to provide communication between the browser and the server. It is a session cookie and exists only when there is an active session between the browser and the server – it is not saved permanently on the client system.

To test whether the browser supports cookies

When a new session is created, Verj.io creates a temporary session cookie solely to determine whether this is supported by the browser. This cookie does not contain sensitive information that could be of interest to a potential hacker and can be considered as exempt from the EU cookie legislation as its purpose is solely to provide communication between the browser and the server.

Save/Restore feature

Use of this feature requires cookies. If support for cookies has been disabled in the client browser, this feature is disabled. (See save/restore feature for more details). The save/restore cookies are persistent and are stored on the client system.

This cookie contains information that might allow a hacker to access a saved form. It is not clear whether this cookie might be considered as “strictly necessary” within the scope of the EU cookie legislation. Therefore if the save/restore feature is used, it is recommended that the user be notified that this will result in a cookie being stored on their system. See the save/restore feature for further information and examples.

Cookies added by scripts

Cookies can be created and read using the FPL getcookie and setcookie functions, or via methods on the API Client object. This provides the opportunity for customer developed applications to use cookies. These facilities are not used by the Verj.io system itself.

Javascript

This section provides documentation on the use of Javascript by the Verj.io system. When support for Javascript is enabled in client browsers, Javascript is used extensively to control client aspects of page display and to validate user input. However, the system can also operate when client Javascript is disabled, but with some small behavioral changes. Javascript can be disabled in one of two ways:

Automatically, when the system detects that the client browser does not have JavaScript enabled
Explicitly by setting system variable $PRESENTATION_USE_JAVASCRIPT to value 'N'

For more information on the system’s use of Javascript and behavior when Javascript support is disabled, see Web Accessibility – Javascript.

Repeated user clicking

This section of the documentation discusses system behaviour when the user clicks on a button, hyperlink or some other control when a previous request is still active i.e. the response for the previous request has not yet been received by the browser. This situation can occur in a number of circumstances: the user might just click a button many times, or he or she might get tired of waiting for a server response and re-click the same button, click on another button, click the browser’s STOP key, use the back button etc.

All commonly used browsers behave in the same way when this occurs. Repeatedly clicking on a single control will usually result in at least some of the subsequent requests being sent to the server. Clicking the browser STOP key has little impact and does not notify the server that the user wants to terminate the request. Clicking the back button, then clicking a control from a previous page is treated the same as clicking a control on the original page – the request will be sent to the server.

When a browser sends a second or subsequent request to a server, it effectively ignores the original request: any response sent by the server to the original request will be ignored by the browser and will not be displayed to the user. A browser will always display the response to the most recent request sent to a server. This behavior is entirely consistent with the principles of internet browsing – that the user is free to navigate to any URL and that any new request supersedes earlier requests.

However, while this approach is well suited to internet browsing, it is not really appropriate for interactive applications where a tighter binding between client and server is required. Therefore, the Verj.io behavior when repeated clicking is detected is slightly different and is based on the principle that the user must always see the response to any processing actually performed by the server. The Verj.io system operates as follows when repeat requests are received:

The first request in a sequence of requests is processed (i.e. input is received, events executed etc)
Any second or subsequent requests are ignored and are not processed
The response to the first request is returned to the user in response to the final request of a sequence. In this way, the user always sees the response for processing executed.

This is best illustrated by an example. In this example, the user is running an application to transfer money between two accounts. The system presents a radio button for the user to select the amount to transfer, and transfer and cancel buttons. This is obviously not a real world example but serves to illustrate the point.

repeat_post1

The user clicks the £10,000 radio button and then the transfer button. The system takes a while to respond, so the user then clicks the cancel button. In this circumstance, the Verj.io system will process the transfer request (the first request) and ignore the cancel request, and the response displayed to the user will be the response from the processing of the transfer request. Obviously, there are other possible scenarios here: the user could start a transfer for £10,000 then change the amount to £100 and re-click the transfer button. In all cases, processing is the same: only the first request of a sequence is processed, and the response to the first request is displayed to the user.

Popup Blocking

The popup windows displayed as a result of the FPL commands: PRINT, PDFPRINT, OUTPUTPAGE and DISPLAY (or API methods PrintResource.print(), WebForm.generatePdf(), WebForm.displayUrl()) are treated as candidates for blocking by most browsers. There are a number of different approaches that can be taken to this issue:

Let the user respond to the messages issued by the browser. The problem with this approach is that the user may not be sufficiently knowledgeable about the operation of their browser.
Globally suppress all popups. This option is configured with server property Do Not Popup New Windows. When this option is enabled, popup windows are not “popped-up”, instead they are displayed as inline browser pages. This solves the pop-up blocking issue, but the end user experience is not the same: the popup window cannot be displayed at the same time as the original window, and the user must click the browser back button to return to the application. When global suppression of popups is enabled, system variable $PRESENTATION_USE_POPUPS contains value ‘N’.
Add a textual message to the page at the point where the popup is to be displayed e.g. “Clicking the print button will result in a popup window containing the print document. Please ensure popups are not blocked on your browser”.

Focus

See controlling browser focus.

Scrolling and Screen Stability

See browser scrolling.

Multiple Browser Windows

Verj.io provides support for multiple windows within each browser client. This means that each user can run multiple forms concurrently. This support is basic functionality and does not have to be enabled in any way. See Support for multiple windows for detailed information.

Browser Language Options

Verj.io can be configured to use the preferred languages configured in a client browser. When this support is activated, the system attempts to supply each language dependent item (texts, messages and static lists) in the chosen language. See Internationalization support for complete details.

Timeouts

The Verj.io web application is supplied with a default timeout period of 30 minutes i.e. if the user is inactive for 30 minutes, the session is removed by the application server. This timeout period is configured using the Server Admin App.

The timeout can be changed dynamically for the current session using Javascript like this:

client.httpSession.maxInactiveInterval = 3600; // seconds

A negative number indicates that the session should not time out, but treat this with caution as a negative number also means that session state memory is never freed.

When a timeout occurs, all memory related to the session is freed by the application server. If the user subsequently clicks on something to continue working, a timeout message as shown below is displayed.

“The application has timed out. Press the browser's refresh key to start again.”

If the user activates the browser refresh key at this point as suggested, the form will restart from the beginning. All data entered previously is lost. This message is contained in file ufs_timeout_page.htm and can be configured. See customization of error pages for more information.

Accessibility

Verj.io enables the creation of forms and web applications that meet the Web Content Accessibility Guidelines (WCAG) 1.0 produced by the World Wide Web Consortium, W3C under the Web Accessibility Initiative (WAI). See Web Accessibility for details.

Customization of Error Pages

See customization of error pages.

Checking browser information programatically

For API based languages, many methods and properties on the Client object provide information about the browser e.g.

client.IE; // is the browser IE

client.fireFox; // is the browser Firefox

client.chrome; // is the browser Chrome

etc.

client.secure; // is the request using HTTPS

client.mobile; // is the browser a mobile device

client.userAgent; // returns the browser’s user agent string from the HTTP header

client.supportsCookies();

client.supportsJavascript();

The Client object can also be used to directly access the servlet request, response and session objects. These give access to all available information about the browser client, the current request and the session e.g. request parameters, request header parameters, cookies, session attributes etc.

A number of system variables are also available to all programming languages which provide information about the client browser at runtime:

$BROWSER_TYPE

This contains the user-agent string from the HTTP header. Typical values are:

Internet Explorer	Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)
Firefox	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8) Gecko/20051111 Firefox/1.5
Opera	Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.0) Opera 7.54 [en]

$BROWSER_SUPPORTS_COOKIES

Contains ‘Y’ or ‘N’ to indicate whether or not the browser supports cookies.

$BROWSER_SUPPORTS_JAVASCRIPT

Contains ‘Y’ or ‘N’ to indicate whether or not the browser supports Javascript. Note that a value of ‘Y’ does not necessarily indicate that Javascript is being used as this could have been suppressed globally within Verj.io. To check if Javascript is being used, use system variable $PRESENTATION_USE_JAVASCRIPT.

$BROWSER_SUPPORTS_STYLESHEETS

Contains ‘Y’ or ‘N’ to indicate whether or not the browser supports stylesheets.

$PRESENTATION_USE_JAVASCRIPT

Contains ‘Y’ or ‘N’ to indicate whether or not Javascript is currently being used.

$PRESENTATION_USE_POPUPS

Contains ‘Y’ or ‘N’ to indicate whether or not popup windows should be displayed as popups or inline. See popup blocking.