2018r3 Web app appears stuck when it quits

Just recently upgraded from 2017r3 to 2018r3 and notice that when Web apps quit, they no longer display the

message. They just get stuck. I think someone else reported this somewhere in this forum, but I can’t find it. This looks terrible. It looks to the user like the Web app crashed. Is there a 2018r3 workaround for this?

I now see it here: <https://xojo.com/issue/53291>

I may have to go back to 2017r3 for now. This make my Web app look broken.

We had this issue with 2018r2 but 2018r3 seems to have fixed it as you can see for yourself here: https://service.docblaster.com/#DJSMJ6ZZZ8INGRKSQBTA5fI69h6FDDqkl

Previous to 2018r3 we wrote our code in 2018r2 or less and compiled in a 2017 version to avoid the bug, however now there is no need.

This behavior is still present for me with 2018r3, so will have to revert to 2017r3.

In that case you may be better off sticking with 2018r3 for development and do your final compile in 2017rX since the IDE for debugging and iterative development purposes has much improved since then.

I guess I’ll just have to see what new features have been added since 2017r3 and be careful not to use any of them when developing with 2018r3, and then do the final compile with 2017r3. Will the 2017r3 compile process alert me when it comes to such a feature (that it doesn’t support), or will it just skip it? Just in case I accidentally use one of them when developing with 2018r3.

Yes. You’ll get a compile error.

That’s what I was hoping. Thanks for the quick reply.

You must also be careful with plugins, 64 bits, sqlite version, etc.

it would still be better if the Xojo team could fix this bug that has been impacting all web applications for months.

Even if you simply update the application or server, or restart the server, or put the client side computer to sleep and restart it, etc., the client side web app will seem stucked.

Customers who use a laptop computer (the majority of users in our time) often put their computer on standby to save energy or for confidentiality: either automatically or by closing the screen, etc. And as soon as the computer is out of sleep, they are used to working immediately. But with a Xojo web app, it doesn’t work anymore, the application is stucked, they don’t know how to react.

it’s a bug that gives a bad image of the product, because customers see it every day. it is now becoming urgent to fix this bug.

I understand that there were too many priorities for the release of the R3 version, but now that the R3 is out, this bug should be a priority. We can’t wait for the web 2 framework, it would mean months more waiting for our customers, not to mention the time to analyze this new framework, the time to adapt the code, and the circumvention of the inevitable bugs of a brand new version.

please, consider putting your points on the feedback:
<https://xojo.com/issue/53291>

Translated with DeepL Translate: The world's most accurate translator

I have reverted to using 2017r3 for development because of this bug.

I wrote a really long article explaining the changes between 2017 and 2018 and the small issue that is causing this behavior. I wrote it on my blog: http://www.dev.1701software.com/blog/2018/11/19/freezing-xojo-web-apps

It is a meaty 3 minute read and somewhat technical but interesting. However, for future visitors who encounter this as we don’t know when a resolution will be provided here is the fix:

  1. Add an event handler for the ‘Shown’ event for the first WebPage in your Xojo Web project if it does not already exist.

  2. Add the following code:

me.ExecuteJavaScript("if (Xojo.eventsource !== undefined){Xojo.eventsource.onerror = function (event) {Xojo.eventsource.msgcount--;if (Xojo.eventsource.msgcount < 1 || Xojo.eventsource.readyState === 2) {Xojo.view.preventInteraction();}};};")
  1. That’s it! You can now deploy your app and verify the fix works on ALL devices.

I think I’ve noticed this too - I have a Xojo standalone webapp running on macOS which implements an online survey. I’ve had 100s of users use it successfully, but occasionally it just gets “stuck”. Hoping Xojo can implement this fix.

Thank you very much Philip! A very nice job of analysis and execution, as usual! I hadn’t seen this change for SSE, I’m going to see all this and read your blog more carefully. :slight_smile:

Thank you. I felt it was important to explain WHY the failure occurred. You should not go tweaking your Xojo framework without caution. :slight_smile:

This was marked as fixed as of this morning in <https://xojo.com/issue/53291>.

Thanks @Greg O’Lone for the fix!

I find that Xojo 2018r4 fixed this.