Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget

Author: adrian.gosbell@synapse-i.jp (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.

Page 1 / 1

Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget

Author: adrian.gosbell@synapse-i.jp (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.

gianni said Hi Adrian, It could be a side question...but...I would like to know if HTML5 widget is activated only on screen (component with edit/display instruction) or also when printing (hidden component with print instruction)...and last if the show instruction is anyhow connected to HTML5 widget. Thanks in advance. Gianni

See my answer in the other post: HTML5 widget activation Daniel

Author: diseli (daniel.iseli@uniface.com)

Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget

Author: adrian.gosbell@synapse-i.jp (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.

Hi Adrian, We use HTML widget in tabs, which can be closed and open often. Do you think that this version may have a negative impact on our application ? Can you tell us more about the improvements of this CEF 3.0 version (cookies, cache management) ? Thanks. Gilles.

Author: Gilles (gls.tools@free.fr)

Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget

Author: adrian.gosbell@synapse-i.jp (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.

CEF1 was effectively Chrome version 27. Given that we are now at Chrome version 53 there are many, many differences. See http://caniuse.com/#compare=chrome+27,chrome+53 for details. One area that I was interested in was flex box support, which is much better in the modern code line. I've been meaning to raise a wishlist item to move to CEF3 for some time now, but you've beaten me to it. Good job.

Author: Andy Heydon (andy@heydon.org)

Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget

Author: adrian.gosbell@synapse-i.jp (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.

UserGho said Hi Adrian, We use HTML widget in tabs, which can be closed and open often. Do you think that this version may have a negative impact on our application ? Can you tell us more about the improvements of this CEF 3.0 version (cookies, cache management) ? Thanks. Gilles.

Hi Gilles, the issue I mentioned is specific to the app being closed rather than flipping between multiple tabs. In regards to the functionality, Andy's links below would be a better place to get your info. We've not tested every single CEF/Chromium feature in regards to the Uniface scenarios.

Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)

Possible changes in client server shutdown times in Uniface 9.7.02 when using the HTML5 widget

Author: adrian.gosbell@synapse-i.jp (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.

Hi Adrian, It could be a side question...but...I would like to know if HTML5 widget is activated only on screen (component with edit/display instruction) or also when printing (hidden component with print instruction)...and last if the show instruction is anyhow connected to HTML5 widget. Thanks in advance. Gianni

Author: gianni (gianni.sandigliano@unifacesolutions.com)