Wt

With wt-4.10.3, there appears to be a regression with the client/server synchronization of form data with the default TwoPhaseRenderingThreshold -- at least in some circumstances.

The issue can be observed with the bundled charts.wt example. With wt-4.10.3, it logs 72 messages at session start-up of the form:

... [error] "WContainerWidget: WContainerWidget o103: error parsing form data: 'undefined', ignoring value"

From a git bisect, it appears that the messages started with commit: 935319c9f8

The issue may be that that the list of form elements sent to the client does not get adjusted to reflect the actual elements present when invisibleJS gets deferred to the second load phase. This results in "undefined" form data values being reported to the server for elements that have not yet been unstubbed by the deferred invisibleJS.

The chart3D application is another example. In this case, there is also an "undefined" form value received for a canvas element associated with the Wt::Chart::WCartesian3DChart widget. This form data gets silently ignored in Wt::WGLWidget::setFormData at WGLWidget.C:1126. However, prior to commit 935319c9f8, the first update would have provided actual data.

Other than the WContainerWidget log messages, I have not noticed any impact to apps from this issue. However, prior to commit 0fa09553, WContainerWidget would cause a session to terminate on an "undefined" form value. So, it seems that "undefined" form values were generally not expected prior to that update in late 2022. Given that there are many specializations of setFormData, it seems possible that some of them could be affected. Even if an "undefined" value gets ignored, the lack of an initial update could potentially have an observable effect.

A potential workaround for an affected app is the set the two phase rendering threshold to zero.