HTMLViewer - long time to get TitleChanged event

I’ve been doing some timings of how long it takes between issuing:

myHTMLViewer.ExecuteJavaScript ("getTitle();")

and getting the subsequent TitleChanged event. The javascript function getTitle() is very short:

function gettitle () { titleCount++; document.title = "myEventMarker:GetTitle:" + titleCount + ":" + titlestuff; }

where titlestuff is a 100 byte string (the prefixed stuff is to distinguish between wanted/unwanted events and the various wanted ones).

Now, under macOS, the time in question is a couple of milliseconds at worst. However, under Win7 in a virtual machine (VirtualBox under macOS), using the IE11 renderer, this time consistently shoots up to 110 msec, there or thereabouts. Similar code has been tried by someone with a real Win10 machine, he reports similar timings.

I’m now working on porting an app to Windows. Historically I’ve used the StatusChanged event to pass data from an HTMLViewer back to Xojo, but this may cease working at any time. The problem with using the TitleChanged event is the data length limitation of some 200 bytes (under the IE11 renderer). If I have a few k of text to recover from the HTMLViewer, that could take some seconds which will not work well with the rest of the app.

Is there a reason for this long lag with the HTMLViewer/TitleChanged under Windows? Any way I can mitigate it or use an alternative strategy?

Just submitted <https://xojo.com/issue/53769> about this.

Tim, are you testing in 32 or 64 bit builds?

I’m running into something which may or may not be related: on Window builds, it seems that I’m losing titleChanged events - my Javascript can set the title several different times, but it seems like only some of the changes are triggering the titleChanged event inside Xojo. On mac builds I have no problem.

Errr, looks like 64 bit. Seems like Xojo are still thinking about the slowness of these under Windows.

Meanwhile I took up a suggestion of (sp?), who mentioned websockets. So now I have incorporated a websocket server in my app and will in general terms avoid statusChanged or titleChanged when communicating to/from an HTMLViewer.

I’ve been testing another way in which you set window.location via javascript, which then triggers the CancelLoad event in the HTMLViewer - this seems to be working better for me (x64 Windows build, HTMLViewer native).

Tim, have you tried that method out for speed?

[quote=420236:@Michael Diehr]I’ve been testing another way in which you set window.location via javascript, which then triggers the CancelLoad event in the HTMLViewer - this seems to be working better for me (x64 Windows build, HTMLViewer native).

Tim, have you tried that method out for speed?[/quote]
Errr, sorry, which one? websocket or window.location?