Change:
return str.match(regex); } <del> --fcc-editable-region-- </del> function addEntry() { const targetInputContainer = document.querySelector(`#${entryDropdown.value} .input-container`); const entryNumber = targetInputContainer.querySelectorAll('input[type="text"]').length; <del> const HTMLString = ``; </del> <ins> const HTMLString = ` --fcc-editable-region-- --fcc-editable-region-- `; </ins> } <del> --fcc-editable-region-- </del> ```

Discussion:
The test for Step 44 does not pass as it should when the user creates a newline with a newline literal, and not by pressing the enter key on their keyboard and making the string extend by a line. The challenge should report successful, as the created label has a newline before it. ! ! Device: Desktop, Arch linux, Firefox OS: 6.6.7-arch1-1 Browser: Firefox Version: 120.0.1 (64-bit) No response
Ran into this issue in the today.
Not sure I understand why we care if there is a new line. If this requirement is meant as a code formatting requirement we shouldn't allow the use of and instead change the text to be more precise. Simply changing "with" to "on" might be enough.
Yeah I would improve the instruction as well, instead of changing the tests. The starting code of the subsequent steps have this line on a new line, so I think we should guide campers to follow the same format here.
so it is not a parsing issue then but an instruction issue?
I would say so. I can't imagine the text "Start your with a new line" in any way referring to using . I think it just needs to be clarified.
I can easily imagine people interpreting that as using a at the beginning of the string. Also, this appears to be the first time a step uses multiple lines in a template literal, so it may not be obvious to the user that you can do that, and thus they might think that is their only option. I'm struggling to find a reason why we care whether they use or an actual hard return here? Maybe the point is to teach that template literals allow for multi-line strings? If that's the case then we need to explain that in the instructions. Otherwise, this restriction of not allowing seems rather capricious.
Which is why I said it should be clarified. As far as I'm concerned the new line asked for only serves as code formatting. It has no other importance. <sAllowing doesn't make sense as it does not produce the same code as going down on a new line before creating the element (also it doesn't do anything useful). </sEdit: never mind I thought they had a space as well. But as I said initially, I do not see the importance of testing for the new line.

It seems fairly irrelevant.
What about changing the seed code so the user does not need to do this at all? That seems like a good solution to me. Change the instructions to:
It looks like we are still getting users on the forum, getting stuck on this issue. I vote we move forward with 's suggestion of just updating the instructions and changing the editable regions to make it super clear where they need to write their code.
This is what I have and can't still move ahead: function addEntry() { const targetInputContainer = document.querySelector(); const entryNumber = targetInputContainer.querySelectorAll('input[type="text"]').length; const HTMLString = `; HTMLString = <labelEntry ${entryNumber} Name</label`;
Hey Instead of asking for help here, please click the "Help" button on the challenge on freeCodeCamp, which will help you create a question in the right part of the forum. Volunteers on the forum usually respond to questions within a few hours and can help determine if there is an issue with your code or the challenge's tests. Thank you and happy coding.