Webtimer not firing sometimes

Is there any reason a webtimer should not get to its action event?

The timer is on a containercontrol, and it is used to have the container refresh reliably. When the timer’s action event occurs, it calls a method to show an error message. Sometimes the action event never happens. I can tell when things are/are not happening because I have a bunch of logging statements in the code.

(Note: Of course, it always works when I run it either locally or on our test site.)

-Bob (who is thoroughly confused)

WebTimers are JavaScript timers which fire on the browser itself. Timing can be affected by a number of things, including browsers which throttle events to try to save CPU cycles.


So, if I need to update some information on the page (say receiving an error message from a service), I thought using a timer was the right thing to do because the page would update at the end of the event (the timer’s action event). If that’s no reliable, is there something else I can do? (BTW, I set the timer’s mode to multiple on the chance it might not fire reliably but that it might fire sooner or later. I turn it off in the action event.)


Brief update:

One of our testers had things work successfully twenty times.

The director had it fail. In fact, at the moment he’s the only one not getting the correct behavior. Could there be some browser setting?

-Bob (who is still confused)

We’d need to know more about the OSs and Browsers each person is using.


OS and version info coming.

Other news: The person for whom it’s not working tried it on an iPad and a MacBook Air. Worked fine. So now we have it failing on just his iMac.

Also: The app was developed in Xojo 16.2.1. I just moved it to 17.1. Any chance this might make a difference?


What does the timer do exactly ? It refreshes a container control ? In which way ? How often ?

Just looked through the release notes and I don’t see any glaring reason why this might have changed.


As I understand it, the only way to get something to change on a page is to have some event end. The action event of a timer is suggested.

We’re getting a reply back from a service. Sometimes things are okay, and processing continues. Sometimes there is an error (e.g. user has entered bad data), and we want to show our users an error message so they may correct things.

So, when I receive and error message, I start the timer. In the timer’s action event I present the error message. This works reliably on my computer and on our tester’s computer. It does not work on the director’s iMac, but it does work on is MacBook Air and iPad.

I have numerous logging statements. If the action event fires, it should write to the log. So, I know where things are happening (or not).

If there is another way to get the error message to appear, I will try it.

Thanks for any suggestions you may have.



I don’t remember seeing anything, but I figured it couldn’t hurt. Also, it’s probably a Good Practice to stay reasonably current with Xojo releases.

Info on OS and Browser versions coming.


I have never seen a JavaScript timer lock (that is the underlying WebTimer). But you may try a server side timer, the very one used in Desktop projects. Since it is not part of the page, it will probably be immune to whatever blocks execution of the WebTimer.

  • Drag a generic object to the WebContainer/WebPage
  • Make it’s super “Timer”
  • Add the Action event with the Msgbox inside
  • In the Open event of the WC/WP, set the period :
TimerRefresh.Period = 100

No need to have any shorter period, an average round trip is already over 150 ms.

When you need the timer to fire, do as usually :

Timer.Refresh.Mode = Timer.ModeSingle

Note that inside the Action event, you do not have access to the Session object, as you would in WebTimer. If for some reason you need it, see http://documentation.xojo.com/index.php/WebSessionContext

An update:

I ended up using a MsgBox in case there was an error.

What I had been doing is simply displaying a label with the error message and highlighting the label next to the field with the error. This was not working reliably (timer issues as above).

The MsgBox worked in the environment where the errors had never appeared. This will do for now.