This may be a regression in our newline handling, or just an edge case. When viewing a conflict between base revision https://test.wikipedia.org/w/index.php?diff=425275 , conflicting revision https://test.wikipedia.org/w/index.php?diff=425276 , and my edits which added a line at the end, I got this dialog:
The empty boxes are disconcerting although reasonable since there's a whitespace change. However, the difference isn't visible because the text boxes both contain no text. Newlines have been optimized out into the split-linefeeds hidden inputs, so there's no way for a user to meaningfully choose between sides.
A second bug: when the user edits and resets the text field, the newlines reappear but this time inside the text! Hidden linefeed counts are still present, so I would imagine the linefeeds will be saved double. The difference between actual text and stored "reset" text also throws off our change detection code on the client.
A third bug: selecting the side with the newlines, "\n\n" in the textarea and hidden field with value "2" linefeeds, and saving the page, I would expect to see 4 linefeeds. Instead, I see zero.
Leading newlines get lost
How to demo: Create a conflict, but make sure to add some newlines at the beginning of the page when you do the second edit. The merge UI will show these as two empty boxes (this is to be fixed later, see T250402). Pick the empty box on the right (it represents the newlines you added). Merge. Look at the diff. The newlines should appear there.
Reset warning pops up when it shouldn't
How to demo: Cause a conflict. Start editing in one of the blocks. Add or remove newlines at the end of this block. Accept this block. Now reset this block. No warning should be shown, because newlines at the end don't matter when the merge is done later.
Incomplete tracking of newlines at the beginning of text blocks
This is related to T248668: Edge case: newlines can break talk page use case. Before, newlines have been tracked as part of the previous block of text. This worked badly when there was no previous block, or the previous block was a conflicting one.
How to demo: Create a page with a few paragraphs. Make sure there are multiple empty lines between two of the paragraphs. Now cause a conflict in the text below the empty space you just created. Change some text and add one or more additional newlines. Old, bad behavior: This caused 2 conflicts, one in the paragraph where the text actually changed, and one in the previous paragraph. Fixed behavior: Only the paragraph with actual changes shows up. When you pick your side, the resulting page should contain both the text changes as well as the additional newlines.