Deactivate TabEngine Temporarily and Then Turn It Back On

Targets Web
1

I have an issue (latest version of Xojo and 2024r2.1) where the TabEngine built into the xojo client-side JS Framework gets stuck in an infinite recursion. (edited from “infinite loop”; the issue is the function is getting called recursively again and again, maybe because of a Null reference being passed?)

This happens in every browser I’ve tested so far. (On Mac: Safari, Edge, Firefox; On Windows: Chrome)

I believe this is related to embedding containers, at runtime, into a web dialog. (only place it happens)

If I completely turn off the TabEngine using:

ExecuteJavascript("XojoWeb.TabEngine.currentTabEngine = function(x){};")

The problem is “fixed” but I don’t want to permanently turn off the tab engine.

Instead I either want to:

  • Temporarily turn off the tab engine while the dialog is shown and then restore it, or…

  • Omit the container and any of the controls embedded into it at runtime from using the TabEngine

Any advice on how I can do this?

2

Have you tried putting a textfield off the edge of the container to catch the focus?

3

@Greg_O - I have not. I’ll give that a shot tomorrow AM.

It also occurred to me I could probably replace the embedded-at-runtime container controls with WebSDK controls since I only need to show an image and capture a click?

4

Emphasis is mine.

Just a note to tell you and other posters that “latest version” has a meaning that lasts just for some while. For example at the time I write this post, version 2024R3 is now available.

I wsih you that this issue has been fixed in R3 :smiley:.

5

@Greg_O - Putting an invisible WebTextField control on the first container being embedded into the dialog seems to be a workaround.

For anyone who runs into the same issue:

  • This was an issue specific to embedding WebContainers, at runtime, into a WebDialog.

  • Specifically, the issue was the Xojo JS Framework would get caught in an endless recursion related to the JavaScript “TabEngine” implemented within it. This would use 100% CPU on the client’s computer since it was happening in the browser.

  • To fix this, I placed an Invisible (Visible = False), but Enabled WebTextField “outside the bounds” of the first WebContainer being embedded at runtime as suggested by @Greg_O

image
image2664×1528 154 KB

  • Note: I only had to do this for the first container being embedded. Doing so fixed the issue for both the initially embedded container and any additional containers being embedded inside of it.
    –
    (I tested putting the WebTextField in various different places, e.g. on the dialog itself; on both the initially embedded WebContainer and the other WebContainers which are then embedded into it; only on the subsequently embedded containers but not on the initially embedded container; etc…

Placing a WebTextField on the initially embedded container “caught the focus” and solved the performance issue.

Many thanks to Greg!

@Gilles_Plante

As I wrote, I experienced the issue in latest version of Xojo and 2024r2.1.

In other words, r3 has the same problem. I could’ve been more explicit/clearer, so thanks for the nudge.