On the 3rd page the value under 'Descriptor of vessel(s)' is a pull down. Changing it should change the values available in 'Sub-descriptor of vessel(s)' beside it.

This is very similar to https://bugs.chromium.org/p/pdfium/issues/detail?id=954, the file looks the same but is slightly different. Here the "Sub-descriptor of vessel(s)" drop down show options, but they do not change.

Extracting just the relevant choiceLists and scripts into a Full XFA document this behaviour works fine. I suspect the root issue here is that the document is a Foreground XFA and something about the bindings to XFA is screwed up.

The scripts of interest here are attached to the enter event handler, which never fires on the full document.

Looking at what is going on in the full document case, it appears that the mouse move event is causing a enter event, which is being sent to the PDF widget, but that is not being forwarded to XFA.

This has surfaced some deep architectual issues. After resolving issues with enter event forwarding, values will still not update in the UI. This is because the XFA scripting layer and the AcroForms Widget have no knowledge of each other. The XFA code only knows how to talk to XFA Widgets and not AcroForms. Additionally AcroForms Widgets do not forward user entered data into the data layer that XFA knows how to talk to.

Fixing this requires 3 basic steps, that are probably each a ton of work.
1) Change XFA scripting code(CFXA_Node I think) to send UI change call to a UI proxy, which will route to the appropriate XFA or AcroForm Widget, instead of directly accessing the widget.
2) Add a listener interface to the AcroForm Widgets, which the XFA node will be the only implementer of.
3) Change the creation code for PDF loading, so that all of the AcroForm Widgets are created and then the XFA tree is created. As the XFA tree is being created, determine for each new node if there is an AcroForm Widget associated with it. If there is, then use that widget in the UI proxy, and have the node register as a listener on the widget. If there is not an AcroForm widget, then create a XFA widget as normal and use that in the proxy.

In addition to c5 data flow changes there will need to be event forwarding implemented, but that I think that can be piggybacked to what needs to be done for data flow.

Removing myself from bugs I do not plan to address while working 20% on PDFium.