Ebase provides explicit support for the browser back button. The designer 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 back button to navigate to a previously displayed page and then continue execution from that point. Before activating this feature, 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 form button to display PAGE10. From the perspective of the executing form, it has just displayed PAGE4 then receives input from PAGE1 and executes the event for the clicked button on PAGE1. 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.

When back button support is disabled, the end user is automatically returned to the current page when the browser back button is clicked; from the perspective of the end user, the back button appears not to work. The system achieves this by adding Javascript to each page to intercept the back button. If the form is executing with Javascript disabled, the back button will appear to work and the end user can display a previous page; however, when a post is made from that page e.g. a button or hyperlink is clicked, the user is automatically returned to the current page.

How specified

The system default for browser back button support is specified in parameter Ufs.browserBackButtonSupport in UFSSetup.properties which can have a value of true or false. If this parameter is not specified, the default is false i.e. back button support is disabled.

The system default can be overridden at form level using options under the heading Browser Back Button Support in the General tab of form properties as shown below.

When the back button is used to return from a called form to a calling form, both forms must support use of the back button as described above. If this is not the case, the request is treated as if back button support is disabled.

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

How the back button works

This section is provided for information only.

All browsers maintain a history of displayed pages. When the back button is used to display an earlier Ebase page, the page is displayed from the browser’s history cache without the need to contact the server. Therefore, the server (and the executing form) are unaware of what the user is doing until he or she performs some action that results in a post to the server from the new page; usually this means clicking on a button or a hyperlink or some other control. It is important to understand that the server does not receive control each time the user clicks the back button.

As the user clicks the back button, the browser’s forward button is also enabled, thus allowing the user to page backwards or forwards through the history as desired. However, if the user clicks the back button to a previous page and then clicks a button or hyperlink on that page that results in a post to the server, the browser then removes all history pages from the cache beyond that point. For example, the user navigates through a sequence of pages:

PAGE1, PAGE2, PAGE3, PAGE4

When the user is viewing PAGE4, the previous pages are all available in the history cache. i.e. the history will contain

=> PAGE1, PAGE2, PAGE3

The user then clicks the back button three times to return to PAGE1 and clicks a button on that page that results in the display of PAGE10. At this point, the browser’s history cache will contain

=> PAGE1

And the browser’s forward button will be disabled. Pages PAGE2 and PAGE3 have been removed from the cache and cannot be accessed using the browser back or forward buttons.

Supported scenarios

In the following discussion, the term current page refers to the page displayed before the back button is used, and the term target page refers to the page returned to using the back button. Please note that a back button request is only recognized by the system when the user clicks the browser back button and then causes a post from the new page e.g. clicks a button or hyperlink. Just clicking the browser back and forward buttons to scroll through previous pages does not trigger a back button request.

In general terms, Ebase can only process a back button request when the target page is part of a form that is still available to the server. There are three supported scenarios:

The current page and the target page are different pages in the same form.
The current page and the target page are the same page in the same form. This scenario arises when the same Ebase form page is displayed to the user many times. The browser treats each display as a separate page and adds each one to its history cache.
The current page and the target page are in different forms. This is only supported where the target page’s form is in the current call stack i.e. CALL FORM has been used. This is illustrated in the following examples:

Example 1:

FORM1 calls..

FORM2 calls..

FORM3 calls..

FORM4

The user can use the back button to return from FORM4 to any displayed page in FORM1, FORM2 or FORM3. (Note that back button support must be enabled for both the current page’s form and the target page’s form.)

Example 2:

FORM1 calls..

FORM2 calls..

FORM3 returns..

FORM2 calls..

FORM4

The user can use the back button to return from FORM4 to any displayed page in FORM1 or FORM2, but cannot return to any page in FORM3 as FORM3 has been removed from the call stack.

Please note that when the back button is used to return to an earlier form, any forms that were subsequently called from that form are removed from the server’s memory. To clarify, in Example 1 above, if the back button is used to return from FORM4 to FORM2, then FORM3 and FORM4 are both removed from memory.

Before the back button request from FORM4 to FORM2:

FORM1 calls..

FORM2 calls..

FORM3 calls..

FORM4

After the back button request:

FORM1 calls..

FORM2

This processing mirrors browser behaviour when the back button is used as described in section How the back button works.

The back button can also be used to return to a non-Ebase page e.g. a page prior to the first call to Ebase.

Restrictions

There are a number of 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. Using the back button to return to one of the form’s pages will result in the timeout message being displayed.
A GOTO FORM command has been issued. The user is returned to the last page displayed of the current form i.e. the system acts as if back button support was disabled.
A GOTO URL command has been issued. Using the back button to return to one of the form’s pages will result in the timeout message being displayed.
A RETURNFROM FORM command has been issued. The user is returned to the last page displayed of the current form i.e. the system acts as if back button support was disabled.

Back button event

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

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.
$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. 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. See notes under Practical Considerations on limitations.

Variables $BACK_BUTTON_USED, $BACK_BUTTON_FROM_PAGE, $BACK_BUTTON_TO_PAGE and $BACK_BUTTON_FROM_FORM only contain the information described above when processing the first post after the back button has been used. They always contain valid information when the back button event is executed.

Practical Considerations

