#ckeditor

The filter is only for text. It shouldn't be used for HTML.

The output of a text format is by definition HTML. Even if you're entering markdown or something, the end result is HTML, and the auto line break filter can theoretically be applied at any point in that process. You could say it should only be applied at the beginning, before any other HTML formatting is applied from different filters, and that editors shouldn't copy and paste paragraph breaks when using a format with the automatic line break filter, but the text format system doesn't enforce this at all, and I've had plenty of sites where a mixture of handwritten and copy and pasted content gets put into the same text format.

The question is, does this filter make any sense at all in conjunction with CKEditor fields

The media filter can be used without ckeditor5, so the line break filter ought to be able to work with it - and comments above suggest this is broken without any involvement from ckeditor5 at all.

There might well be a case for adding some validation to prevent the auto-line break filter from being configured alongside ckeditor5 though but that feels like a new issue to me.

* IMHO, I think this is correct. The filter is only for text. It shouldn't be used for HTML. I don't see any valid use-case either. Whether it really needs to check and silently fail or whether a description would enough is anyone's guess. There are other filters which just use the issue description to specifiy their restrictions in order to work correctly ("only use after/before this and that"). They don't check and silently fail in these cases either.
* This issue morphed into sth. else though. The original issue as still seen in the issue description was "we can't guarantee that the rendered representation of that media item will be a single HTML element". That's still a valid concern and by far isn't solved by just disabling this filter. But perhaps a new issue could be filed for this. The far more complicated problem to solve is: If a media *entity(!)* is rendered it unsurprisingly consists of entity *fields(!)*. When rendering these fields, there are DIV tags introduced at the very least because the default field item template contains DIV tags. I know this affects issues with far reaching consequences and this is probably not easy to change, but my take on this is: This is actually wrong. A DIV cannot appear inside a SPAN tag. This causes invalid HTML. Whenever a field is rendered inline you will get these problems which is kind-of sad. It could perhaps be solved without turning the whole of Drupal on its head if we said that field elements should be rendered with a special SPAN tag template just for the media entity display mode or sth. along these lines.

The question is, does this filter make any sense at all in conjunction with CKEditor fields? I think it's primarily meant for use with plain text fields, as CKEditor does this conversion already. I can't think of a use case for fields powered by CKE, so maybe we need a hint not to use it, or prevent usage at all for CKE fields. At least it should fail silently and not destroy the markup given by CKE.

Glad we got this isolated, I think with that in mind it shouldn't be too hard to write a test case.

Re-titling.

Moving this to filter module. Should be possible to write a test case given the examples above to reproduce the duplicate link, then we can try to fix it in _filter_autop

Did a quick test to look at this filter in isolation, by calling the _filter_autop() function directly. This is broken indeed:

$output = _filter_autop('<p><a href="https://google.de"><drupal-media/></a></p>')

Result:

<p><a href="https://google.de"></p>\n
  <drupal-media/></a></p>