Jinjafx_input: Multiple <textarea> Elements Merge Into One Variable Due To Missing Newline After First Scalar
jinjafx_input: Multiple
Description
When a custom jinjafx_input
form contains two or more <textarea>
elements, the client-side code concatenates the second textarea's YAML block header onto the end of the first textarea's scalar because the terminating CRLF is missing. The YAML loader therefore interprets the entire fragment as one scalar, so only the first key is produced in jinjafx_input
, with both textarea contents jammed together.
This issue arises due to a missing newline character after the first scalar in the jinjafx_m.js
file. As a result, the YAML loader fails to correctly parse the YAML block, leading to unexpected behavior.
Steps to Reproduce
To reproduce this issue, follow these steps:
-
Create a
vars.yml
file with the following content:--- jinjafx_input: body: |2 <div class="mb-3"> <label for="t1" class="form-label">Notes</label> <textarea class="form-control" id="t1" rows="3" data-var="notes"></textarea> </div> <div class="mb-3"> <label for="t2" class="form-label">Comments</label> <textarea class="form-control" id="t2" rows="3" data-var="comments"></textarea> </div>
-
Launch JinjaFx and fill both textareas with the following values:
"Text area"
,"Text area 2"
-> Generate. -
Inspect the variables with the following Jinja2 code:
{{ jinjafx_input | to_nice_json(indent=2) }}
Expected Behavior
The expected behavior is that the jinjafx_input
variable should contain two separate keys: notes
and comments
, each with its corresponding value.
{
"notes": "Text area",
"comments": "Text area 2"
}
Actual Behavior
However, due to the missing newline character, the actual behavior is that the jinjafx_input
variable contains only one key: notes
, with the value being a concatenation of the first textarea's value and the second textarea's YAML block header.
{
"notes": "Text area comments: |2\nText area 2"
}
Root Cause
The root cause of this issue is the missing newline character after the first scalar in the jinjafx_m.js
file. Specifically, the line of code that appends the scalar to the vars_yml
string is missing the \r\n
characters.
var vars_yml = 'jinjafx_input:\r\n';
// ...
vars_yml += ' ' + v + ': ' + vars[v]; 👈🏼
This omission causes the YAML loader to interpret the entire fragment as one scalar, leading to the unexpected behavior.
Environment
The environment in which this issue was encountered is as follows:
-
JinjaFx Server:
v25.7.0
-
OS: macOS 15.4.1 (local devcontainer:
python:3.12-slim
andPEP660 workflow
) -
Browser:
Chrome 136.0.7103.93
-
Run command:
docker run --rm -it -p 8080:8080 -v "$PWD":/app jinjafxserver-localdev
Suggested Fix
To fix this issue, a simple one-line change can be made to the jinjafx_m.js
file. Specifically, the line of code that appends the scalar to the vars_yml
string should be modified to include the missing newline character.
- vars_yml += ' ' + v + ': ' + vars[v];
+ vars_yml += ' ' + v + ': ' + vars[v] + '\r\n';
This change should be applied to the line of code that is currently missing the newline character. With this fix, the YAML loader should correctly parse the YAML block, and the jinjafx_input
variable should contain the expected values.
Conclusion
In conclusion, the issue of multiple <textarea>
elements merging into one variable due to a missing newline character after the first scalar is a bug in the jinjafx_m.js
file. By applying a simple one-line fix, this issue can be resolved, and the jinjafx_input
variable should contain the expected values.
jinjafx_input: Multiple
Q: What is the issue with the jinjafx_input form?
A: The issue with the jinjafx_input
form is that when it contains two or more <textarea>
elements, the client-side code concatenates the second textarea's YAML block header onto the end of the first textarea's scalar because the terminating CRLF is missing. This causes the YAML loader to interpret the entire fragment as one scalar, leading to unexpected behavior.
Q: What is the expected behavior of the jinjafx_input variable?
A: The expected behavior of the jinjafx_input
variable is that it should contain two separate keys: notes
and comments
, each with its corresponding value.
{
"notes": "Text area",
"comments": "Text area 2"
}
Q: What is the actual behavior of the jinjafx_input variable?
A: The actual behavior of the jinjafx_input
variable is that it contains only one key: notes
, with the value being a concatenation of the first textarea's value and the second textarea's YAML block header.
{
"notes": "Text area comments: |2\nText area 2"
}
Q: What is the root cause of this issue?
A: The root cause of this issue is the missing newline character after the first scalar in the jinjafx_m.js
file. Specifically, the line of code that appends the scalar to the vars_yml
string is missing the \r\n
characters.
var vars_yml = 'jinjafx_input:\r\n';
// ...
vars_yml += ' ' + v + ': ' + vars[v]; 👈🏼
Q: How can this issue be fixed?
A: This issue can be fixed by applying a simple one-line change to the jinjafx_m.js
file. Specifically, the line of code that appends the scalar to the vars_yml
string should be modified to include the missing newline character.
- vars_yml += ' ' + v + ': ' + vars[v];
+ vars_yml += ' ' + v + ': ' + vars[v] + '\r\n';
Q: What is the environment in which this issue was encountered?
A: The environment in which this issue was encountered is as follows:
-
JinjaFx Server:
v25.7.0
-
OS: macOS 15.4.1 (local devcontainer:
python:3.12-slim
andPEP660 workflow
) -
Browser:
Chrome 136.0.7103.93
-
Run command:
docker run --rm -it -p 8080:8080 -v "$PWD":/app jinjafxserver-localdev
Q: Can this issue be reproduced?
A: Yes, this issue can be reproduced by following the steps outlined in the "Steps to Reproduce" section of the original article.
Q: What is the suggested fix for this issue?
A: The suggested fix for this issue is to apply the one change to the jinjafx_m.js
file, as outlined in the "Suggested Fix" section of the original article.
Q: Will this fix resolve the issue?
A: Yes, this fix should resolve the issue and ensure that the jinjafx_input
variable contains the expected values.