When the back button is used, there may be an inconsistency between the data displayed to the user and the data contained in the server’s memory. For example, field CREDIT_CARD_NO might be displayed on the PAYMENT page of a form. In subsequent pages, this is changed by the user to a new value, but when the user returns to the PAYMENT page again using the back button, the original value is displayed even though the server holds the new value. The amount of inconsistency will depend on the application design, on the point returned from and the point returned to. The back button event provides the opportunity to programmatically resolve any such inconsistencies and to ensure that the back button operates as expected.

The back button can be dynamically enabled or disabled by setting the $BACK_BUTTON_SUPPORTED system variable e.g.

set $BACK_BUTTON_SUPPORTED = 'N';

The effect of this command is to stop the user from using the back button to return to the next page displayed or any subsequent page. However, it does not prevent the user from returning to a page displayed before this command was issued although this is difficult and can only be achieved by repeated rapid clicking on the back button. Because this command does not provide a total guarantee that the back button cannot be used, the technique described in the next paragraph can also be used.

Whereas the command shown above stops the user from using the back button, there may also be a requirement that the back button is not used to return to certain pages in a form or past a certain point in processing. This could be implemented in a back button event by checking the target page e.g.

if [ $BACK_BUTTON_TO_PAGE = 'PAYMENT' || BACK_BUTTON_DISABLED = 'Y' ]

// not allowed, return the user to the page they’ve just come from

goto page $BACK_BUTTON_FROM_PAGE;

endif

(where BACK_BUTTON_DISABLED is a field used to programatically control whether use of the back button is allowed)

In this scenario, the back button will appear to have worked to the user, but when a button or hyperlink was clicked in the earlier page, they are then returned to the original page i.e. the page displayed before the back button was used.

Back button and tables

A potential problem exists where the browser back button is used to return to a page that contains dynamic table data i.e. the page contains a table and the contents of the table change based on user behaviour or selections. This problem arises because there can be an inconsistency between table data displayed to the user and table data contained in the server’s memory.

This problem is best illustrated by an example: consider a form that allows users to search a problem log database. The search page contains a search field with a table of results underneath; each row in the results table contains a “Details” button that then displays the details of the selected problem log on a separate page. Consider the following scenario:

The user performs a search with keyword “Windows” and the system displays a table with 6 results (log numbers 3, 5, 8, 25, 51 and 60).
The user then performs a second search with keyword “Linux” and the system now displays a table with just 2 results (logs 9 and 57).
The user then uses the back button to return to the first page. At this point the user is looking at the results of the first search and clicks the “Details” button to display log 5, which is the second row in the table.
However, the system displays the details for log 57 as this is the second row of the table in the server’s memory.

This problem can also be manifested in other ways e.g. the user might click a button in a table row that no longer exists. When a form is being run from the designer, a message beginning “Table data inconsistency during back button processing:” is written to the execution log, but no such message is written when the form is run in production.

It may be difficult to achieve a totally seamless operation of the browser back button in this situation. However it is recommended that the back button event is used to reload the same table data that is displayed to the user; if this is done, there is no inconsistency between data viewed by the user and data held in the server’s memory. In some circumstances, it may be necessary to have a hidden field that is written as part of the HTML for each page e.g. this might contain information used to reload a table. This can be achieved using the user variables $USERVAR1, $USERVAR2, $USERVAR3.

Cookies

This section provides documentation on the use of cookies by the Ebase 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 Ebase system.

Cookie support is required for the following:

Execution of a form when back button support is disabled

When back button support is disabled, Ebase uses cookies to control the sequencing of displayed pages. If support for cookies has been disabled in the client browser, an error message is issued and form execution stops. The message text is taken from system text 422 and can be customized by adjusting this text. (System texts are maintained in the Ebase Designer Tools --> System Texts).

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).

getcookie/setcookie FPL functions

These FPL functions provide the opportunity for customer developed applications to use cookies. These functions are not used by the Ebase system itself.

Javascript

This section provides documentation on the use of Javascript by the Ebase 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 behavioural changes. Javascript can be disabled in one of three ways:

Automatically, when the system detects that the client browser does not have JavaScript enabled
Explicitly, when the 'do not use JavaScript' option has been set in the global accessibility dialog.
Explicitly by executing FPL command set $PRESENTATION_USE_JAVASCRIPT = 'N'

For more information on the system’s use of Javascript and behaviour 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 behaviour is entirely consistent with the principles of internet browsing – that the user is free to navigate to any URL and that any new request supercedes 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 Ebase behaviour 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 Ebase 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.

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 Ebase 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, Ebase 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 and DISPLAY 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 is an Ebase option available from the accessibility dialog (Tools --> System Preferences --> Accessibility). 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”.

Multiple Browser Windows

Ebase provides support for multiple windows within each browser client. This means that each user can run multiple Ebase 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

Ebase 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 Ebase 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 in the <session-config> element of the web.xml file which is located in the WEB-INF directory of the Ebase web application (For Tomcat systems, this can be found in UfsServer/tomcat/webapps/ufs).

<session-config>

<session-timeout>30</session-timeout>

</session-config>

If this is changed, the web application should be restarted.

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 siggested, 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

Ebase 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 Ebase Web Accessibility for details.

Customization of Error Pages

See customization of error pages.

Checking browser information programatically

A number of system variables are available to 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 Ebase. 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_STYLESHEETS

Contains ‘Y’ or ‘N’ to indicate whether or not stylesheets are 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.