[FEATURE]: Make WebView2Bridge message throttling configurable

[Blowcake]

What feature would you like, or what problem are you facing?

Hi ioa747 and mLipok,

First of all, thank you both for your incredible work on NetWebView2Lib! It has been an absolute game-changer for building modern web-based UIs in AutoIt.

I recently upgraded to the newer versions (like v2.2.1-alpha1) and noticed that debug/log messages sent rapidly in a row from JavaScript to AutoIt were being silently lost.

After investigating, I found they get discarded on the C# side in WebView2Bridge.cs due to the hardcoded 20ms throttling limit:

csharp
private const long ThrottlingIntervalTicks = TimeSpan.TicksPerSecond / 50; // max 50 calls/sec
...
if (currentTicks - _lastMessageTicks < ThrottlingIntervalTicks) return;

To prevent this critical message loss, I was forced to implement a 50ms queue delay before each call in my code. However, this workaround now causes a massive slowdown in my application (e.g., sending 100 log/state updates takes a full 5 seconds to process).

Proposed Solution:
Would it be possible to make this throttling interval configurable?

1. Add a property to the manager, such as ThrottlingIntervalMs (defaulting to 20 to keep the safety limit active by default, but allowing developers to set it to 0 to disable it entirely).
2. In WebView2Bridge.cs, only throttle if ThrottlingIntervalMs > 0:

csharp
if (ThrottlingIntervalMs > 0 && (currentTicks - _lastMessageTicks < ThrottlingIntervalTicks)) return;

3. Update the injected JS bridge script so it only queues messages with a delay if throttling is active (or bypasses the queue/setTimeout if disabled).

This would allow me to fully utilize the speed of the WebView2 interop without risking silent message drops or forcing artificial application slowdowns.

Thank you for considering this enhancement!

Best regards and greetings from Germany/NRW
Harald Frank

What's your proposed solution?

Would it be possible to make this throttling interval configurable?

1. Add a property to the manager, such as ThrottlingIntervalMs (defaulting to 20 to keep the safety limit active by default, but allowing developers to set it to 0 to disable it entirely).
2. In WebView2Bridge.cs, only throttle if ThrottlingIntervalMs > 0:

csharp
if (ThrottlingIntervalMs > 0 && (currentTicks - _lastMessageTicks < ThrottlingIntervalTicks)) return;

3. Update the injected JS bridge script so it only queues messages with a delay if throttling is active (or bypasses the queue/setTimeout if disabled).

This would allow me to fully utilize the speed of the WebView2 interop without risking silent message drops or forcing artificial application slowdowns.

Screenshots

No response

Do you want to work on this issue/improvement?

Maybe

Any additional context?

No response

[mlipok]

Hi I be able to look deeply in next 4 weeks as, th 2 comming weeks will be have to me.