Problem/Motivation
Existing sites with CKEditor 4 can have 'Allowed HTML tags' containing the tags
<ul type> <ol type start>
For example:

When switching to CKEditor 5, these tags will be added to "Manually editable HTML tags":

Issue #3261599: Use CKEditor 5's native <ol start> support (and also support <ol reversed>) already covers 'start'.
However, 'type' is not yet handled and causes CKEditor 5 to break when empty lists are present, or added, using the Source option.
Steps to reproduce
The easiest way to trigger the same behaviour :
- Configure CKEditor 5 with the "Manually editable HTML tags" to include
<ul type> <ol type>
- Configure CKEditor 5 to include the "Source" button in the toolbar
- Find/create a text field on content using the editor and prepare it wil a list with at least one list item.
- Switch to "Source" mode and add an empty list (ul, ol) to the field.
- Turn off "Source" mode and observe CKEditor throwing an error while nothing visually happens.
- Try to turn off "Source" mode again a few times and observe weird visual behaviour
Example:
https://www.drupal.org/files/issues/2022-04-08/ckeditor5.mov
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comments
Comment #2
wim leersWonderful find! 🤩
Clarifying the title to make it clear that this only happens on invalid markup:
<ol></ol>and<ul></ul>, without<li>children is the only way to crash this.Upstream issue created based on your information 🙏🥳 https://github.com/ckeditor/ckeditor5/issues/11595
Comment #3
wim leersComment #4
wim leersActually, this does not make sense to be a stable blocker because A) it does not result in data loss, B) it requires very invalid HTML.
But it does seem given that the editor can no longer be used for content containing invalid HTML markup.
Comment #5
lauriiiI'm not sure if this changes whether this should be a stable blocker or not; but based on WHATWG,
<ul>and<ol>elements can contain zero or more li elements. 🤷♂️Comment #6
wim leersWow! 🤪
Comment #7
lauriiiComment #8
wim leersNote that even without the specific steps to reproduce reported here, #3274651: Impossible to enable <ol type> or <ul type> with GHS: switch to List's successor, DocumentList means that even when not trying to trigger the crash, the
typeattribute is lost.Therefore this is sort of postponed on #3274651: Impossible to enable <ol type> or <ul type> with GHS: switch to List's successor, DocumentList.
Comment #9
wim leersMaybe #3274651: Impossible to enable <ol type> or <ul type> with GHS: switch to List's successor, DocumentList fixes this 🤞
Comment #10
wim leersJust manually tested, and YAY! I can confirm that #3274651: Impossible to enable <ol type> or <ul type> with GHS: switch to List's successor, DocumentList indeed fixes this! 🥳
Transferring tags + credit to that issue 👍