Repeating section field area is blank after submitting

[jbhuddleston]

I am creating my first repeating section to store notes and comments on a form from successive users.

I have managed to capture the data in the sharepoint list (XML multiline text) and then format the elements of it for HTML output and store that as well, however, the entire repeating section that contained the data when I submitted it is an appropriately sized large gray area, instead of continuing to show the data I submitted in the individual fields.
I can hit the add row and it simply expands the gray space.

Should I not be able to expect another set of the fields to be available for input, even if the submitted data is no longer shown in the original fields?
I am probably missing some very simple part of the process or expecting behaviour that is not supported, as I have not seen anyone else reporting this problem.

[MegaJerk]

Interesting. I have a question. Let's say your Repeating Section is connected to a Plain-Text Multiline Column called RsXML. In your workflow, when you format your XML into an HTML Table, are you saving it back to the RsXML column or are you saving it to a different column? 

If you're overwriting the XML with HTML then that is likely the issue, and you simply need to save your output into a different multi-line column (likely with rich formatting so it displays as an actual table!)

If this scenario is not the case, then it would be helpful to see what the XML is before your workflow runs, and what it is after just to make sure that there isn't *something* that is changing it. 

If it's identical, then the connected column isn't the issue, and I'd start looking to see if you have any rules running on the form that are attached to the Repeating Section.

No matter, post back with some more pictures and examples if none of this works, and we can take a deeper look at it. 

[jbhuddleston]

I have checked each of your possible causes and come up empty.

I have had no issues when using Responsive forms but for this task I am using a Classic Form. Might that be the problem even though there is nothing I can find in the documentation to indicate that?

[MegaJerk]

Well then for a next step, I recommend producing some screenshots of test data, and some xml (before and after workflow) of the test data if at all possible

[jbhuddleston]

I have checked the XML for the repeating section both before and after and they are identical.
Another colleague just created two forms with repeating sections in the same environment I am using; one Responsive and the other Classic. The responsive works fine while the classic does not so I think the problem may lie there. Do you think it otherwise?

[MegaJerk]

I'm saying that without actually seeing what is happening, it's difficult to say! Classic forms can sometimes have issues with Repeating Sections, depending on the version and how temperamental your install is being!

If you wanna see if it's throwing errors, open the Dev Console (in Chrome this is F12, might be the same for FireFox), and then navigate to the Form. See if it throws any errors (in red) in the console. 

If it has errors, they should display in red, and it might help pin down what's going on. However, if you just want to use Responsive Forms instead, that is also an option. 

[jbhuddleston]

Thanks for the tip/reminder about dev tools.
I checked the console while performing various operations and no errors. However, I checked the elements and discovered that the repeating section elements were being hidden in the element:style and that the form in edit mode has something wrong with the people picker for the next element people picker.

Here are the snips of the form in display mode along with the element and style info and again in edit mode. Perhaps you will be able to see something that I am missing.

Thanks for your patience with me on this. I think we are getting closer to finding out the cause.

[MegaJerk]

The way that Repeating Sections work under the hood is that the first row is always hidden, and is used as a "clean" baseline template for when you Add a new Row. Additionally that intentionally invisible row is given the class "nf-repeater-row-hidden" to differentiate it from the other user facing rows, so that is not an issue and that row should remain hidden. 

Looking at your form, I see that you've filled something out, and then you've looked at the form in View Mode, and whatever you filled out still seems to be there. Is the Repeating Section no longer turning into a grey mess? 

[jbhuddleston]

The first row being hidden makes sense but then it should not just be hidden but also occupy no space.

No, still plain grey; I just unhid the elements (see the visibility: hidden is unchecked and /* commented out */ in the style section of the element) so we could see what was taking up the space.

I have it unhidden in both in view mode and edit mode. Your statement of the template row being hidden on purpose makes the incorrect formatting of it in edit-mode less sinister. If it is the template for the people picker and not the actual people picker, that is probably fine.
However, it is still occupying space in the form when it should not, I think.

[MegaJerk]

in your dev console, if you were to right click on that hidden row (with the hidden row class), and select Copy -> Copy outerHTML, could you paste the contents here? 

I wanna see if there is some class missing or something attached to it that would prevent it from hiding.