It fixes the issue, except it introduces an old bug #17398. It also happens on empty values, without NULL.

Also, I think it should be Line ending:, without s, since only one line ending can be selected and work at a time. Also, the help icon should be moved after :.

Hi @liviuconcioiu ,
thanks a lot for the review and for pointing these things out.

Just to clarify one point: the change in this PR does not introduce the old bug #17398 which has been demonstrated in the attached video. That said, I agree with your observation that it also occurs on empty values without NULL. I’ve addressed that case now in the latest update.

I’ve also updated the label to Line ending: (singular) and moved the help icon after the colon, as suggested.

Please let me know if you’d like me to adjust anything further. Thanks again for the helpful feedback!
[Screencast from 2026-02-06 19-50-46.webm]
(https://github.com/user-attachments/assets/9e5aadd7-66b5-4eb7-8ebb-e6b338e7abee)

UPDATE is still being triggered:

@liviuconcioiu I’ve gone through the scenario again on my end and also shared the recording as proof, but I’m still unable to reproduce the issue you’re observing. To make sure I’m not missing something, could you please share the exact table structure/schema (including column types and any relevant constraints) that you’re using when encountering this problem?
Having the precise structure would really help me set up the same environment locally and understand where the mismatch might be coming from. I’d like to ensure the fix works correctly for your case as well.
Thanks in advance for your help.

I use MariaDB 12.2.1 on Windows.

CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `colA` varchar(255) DEFAULT NULL,
  `colB` varchar(255) NOT NULL,
  `colC` int(10) unsigned DEFAULT NULL,
  `colD` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(`colD`)),
  `colE` uuid DEFAULT NULL,
  `colF` timestamp(6) NOT NULL DEFAULT current_timestamp(6),
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

INSERT INTO `test` (`id`, `colA`, `colB`, `colC`, `colD`, `colE`, `colF`) VALUES
(1, 'Lynne', 'Combs', 1, '{\"test\":100}', '7b42b69b-f744-11f0-9d12-806d971fcc98', '2026-01-22 03:43:14.629614'),
(2, 'Carlos', 'Lara', NULL, NULL, NULL, '2026-01-22 03:43:46.727948'),
(3, NULL, 'Lang', 200, '{\"x\":\"y\"}', NULL, '2026-01-22 03:44:20.661601'),
(4, NULL, '', NULL, NULL, 'c0b2cf7a-f744-11f0-9d12-806d971fcc98', '2026-01-22 03:45:11.126818');

Hi @liviuconcioiu, thanks for sharing the exact table structure/schema.
This turned out to be caused by jQuery’s .data() cache auto-casting values (numbers / JSON objects) on first access, which broke the comparison. Normalizing both sides fixes it.. I’ve now normalized both the canonical old and new values before comparison, which avoids the unnecessary updates you mentioned.
Please let me know if this looks correct from your side.

Found another problem. If I change the line ending to a cell from LF to CRLF, the cell below will have the same line ending as the first, instead of keeping it.

CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `value` text DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

INSERT INTO `test` (`id`, `value`) VALUES
(1, 'test\ntest'),
(2, 'test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test <td class=\"text-right\">\n        test test test test test test test test test test test test test test test test test test test test</td>');

Found another problem. If I change the line ending to a cell from LF to CRLF, the cell below will have the same line ending as the first, instead of keeping it.

Hi @liviuconcioiu, just a quick update! The issue you mentioned is now fixed. It was due to stale event handlers in the grid editor. Would appreciate a quick review when you’re free.

Everything is okay now!

There are some tests that don't pass:
https://github.com/phpmyadmin/phpmyadmin/actions/runs/22016015278/job/63835593911?pr=20076

CSS needs a little improvement:
https://github.com/phpmyadmin/phpmyadmin/actions/runs/22016015270/job/63835593397?pr=20076

And if you can update the baselines:
https://github.com/phpmyadmin/phpmyadmin/actions/runs/22016015270/job/63835593417?pr=20076

Due to how big the diff is, I think only 6.0 versions should be fixed. Maybe rebase onto the master branch.
@MauricioFauth what do you think ?

Hi @williamdes @MauricioFauth @liviuconcioiu , I’m following up on this PR in case it got buried. Please let me know if any changes are needed from my side. Thank you!

@og-khushalpatel Please look into the failing test cases.

There are some tests that don't pass: https://github.com/phpmyadmin/phpmyadmin/actions/runs/22016015278/job/63835593911?pr=20076

CSS needs a little improvement: https://github.com/phpmyadmin/phpmyadmin/actions/runs/22016015270/job/63835593397?pr=20076

And if you can update the baselines: https://github.com/phpmyadmin/phpmyadmin/actions/runs/22016015270/job/63835593417?pr=20076

@MoonE I believe I have already fixed the tests that were previously failing due to the changes in this PR.
There are still some failing tests, but they appear to be unrelated to the changes introduced in this PR. If you notice any tests failing specifically because of this PR, please point them out and I’ll be happy to address them

@MoonE I believe that finally all pipeline failures have been fixed except for one which is not manifesting because of this PR-related changes. I am really grateful for you helped me understand pipeline failure debugging which was a bit scary for a beginner like me. Let me know if I should notify the maintainers for review.

If a user edits a text value that at the begin has no line breaks, it's not possible to select the line breaks, even after closing and re-opening the edit box. It only shows up after a refresh of the whole browse result.

Would be great if it becomes visible after a new line is entered.

Implemented the code to make the line ending selector visible after a newline is entered. Just check it out:

Hi, I looked into the CI failure and I believe it's unrelated to my changes. The error occurs in the stop-local-server cleanup script:

cat: /tmp/last_temp_dir_phpMyAdminTests: No such file or directory

My changes only move i18n strings from JavaScriptMessagesController.php into the Twig template and adjust JS logic in makegrid.js — none of which affect the Selenium server startup (php-fpm/nginx). This looks like a CI environment issue.
Could we re-run the failed job to confirm?

Is there a reason why the line ending detection is done server-side and why an additional original value has to be included in the html?

There is existing logic loading the full text when it is displayed truncated, so it would make sense to get the data only when it is needed. Otherwise this can inflate the html size by a lot, which can be a problem when you have columns containing very long strings.

Maybe check here if the cell contains a <br> and then use the response value to initialize the line-break select?

Is there a reason why the line ending detection is done server-side

Great Question! Yes, this is intentional. According to the HTML spec, <textarea> normalizes all line breaks to \n when returning its value, even if the original database value contains \r\n. This normalization was the root cause of the false "value changed" detection on the client side (i.e., #19368 ), since the client would always see a difference between the textarea value and the original, triggering an unnecessary save.
By detecting line endings server-side, we preserve the actual line-break style stored in the database and can compare accurately.

why an additional original value has to be included in the html?

We need the server-provided original value as a source of truth to prevent \n duplication on each save cycle. Without it, when converting between LF and CRLF (or vice versa), the <br> tags were being duplicated; leading to exponential growth of line breaks in the stored value with every update. Including the original value lets us diff correctly against what the database actually holds, rather than relying on the textarea's already-normalized content.

Otherwise this can inflate the html size by a lot, which can be a problem when you have columns containing very long strings

That's a great point! To address this concern, the HTML size won't actually inflate, since for full-text database columns, I'm storing the truncated value in the data-original-value attribute rather than the complete column content. So the overhead remains minimal regardless of how long the underlying strings are.You can verify it in the following video:
Screencast from 2026-03-11 12-01-22.webm