Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Browser back button

Intercepting of the browser back button only works sporadically in IW 15.2.53, mostly not at all.

I used the following settings for the server controller, which have always worked so far:

BackButtonOptions->Mode   = bmInterceptForm;
BackButtonOptions->ShowMessage    = true;
BackButtonOptions->WarningMessage = L"Please use the back button of the application";
BackButtonOptions->ReloadPage    = false;

On Windows, intercepting the browser back button works correctly.
It only works sporadically (Firefox) or not at all (Chrome, Samsung) on Android devices.
Attached is an example.

Attached Files
.zip (Size: 13.03 KB / Downloads: 2)

I'll have a look and see what can be done.

However, (and I've been saying this for several years every time a request around this area comes to me) the "back button" workaround is not 100% reliable (has never been) and your application shouldn't be designed to rely on it to work flawlessly, because this is a cat-and-mouse game... Every time someone finds out an effective way to prevent the browser to go back, the browser developers change it to break the workaround... And it has been like that for more than a decade now.

I'll keep you informed.

I changed the implementation (quite drastically to be honest) and it seems to be working much better now.

However, there is (and I think there will always be) an issue with Chrome (and other webkit based browsers): It doesn't work (i.e. no event is triggered, so nothing we can do) unless the user interacts first with the page (the user needs at least to click on the page once, focusing the document). That's how Chrome behaves since a few years ago and I don't think this can be changed.

This new implementation will be available in the next release.
Hi Alexandre,

Thank you for finding a solution so quickly.

The main problem is that the browser's back button does not close a displayed form and removes it from memory, but only hides it from the user.
However, the application usually loses access to the form and the next time the application calls it, a new form is created if the new() call does not fail completely.
With extensive user navigation, the application also takes up an unnecessarily large amount of memory.

In addition, it is therefore certainly useful to check before creating a new form whether an initialized form already exists that can be used.

I have adjusted the test example accordingly.


Attached Files
.zip (Size: 13.14 KB / Downloads: 1)
I suggest that you refactor your application and change your form creation code... something like this:

WebApplication->ShowForm(TIWForm1, false, true); // in c++

TIWApplication.ShowForm() method has 3 parameters (the last 2 are optional)

First parameter is the Class of the form
Second parameter (AReleaseActiveForm: boolean), when true, the "old" form will be released when the "new" form becomes active. Default is false
Third parameter (AUseExistingInstance: boolean), when true, any existing instance of the same class of the desired form will be used. Default is false.

When you call it like

WebApplication->ShowForm(TIWForm1, false, true);

IW will create a new TIWForm1 instance and make it active (not releasing the old one) but if there is already an instance created, it will be used instead. This code guarantees that no 2 instances of any form class will ever exist (as long as you use this same method everywhere, instead of creating the forms via traditional code)

It will handle nicely all these cases that you are referring to

Handling the navigation between forms, including the back button events, is sometimes hard to get right. I'll check your updated example and propose a few modifications to handle it better, if that's the case.

Kind regards
I completely overlooked the function, there is definitely less to write about Wink

Attached Files
.zip (Size: 13.07 KB / Downloads: 2)

Forum Jump:

Users browsing this thread: 1 Guest(s)