Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget
Author: firstname.lastname@example.org (Adrian Gosbell)
The HTML widget delivered in Uniface 9.6 is based on sources from Google, using their Chromium technologies. With Uniface 9.7.02, we have changed the version from what is knows as CEF1 to CEF3 which gives us some new capabilities (64-bit being one), and fixes a number of reported bugs.
Getting CEF3 implemented has been a challenging project due to things like APIs changing, differences in threading models and so forth, but we are now code complete and will be delivering Uniface 9.7.02 next month (June 2016).
During testing we identified a change of behaviour where Uniface would crash when an application using the HTML widget was repeatedly closed and opened.
Although it is Uniface that is crashing, the cause is inside the Chromium libraries rather than in Uniface. The Chromium community has acknowledged it as an issue, and it is on their backlog. Unfortunately we don’t have influence on if and when it will be fixed.
Rather than wait of this to be resolved and delay Uniface 9.7.02, we have made some changes in the behaviour of Uniface when closing down, where the exit will be delayed in the event that the HTML widget is still active. This change should delay the exit until the Chromium activities complete.
This workaround has resolved the crashing scenario, and all our tests pass. We also use the same technology extensively in Uniface 10 without any issues from testing and use. From a quality perspective this means it reaches our quality criteria and it will be released.
We believe its unlikely that the crash will surface in customer applications, but if it does, we will analyse them as part of the usual support processes. Obviously we will need test cases to reproduce and analyse the scenario.
It is possible that if customer apps are using the HTML widget in their apps, and the control still actively processing while the end user tries to close the app, the close will not happen until the control has finished.
We have good testing coverage of the HTML widget, and the only scenario we could originally reproduce the issue was the repeated closing and opening of an app, which we hope is not really what happens in the real world.