FORM command output bug, based on input method

[MarketHubb]

Issue detailed in short loom.

When calling <%CHILDREN%> on at item in a Form block after calling the <%FORM%> command on that same block, the index is off by 1.

[mdroidian]

Interesting. Unfortunately I can't seem to repo this:

https://www.loom.com/share/4ef4c3157dd14c47928fde729412c7d3

Could you share the full FORM blocks so I can try recreate the same environment.

[mdroidian]

Thank you for access to the graph. I was able to repo it.

It seems to be the case that the input method used for both the menu select and form confirmation determines if the issues surfaces.

https://www.loom.com/share/e27c5506ebef41ed83bc07a401237448

not broken

• click, click cancel/submit
• click, click out
• click, esc
• enter, click out
• enter, enter cancel/submit

broken

• enter, esc
• enter, click cancel/submit

In your example video, the input method was enter, click submit, which supports these findings.

A similar bug has shown itself in other places related to BlueprintJS's Dialog.
Unfortunately, if this is the same bug, it could be tricky to fix.

Could you confirm my findings by trying the above methods?

If they are the same for you, I'll work on creating a minimal reproducible example to narrow the search.

[mdroidian]

To be clear, it doesn't seem that the issue is with the index, rather the text being added to the trigger block.

https://www.loom.com/share/3c6e845695dd465b96a12aef58fd2b83

[mdroidian]

https://www.loom.com/share/30308eb2dd9340c39b53f6fbdf15d320

• to repo
  • trigger SmartBlock with Enter
  • add text to label
  • click Submit

- Form Bug Form
    - fields
        - this is some text
            - type
                - text
            - label
                - test
    - output
        - inline
- #SmartBlock Form Bug
    - <%FORM:Form Bug Form%>

[MarketHubb]

@mdroidian

What an obscure bug! Thanks for clarifying the issue