launchInDefaultBrowser() causes a message loop to be triggered

I’ve got some code that roughly boils down to this.

startTimer(100);

void timerCallback()
{
  if (! launched)
    url.launchInDefaultBrowser();

  launched = true;
}

It causes infinite recursion and an infinite number of browser tabs to open! Which was unexpected (by me).

Is there some way of preventing this behaviour accross the app or do we need to design all timerCallbacks to be reentrant…?

Sample of the stack trace:

how about this?

startTimer(100);

void timerCallback()
{
  if (! launched)
  {
    launched = true;
    url.launchInDefaultBrowser();
  }
}

Or did I misunderstand?

That’s what I’ve done. But what i’d really like is something that stopped it happening in the first place … reentrancy guarantees on timerCallback maybe (or luanchInDefaultBrowser())? Not sure!

To be honest, I am puzzled how it could happen in the first place.
timerCallback() is happening from the message thread.

I can see launchInDefaultBrowser() blocking a while, but how could the next message (another timerCallback()) happen in the meantime?
That would mean launchInDefaultBrowser() spawned a new thread?
But then it would have returned already, before giving way to the message queue?

Well apparently windows decided to send another message back to wndproc or whatever before returning from openDocument. The timer then fired and off we went for another loop!

Can you perhaps avoid all of these considerations by using the Timer::callAfterDelay() static method for launching the browser?