Bug #12366


Form data can lose synchronization with default TwoPhaseRenderingThreshold -- regression

Added by Bruce Toll 3 months ago. Updated 2 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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.

Actions #1

Updated by Matthias Van Ceulebroeck 2 months ago

  • Target version set to 4.11.0

It really annoys me that that change had side-effects. The original issues were already a pain.
I'll see if I can find a more robust way to delay invisible changes that won't impact this.

Actions #2

Updated by Bruce Toll 2 months ago

Thanks for following-up. I really appreciate it.

Actions #3

Updated by Bruce Toll 2 months ago

NOTE: Issue #12424 mentions a similar problem with "undefined" values.


Also available in: Atom PDF