event.html | Fail | 172 / 180 | BUG, TEST BUG | formatBlock with quasit and insertImage with an empty value fire input in Chrome and Safari only; 5 of the 8 failing subtests fail in every browser: the test expects an input event for commands that do nothing because their value is invalid (createLink, fontSize and formatBlock with an empty value, fontSize with quasit), and Changing selection from handler expects the event at the second editing host although nothing changes the selection; per the specification no event is fired when the action of the command returns false; fontSize with the value 15px is expected to fire input: the browsers parse the value with the legacy font size rules (the leading digits, 15), but the specification returns false for a value that is not a valid floating-point number, and editing/data/fontsize.js (editing/run/fontsize.html) expects 2em, 20pt and 1. to do nothing and return false, which the library passes; accepting the value here would fail these subtests |
other/body-should-not-deleted-even-if-empty.html | Pass | 2 / 2 | | |
other/br-tag-not-added-with-inline-root-editable-element.html | Pass | 1 / 1 | | |
other/cefalse-boundaries-deletion.html | Pass | 3 / 3 | | |
other/copy-paste-before-non-editable.html | Fail | 0 / 1 | TEST BUG | the copy and the paste work (Select is inserted before something in the Text node and no child node is lost), but the expected markup hard-codes the style attribute of the untouched non-editable span as Blink re-serializes it (style="border: 1px solid gray;", with a trailing semicolon) while the source attribute is style="border: 1px solid gray", which the library leaves as is. Firefox and Safari fail the same assertion. |
other/copy-paste-in-styled-inline-editing-host.https.html | Pass | 1 / 1 | | |
other/data_transfer_on_input_event_with_insertfrompaste_type.html | Pass | 1 / 1 | | |
other/delete-at-end-boundary-of-div-followed-by-inline-element-containing-hidden-select-element-with-non-editable-node.html | Fail | 0 / 1 | BUG | forward delete at the end of <div id="first">First block</div> followed by <span id="second">Second block<select style="visibility:hidden"></select></span>: the test expects only the text to join the block and <span id="second"><select ...></select></span> to stay after it; the library moves the whole following line into the block (<div id="first">First block\n<span id="second">Second block<select ...></select></span></div>), as the block merging of the specification does (Chrome and Safari pass, Firefox fails). |
other/delete-at-start-boundary-of-div-containing-hidden-select-element-with-non-editable-node.html | Fail | 0 / 1 | BUG | Backspace at the start of <div id="second">Second block<select style="visibility:hidden"></select></div>: the test expects only the text to be merged into the previous block and <div id="second"><select ...></select></div> to remain; the library moves every child of the block, including the hidden <select>, and removes the emptied block (<div id="first">First blockSecond block<select ...></select></div>), as the block merging of the specification does (Chrome and Safari pass, Firefox fails). |
other/delete-editing-host.html | Pass | 2 / 2 | | |
other/delete-in-inline-editing-host-under-shadow-root.html | Fail | 0 / 4 | TEST BUG | the helper of the test selects in the editing host of a shadow tree with Selection.addRange() and checks rangeCount. As the Selection API specifies, addRange() ignores a range whose root is not the document and rangeCount is 0 while the selection is in a shadow tree (it is only exposed by getComposedRanges()), so the helper throws "Failed to set selection to the given ranges" before any key is sent; Chrome and Firefox accept the range, Safari fails as the library does. |
other/delete-in-last-definition-list-item-when-parent-list-is-editing-host.html | Fail | 5 / 16 | BUG | Backspace or Delete in the last empty item of a list nested in a <dl contenteditable> is expected to leave one valid empty item of the host (<dd></dd> or <dd><br></dd>). Backspace only removes the nested list and leaves its item as an invalid child (<dd><li></li></dd>, <li></li> or <dt></dt> directly in the <dl>), as the algorithm of the specification does, and forward delete changes nothing (<dd><ul><li></li></ul></dd>). Only Firefox passes these 11 subtests. |
other/delete-in-last-list-item-when-parent-list-is-editing-host.html | Fail | 12 / 28 | BUG | Backspace or Delete in the last empty item of a list nested in a <ol contenteditable> or <ul contenteditable> is expected to leave one empty <li> of the host. Backspace in <dl><dt>{}</dt></dl> or <dl><dd>{}</dd></dl> converts the item to the default paragraph separator, which is an invalid child of the list (<ol contenteditable><div></div></ol>, as the algorithm of the specification does), and forward delete in any nested list changes nothing (<li><ul><li></li></ul></li>). Only Firefox passes these 16 subtests. |
other/delete-in-shadow-hosted-in-body.html | Fail | 2 / 3 | TEST BUG | for the <div contenteditable> in the shadow tree of the body (1 of 3 subtests; the <input> and the <textarea> pass): the helper of the test selects in the editing host of a shadow tree with Selection.addRange() and checks rangeCount. As the Selection API specifies, addRange() ignores a range whose root is not the document and rangeCount is 0 while the selection is in a shadow tree (it is only exposed by getComposedRanges()), so the helper throws "Failed to set selection to the given ranges" before any key is sent; Chrome and Firefox accept the range, Safari fails as the library does. |
other/delete-without-unwrapping-first-line-of-child-block.html | Fail | 260 / 300 | BUG | 40 of 300 subtests, all about getTargetRanges() of the Backspace and Delete keys (the DOM results pass): when the lines before a child block are deleted (abc<br>{<br><div id="child">]def<br>ghi</div>), the target range is the range of the selection, or the caret extended by one character, which ends in the first Text node of the block ((host, 2) - (#text "def", 0)); the test expects the range of what is removed, ending before the block ((host, 2) - (host, 3)). Only Firefox passes (Chrome fails them, Safari does not report them). |
other/delete.html | Fail | 15 / 16 | TEST BUG | 1 of 16 subtests: after Backspace in the last paragraph of <p><tt>x</tt></p><p><tt><br></tt></p><p><tt><br></tt></p> the markup is the expected one, but the test requires the caret in the remaining <tt> ((<tt>, 0), the Gecko behavior); the library leaves it in the paragraph, after the <tt> ((<p>, 1)); Chrome and Safari also fail this subtest. |
other/double-click-range-selection-in-floating-list-item.html | Pass | 2 / 2 | | |
other/double-click-range-selection-in-list-item.html | Pass | 2 / 2 | | |
other/editing-div-outside-body.html | Pass | 55 / 55 | | |
other/editing-host-with-only-out-of-flow-child.html | Pass | 4 / 4 | | |
other/empty-elements-insertion-padding.html | Pass | 1 / 1 | | |
other/empty-elements-insertion.html | Fail | 4 / 5 | BUG | 1 of 5 subtests: the press inside an empty <strong> without border, padding nor generated content puts the caret in the adjacent text of the editing host instead of in the empty element (it has no box that the pointer can hit), so the text of insertText is not inserted in the element. Only this subtest fails; it fails in Firefox too. |
other/end-key-with-wbr.html | Fail | 0 / 2 | BUG | in <wbr><wbr><span contenteditable="false">1</span><wbr><wbr><span contenteditable="false">2</span><wbr><wbr> the End key moves the caret from (div, 0) to (div, 6), after the last non-editable span, and the Home key from (div, 8) to (div, 2): the caret does not go past the <wbr> elements at the edges of the line, whereas the test expects the first and last positions of the editing host (only Chrome passes). |
other/extra-text-nodes.html | Pass | 2 / 2 | | |
other/fire-selection-change-on-deleting-empty-element.html | Pass | 1 / 1 | | |
other/html-text-copy-paste-of-anchor-with-href-in-content-editable.html | Pass | 1 / 1 | | |
other/inline-editing-host-has-placeholder-with-after-pseudo-element.html | Pass | 2 / 2 | | |
other/inline-editing-host-has-placeholder-with-before-pseudo-element.html | Pass | 2 / 2 | | |
other/insert-br-tag-on-text-node-removal-with-non-editable-elements.html | Pass | 3 / 3 | | |
other/insert-space-at-beginning-of-wrapped-line.html | Pass | 12 / 12 | | |
other/insert-text-with-surrogate-pairs.html | Pass | 1 / 1 | | |
other/inserthtml-do-not-preserve-inline-styles.html | Fail | 51 / 54 | TEST BUG | 3 of 54 subtests (the stylesInserting=hilitecolor variant) fail in every browser: the test compares queryCommandValue("hilitecolor") with "rgb(0, 255, 255))" (two closing parentheses). |
other/insertparagraph-in-non-splittable-element.html | Fail | 11 / 14 | BUG | 3 of 14 subtests, which only Firefox passes: with the caret set by script in a <button>, a <caption> or a <legend>, the test expects a line break in the element (<div><button><br>abc</button></div>), where the library splits the enclosing <div> (<div><br></div><div><button>abc</button></div>; for caption and legend, through the table or the fieldset, which is cloned). |
other/inserttext-after-bold-in-font-face-monospace.html | Pass | 1 / 1 | | |
other/inserttext-last-mutation.html | Pass | 64 / 64 | | |
other/join-different-white-space-style-left-line-and-right-paragraph.html | Pass | 2,607 / 2,607 | | |
other/join-different-white-space-style-left-paragraph-and-right-line.html | Pass | 1,455 / 1,455 | | |
other/join-different-white-space-style-paragraphs.html | Pass | 3,456 / 3,456 | | |
other/join-pre-and-other-block.html | Pass | 426 / 426 | | |
other/legacy-edit-command.html | Pass | 120 / 120 | | |
other/link-boundaries-insertion.html | Pass | 2 / 2 | | |
other/mathml-html-serializtion-on-copy.html | Fail | 1 / 4 | TEST BUG | the copied <math> tree is pasted as MathML elements, with the white space Text nodes that the source has between its elements (<math ...>\n <mrow>\n <mi>x</mi>...); the test expects the innerHTML of the pasted <math> without any white space (<mrow><mi>x</mi><mo>+</mo>...), which is the serialization of the copy of Chrome (only Chrome passes the test). |
other/merge-span-with-style-after-backspace-having-contenteditable.html | Fail | 0 / 1 | TEST BUG | the two headings are joined and the style of the moved span is preserved, but the expected markup requires the moved <span style="background-color: red;" id="space"> to lose its id attribute, an artifact of Blink and WebKit that rebuild the element from its style. The library moves the node itself, as the specification and Firefox do, and gets ...<span style="background-color: red;" id="space">space</span></h1>. |
other/merge-span-with-style-after-forwarddelete-having-contenteditable.html | Pass | 1 / 1 | | |
other/merge-span-with-style-after-pressing-enter-followed-by-backspace-in-contenteditable-div.html | Fail | 0 / 1 | TEST BUG | Enter then Backspace in <span style="background-color:red;">Back[]space</span> gives the expected structure, but the expected markup requires the style attribute of the second span to be re-serialized by the style engine (background-color: red; with a space) as Blink and WebKit do; the library clones the attribute of the split span verbatim (style="background-color:red;"), as the specification and Firefox do. |
other/no-beforeinput-when-no-selection.html | Pass | 5 / 5 | | |
other/non-html-document.html | Pass | 1 / 1 | | |
other/password-bidi-dblclick.html | Pass | 1 / 1 | | |
other/paste-text-after-collapsible-white-space-whose-container-remove-non-first-children.html | Pass | 2 / 2 | | |
other/paste-with-newline-three-times.html | Pass | 1 / 1 | | |
other/paste_text_with_text_transform.html | Error | 0 / 0 | TEST BUG | the test asserts at load that window.testRunner, the internal test API of WebKit and Blink, is defined ("This test requires testRunner to read/write clipboard") and uses the non-standard pasteAndMatchStyle command: the harness errors before any subtest, as in Chrome, Firefox and Safari on wpt.fyi. |
other/plain-text-copy-paste-of-paragraph-ending-with-non-layed-out-content.html | Pass | 9 / 9 | | |
other/removeformat_background_color.html | Pass | 6 / 6 | | |
other/restoration.html | Pass | 34 / 34 | | |
other/restyle-textcontrol-during-beforeinput.html | Pass | 2 / 2 | | |
other/select-all-and-delete-in-html-element-having-contenteditable.html | Pass | 12 / 12 | | |
other/selectall-in-editinghost.html | Fail | 3 / 4 | TEST BUG | 1 of 4 subtests: when the editing host is focused but the selection has no range, selectAll is expected to select only the content of the focused editing host; the library selects the content of the body, text before the host included, which is what the specification says for selectAll. Chrome and Safari fail this subtest too (only Firefox passes). |
other/selectall-without-focus.html | Pass | 3 / 3 | | |
other/selection-change-not-fired-if-selection-set-to-root.html | Pass | 1 / 1 | | |
other/setting-value-of-textcontrol-immediately-after-hidden.html | Pass | 28 / 28 | | |
other/shadow_root_iteration_in_block_style.html | Fail | 0 / 1 | TEST BUG | removeFormat with the selection inside the nested editing host <span id="span" contenteditable style="color:red">world</span> is expected to clear the style attribute of that span (style=""), which only Chrome does. The span is the editing host of the selection, hence not editable, and the specification never modifies it: the library keeps style="color:red", as its reference implementation, Firefox and Safari do. |
other/typing-around-link-element-after-joining-paragraphs.html | Fail | 32 / 48 | BUG | 16 of 48 subtests (the link contains a <b>: <p><a href style="color:rgb(0, 0, 255)"><b>foo</b></a></p><p><span ...>bar</span></p>): after Backspace or Delete has joined the paragraphs, the typed text is expected in a new <b> after the link (...<b>foo</b></a><b>XY</b><span ...>). The library gives the text the bold of the end of the link with the bold command, whose algorithm (the one of the specification, which reorders the modifiable descendants of the previous sibling) moves the <b> of the link around the link and the text: <p><b><a href ...>foo</a>XY</b><span ...>bar</span></p>. 16 pass in Firefox, 4 of them in Chrome, none in Safari. |
other/undo-insertparagraph-after-moving-split-nodes.html | Pass | 4 / 4 | | |
plaintext-only/delete-around-linebreak-or-block-boundary.html | Pass | 151 / 151 | | |
plaintext-only/delete-part-of-white-spaces.html | Pass | 14 / 14 | | |
plaintext-only/forwardDelete-around-linebreak-or-block-boundary.html | Pass | 151 / 151 | | |
plaintext-only/forwardDelete-part-of-white-spaces.html | Pass | 14 / 14 | | |
plaintext-only/insertHTML.html | Pass | 80 / 80 | | |
plaintext-only/insertLineBreak.html | Pass | 588 / 588 | | |
plaintext-only/insertParagraph.html | Pass | 40 / 40 | | |
plaintext-only/insertText.html | Fail | 204 / 212 | BUG | 8 subtests (2 per white-space variant) type text after insertParagraph replaced the whole content of a <b> (<p><b>[AB]</b></p>): the test expects the <b> to be kept in both paragraphs (<p><b><br></b></p><p><b>a</b></p>), in the library, as in the reference algorithm, the deletion of the selection removes the <b> that it empties before the paragraph is split (<p><br></p><p>a</p>); these subtests fail in Chrome, Firefox and Safari too |
plaintext-only/nested-with-contenteditable-true.html | Pass | 56 / 56 | | |
plaintext-only/paste-when-nested-with-contenteditable-true.https.html | Pass | 14 / 14 | | |
plaintext-only/paste.https.html | Pass | 84 / 84 | | |
plaintext-only/plaintext-only-in-designMode.html | Pass | 3 / 3 | | |
plaintext-only/styling-commands.html | Pass | 300 / 300 | | |
run/backcolor.html | Pass | 1,026 / 1,026 | | |
run/bold.html | Fail | 3,039 / 3,048 | TEST BUG | the 9 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/caret-navigation-after-removing-line-break.html | Pass | 2 / 2 | | |
run/caret-navigation-around-line-break.html | Pass | 20 / 20 | | |
run/caretnavigation.html | Pass | 2 / 2 | | |
run/createlink-with-selecting-img.html | Pass | 3 / 3 | | |
run/createlink.html | Pass | 441 / 441 | | |
run/delete-list-items-in-table-cell.html | Pass | 36 / 36 | | |
run/delete-to-make-editing-host-empty.html | Pass | 12 / 12 | | |
run/delete.html | Fail | 7,815 / 7,842 | BUG, TEST BUG | 10 of the 47 failing subtests (of 7842) come from behaviors of the browsers that are implemented although the data of the test expect the algorithm of the specification (every browser fails them, 8 with the result of the library in the three browsers): Backspace at the start of a <blockquote> joins its line to the previous one (foo<blockquote>[]bar</blockquote> gives foobar, expected foo<br>bar), two <li> are joined without keeping a <br> between their lines (<ol><li>foo<li>[]bar</ol> gives <ol><li>foobar</li></ol>, expected <ol><li>foo<br>bar</li></ol>; for <ol><li>foo<li>[]bar<br>baz</ol> Chrome and Safari only move the first line, the library moves the item as Firefox), and a paragraph emptied before a list item is removed instead of receiving the content of the item (<ol><li>foo</ol><p>[bar<ol><li>]baz</ol> gives two lists, expected <p>baz</p>).; the other subtests that every browser or two browsers pass: a selection from the end of an empty line to the start of a paragraph is expected to remove the line and keep the paragraph (foo<br><br>{<p>]bar</p> gives foo<br>bar, expected foo<br><p>bar</p>), the space before a deleted no-break space in another Text node is expected to become a no-break space (<b>foo </b> []bar gives <b>foo </b>bar, expected <b>foo </b>bar), the empty line between two tables in a <font> is not deleted (<table>...</table><br>{}<br><table>...), and Backspace at the start of a <div> that follows a non-editable <span> is expected to delete the span ( <span contenteditable="false">A</span><div>[] ; ...</div>), where the library unwraps the <div>.; 12 of the failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on a page where the styleWithCSS or defaultParagraphSeparator command of the test did not run (queryCommandState("stylewithcss") before expected false but got true); they also fail in Chrome and Safari. |
run/fontname.html | Fail | 2,219 / 2,225 | TEST BUG | the 6 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/fontsize.html | Fail | 2,415 / 2,422 | TEST BUG | the 7 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/forecolor.html | Fail | 2,320 / 2,327 | BUG, TEST BUG | <span style=color:brown>fo[o</span><span style=color:#0000ff>b]ar</span> expects the selected characters in one new element between the two spans (<span style="color:rgb(165, 42, 42)">fo</span><font color="#0000ff">ob</font><span style="color:rgb(0, 0, 255)">ar</span>, Chrome and Safari); the library moves o into the second span (<span style="color:rgb(165, 42, 42)">fo</span><span style="color:rgb(0, 0, 255)">obar</span>); 1 of the 7 failing subtests fails in every browser: setting the color of the outer element on [bar] of <span style="color: blue">foo<span style="color: brown">[bar]</span>baz</span> with styleWithCSS off expects the outer span to be split (<span style="color:rgb(0, 0, 255)">foo</span><font color="#0000ff">bar</font><span style="color:rgb(0, 0, 255)">baz</span>); the library only removes the inner span, as the reference algorithm; 5 of the 7 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/formatblock.html | Fail | 5,019 / 5,046 | BUG, TEST BUG | 4 of the 37 failing subtests pass in every browser (1) or in Chrome and Safari (3): formatBlock on the first heading of an <hgroup> is expected to replace the heading in the <hgroup> (<section><hgroup><blockquote>foo</blockquote><h2>bar</h2></hgroup>..., the library moves the new block out of the <hgroup>), <div>[foo<p>bar]</p></div> is expected to move the first line out of the <div> (<p>foo</p><div><p>bar</p></div>), and queryCommandValue("formatblock") is expected to be empty for a selection over three <p> (<p>[foo<p>bar]<p>baz, the library returns p, as for <p>[foo<p>bar], where the data expects p); formatBlock with <div> in the item of a list that is in a <div> wraps the content of the item: <div><ol><li>[foo]</ol></div> gives <div><ol><li><div>foo</div></li></ol></div>, as for <ol><li>[foo]</ol> (which the data expects), where every browser and the data leave the list unchanged (2 subtests); 11 of the 37 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox); 8 other subtests expect the behaviour of Firefox only (formatBlock returning false in an editing host that cannot contain the block, <span contenteditable> or <p contenteditable>), and 2 that fail in every browser expect queryCommandIndeterm("formatblock") to be true for a selection over the <dt> and the <dd> of a <dl> |
run/forwarddelete.html | Fail | 7,469 / 7,491 | BUG, TEST BUG | 8 of the 46 failing subtests (of 7491) come from behaviors of the browsers that are implemented although the data of the test expect the algorithm of the specification (every browser fails them, 7 with the result of the library in the three browsers): forward delete in an empty paragraph or list item before a list removes the empty block and keeps the list (<ol><li>foo</ol><p>{}<br></p><ol><li>bar</ol> gives <ol><li>foo</li></ol><ol><li>bar</li></ol>, expected <p>bar</p>; <ol><ol><li>foo</ol><li>{}<br><ol><li>bar</ol></ol> keeps the nested list, as Chrome and Firefox).; the other subtests that every browser or two browsers pass: the line feed that starts a white-space: nowrap line after the deleted character is not removed (<div style=white-space:nowrap>[]f\nbar</div> gives \nbar, expected bar), a selection from the end of an empty line to the start of a paragraph is expected to remove the line and keep the paragraph (foo<br><br>{<p>]bar</p> gives foo<br>bar, expected foo<br><p>bar</p>), and the empty line between two tables in a <font> is not deleted (<table>...</table>{}<br><br><table>...).; 10 of the failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on a page where the styleWithCSS or defaultParagraphSeparator command of the test did not run; they also fail in Chrome and Safari. |
run/hilitecolor.html | Fail | 1,217 / 1,218 | TEST BUG | the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/indent.html | Fail | 1,323 / 1,329 | BUG, TEST BUG | with styleWithCSS the data expects what the browsers generate, <p style="margin-left:40px">abc</p> or <blockquote style="margin:0 0 0 40px; border:none; padding:0px">; the library creates a plain <blockquote>, as the specification says (2 subtests that pass in every browser); and <ol><li>foo<ol><li>bar</ol>[baz]</ol> expects the whole item to be indented (<ol><ol><li>foo<ol><li>bar</li></ol>baz</li></ol></ol>, Chrome and Firefox) where the library, as the reference algorithm, moves baz into the nested list; the test of { <span contenteditable="false">A</span> ; <span contenteditable="false">B</span> ; ... } expects one block around the text and the non-editable spans; the library, as the reference algorithm, wraps each ; between the spans in its own <blockquote> (2 subtests that fail in every browser); the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/insert-list-items-in-table-cell.html | Fail | 81 / 112 | BUG, TEST BUG | a selection that covers the cells of two rows wraps the whole table in a list item (<ol><li><table>...</table></li></ol>) where the test expects a list in each cell (only Chrome passes); toggling the list off leaves the text in a <div> in the cell (<td><div>fsdf</div></td>, expected <td>fsdf</td>, Chrome and Firefox); and a <br> inside <b> does not split the cell content in two items (<ol><li>f<b>s<br>d</b>f</li></ol>, only Firefox passes); 26 of the 31 failing subtests expect queryCommandValue("insertOrderedList") to return the state as a string ("false"/"true"), which is what Chrome and Safari return; the command has no value in the specification and the library returns the empty string, as Firefox and the reference implementation |
run/inserthorizontalrule.html | Fail | 1,346 / 1,348 | TEST BUG | fo[o<span contenteditable=false>bar</span>b]az expects the non-editable span of the replaced selection to be kept (fo<hr><span contenteditable="false">bar</span>az), which is the result of the reference algorithm (it never removes a non-editable node); the library deletes the selection with the span, as the browsers do when deleting (fo<hr>az); the test fails in every browser; the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/inserthtml.html | Fail | 1,557 / 1,565 | BUG, TEST BUG | 2 of the 8 failing subtests, that only Chrome passes: a <span style=display:none> inserted over the content of a paragraph is followed by a <br>, which keeps the line of the paragraph (expected <p><span style="display:none"></span></p>); 5 subtests expect the behaviour of Firefox only (a <pre> inserted in a <pre> is merged: <pre>12abc34</pre>; content inserted after a <span><br></span> goes into the span), and the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/insertimage.html | Fail | 961 / 962 | TEST BUG | the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/insertlinebreak.html | Fail | 1,690 / 1,691 | TEST BUG | 4 of the 6 failing subtests insert a line break at the end of a <span> in a flex or grid container with white-space:pre and expect a line feed followed by a <br> (<span>abc\n<br></span>); the library inserts two line feeds (<span>abc\n\n</span>, the second one keeps the new line visible); these subtests fail in every browser; the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/insertorderedlist.html | Fail | 1,722 / 1,761 | BUG, TEST BUG | 13 subtests that only Chrome passes expect the nested list of a converted item to stay in the item (<ul><li>[foo]<ul><li>bar</ul><li>baz</ul> gives <ol><li>foo<ul><li>bar</li></ul></li></ol><ul><li>baz</li></ul>), where the library, as the reference algorithm, gives <ol><li>foo</li></ol><ul><ul><li>bar</li></ul><li>baz</li></ul>; 3 expect a list created in a <div dir=rtl> to keep the direction on the list or the block (<ol dir="rtl"><li>abc</li></ol>, the library sets it on the item: <ol><li dir="rtl">abc</li></ol>); in an empty <div> or <p> the list is created but the text is inserted beside the empty item (<ol><li></li>abc</ol>, only Firefox passes), and a <div> that only contains a <br> is replaced by the list instead of containing it (3 subtests in total); 3 other subtests are the variant boundaries and the styleWithCSS state that the page enables before the first test; 16 of the 41 failing subtests expect queryCommandValue("insertorderedlist") to return the state as a string ("false" before, "true" after), which is what Chrome and Safari return; the command has no value in the specification and the library returns the empty string, as Firefox and the reference implementation |
run/insertparagraph.html | Fail | 7,165 / 7,195 | BUG, TEST BUG | 3 of the 30 failing subtests. 2 subtests that Chrome and Safari pass: <div>[abc]</div> is expected to give <br><div><br></div> (the library replaces the selected text and splits the <div>). 1 passes in Chrome and Firefox (<pre>foo []</pre>).; 27 of the 30 failing subtests expect the result of Firefox only (13) or fail in every browser (14), e.g. <span>foo[]</span>, whose data expects <div><span>foo</span></div><div><br></div> where every browser (and the library) clones the span in the new line (<div><span><br></span></div>), and the subtests that come from the split in variants by subtest index (a variant starts in the middle of a test, after the subtests that call execCommand()). |
run/inserttext.html | Fail | 2,993 / 3,009 | BUG, TEST BUG | 4 of 16 failing subtests, that two browsers pass: the text typed over a selection that contains all the contents of <b><i> and starts with an image (abc[<b><i><img>def]</i></b>ghi) is expected out of the elements (abcdefghi, Chrome and Firefox), and <div>a<br>{}<span></span><p>c</p></div> expects the text in the next paragraph (Chrome and Safari).; 12 subtests expect the behaviour of Firefox only (10) or fail in every browser (2): e.g. <a href=/>foo[]</a>bar, whose data expects the text in the link (fooa) where the library, as the browsers for the text typed at the end of a link, inserts it after the link; the others are the variant boundaries and the styleWithCSS state that the page enables before the tests. |
run/insertunorderedlist.html | Fail | 2,030 / 2,065 | BUG, TEST BUG | 12 subtests that only Chrome passes expect the nested list of a converted item to stay in the item (<ol><li>[foo]<ol><li>bar</ol><li>baz</ol> gives <ul><li>foo<ol><li>bar</li></ol></li></ul><ol><li>baz</li></ol>), where the library, as the reference algorithm, moves the nested list out of the new item; 5 that Chrome and Firefox pass expect the direction of a <div dir=rtl> on the list or the block (the library sets it on the item: <ul><li dir="rtl">abc</li></ul>) and a selection that ends at the start of a third block not to include it (<div>[abc</div><div>def</div><div>]ghi</div> gives three items in the library); in an empty <div> or <p> the list is created but the text is inserted beside the empty item (<ul><li></li>abc</ul>, only Firefox passes), and a <div> that only contains a <br> is replaced by the list instead of containing it (3 subtests in total); 10 of the 37 failing subtests expect queryCommandValue("insertunorderedlist") to return the state as a string ("false" before, "true" after), which is what Chrome and Safari return; the command has no value in the specification and the library returns the empty string, as Firefox and the reference implementation; 4 others are the variant boundaries and the styleWithCSS state that the page enables before the first test |
run/italic.html | Fail | 2,069 / 2,073 | TEST BUG | the 4 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/justifycenter.html | Fail | 6,181 / 6,203 | TEST BUG | 21 of the 22 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox); the last test ({ <span contenteditable="false">A</span> ; <span contenteditable="false">B</span> ; <span contenteditable="false">C</span> }) expects one block around the text and the non-editable spans (<div style="text-align:center"> <span contenteditable="false">A</span> ; ...</div>); the library, as the reference algorithm (which never moves a non-editable node), wraps each ; between the spans in its own block; it fails in every browser |
run/justifyfull.html | Fail | 4,745 / 4,762 | TEST BUG | 16 of the 17 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox); the last test ({ <span contenteditable="false">A</span> ; <span contenteditable="false">B</span> ; <span contenteditable="false">C</span> }) expects one block around the text and the non-editable spans (<div style="text-align:justify"> <span contenteditable="false">A</span> ; ...</div>); the library, as the reference algorithm (which never moves a non-editable node), wraps each ; between the spans in its own block; it fails in every browser |
run/justifyleft.html | Fail | 2,497 / 2,503 | TEST BUG | the 6 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/justifyright.html | Fail | 4,797 / 4,814 | TEST BUG | 16 of the 17 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox); the last test ({ <span contenteditable="false">A</span> ; <span contenteditable="false">B</span> ; <span contenteditable="false">C</span> }) expects one block around the text and the non-editable spans (<div style="text-align:right"> <span contenteditable="false">A</span> ; ...</div>); the library, as the reference algorithm (which never moves a non-editable node), wraps each ; between the spans in its own block; it fails in every browser |
run/misc.html | Fail | 422 / 423 | TEST BUG | the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/multitest.html | Fail | 9,856 / 10,092 | BUG, TEST BUG | about 54 subtests, nearly all in the last variant (26 pass in every browser, 15 in Chrome and Firefox, 12 in Chrome and Safari), check the style of the text typed after another command: the line break of insertLineBreak over a selection that ends in inline elements is expected before them (abc<br><b><i>def</i></b>ghi, the library gives abc<b><i><br>def</i></b>ghi), the font elements of several value commands are expected merged in one (<font color="#ff0000" face="monospace" size="7">) or in a fixed order (italic then bold then typing expects <i><b>, the library gives <b><i>), and the text typed after a deletion that joins two blocks is expected in the inline element of the end of the first block (<span style="color:rgb(0, 0, 255)">fooA</span>).; about 156 of the 241 failing subtests expect elements where the library generates CSS ([["bold",""],["inserttext","a"]] on foo[]bar expects foo<b>a</b>bar, the library gives foo<span style="font-weight:bold">a</span>bar): the page runs execCommand("styleWithCSS", false, "true") before the tests but the expectations were generated with the flag off; only Firefox passes 82 of them (it ignores a command run while the document has no editing host), the 74 others fail in every browser (17 of them also expect <s> for strikethrough, 7 <p> separators); 17 other subtests expect <p> where the default paragraph separator is div ([["italic",""],["insertparagraph",""]] on foo[]bar expects <p>foo</p><p>bar</p>): the data was generated with defaultParagraphSeparator left to p by a previous group of tests; they fail in every browser |
run/outdent.html | Fail | 2,544 / 2,550 | BUG, TEST BUG | <blockquote><ol><li>foo<div><ol><li>[bar]</ol></div><li>baz</ol></blockquote> expects the three items in one list (<blockquote><ol><li>foo</li><li>bar</li><li>baz</li></ol></blockquote>), which is what the reference algorithm gives; the library gives <blockquote><div>foo</div><div><ol><li>bar</li></ol></div><ol><li>baz</li></ol></blockquote> (2 subtests, which fail in every browser too); 4 of the 6 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/removeformat.html | Fail | 1,831 / 1,832 | TEST BUG | the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/strikethrough.html | Fail | 2,123 / 2,147 | BUG, TEST BUG | 1 of the 24 failing subtests, that Chrome and Safari pass: foo<s>ba[r</s>b]az is expected to remove the decoration of the selected text (foo<s>ba</s>rbaz), the library extends the <s> to the text that follows (foo<s>barb</s>az), as the specification (the selection is not all struck through).; 19 subtests expect the output of one engine: Firefox (and for 2 of them Safari) merges the decorations in one declaration (foo<span style="text-decoration:underline line-through">bar</span>baz, 8 subtests), Chrome serializes text-decoration-line and rewrites <s style="text-decoration: underline"> as <u><strike> (9 subtests, e.g. fo<span style="text-decoration-line:line-through">obarb</span>az where the library serializes text-decoration:line-through), and 5 mix both and fail in every browser; 4 of the 24 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/subscript.html | Fail | 1,240 / 1,241 | TEST BUG | the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/superscript.html | Fail | 1,272 / 1,273 | TEST BUG | the first test expects queryCommandState("stylewithcss") to be false before its commands although the page runs execCommand("styleWithCSS", false, "true") before the tests: only Firefox passes (it ignores a command run while the document has no editing host), Chrome and Safari fail too |
run/typing-text-in-direct-child-of-editing-host.html | Pass | 16 / 16 | | |
run/underline.html | Fail | 2,136 / 2,147 | BUG, TEST BUG | 7 of the 11 failing subtests expect the new decoration to be combined with the one of the selected element in one declaration when styleWithCSS is on (foo<s>[bar]</s>baz expects foo<span style="text-decoration:underline line-through">bar</span>baz, the library gives foo<s><span style="text-decoration:underline">bar</span></s>baz), or the remaining part of a <u> to stay a <u> when the selection ends after it (foo<u>ba[r</u>]baz expects foo<u>ba</u>rbaz, the library recreates it as <span style="text-decoration:underline">, as it must for <u>foo[bar]baz</u> where the data expects spans): 1 passes in every browser, 1 in Firefox and Safari, 5 in Firefox only.; 4 of the 11 failing subtests come from the split in variants by subtest index (?1001-2000...): a variant starts in the middle of a test, after the subtests that call execCommand(), so the result and the states are checked on content that was never modified, and the next test expects the styleWithCSS/defaultParagraphSeparator state left by commands that the variant did not run; the first test of the file also expects styleWithCSS to be off although the page turns it on before the tests (most of them fail in Chrome and Safari too, and half of them in Firefox) |
run/undo-redo-after-mutation.html | Pass | 7 / 7 | | |
run/undo-redo.html | Pass | 69 / 69 | | |
run/unlink.html | Pass | 395 / 395 | | |
whitespaces/delete-chars-following-collapsible-white-space.html | Fail | 38 / 41 | BUG | 3 of 41 subtests, that only Firefox passes: when the last characters of a line that ends with a <br> are deleted after a space (<p>abc d[]<br></p> with Backspace, <p>abc def[]<br></p> with Ctrl+Backspace), the space that now ends the line becomes a no-break space before the <br> (<p>abc <br></p>, as in Chrome and Safari); the test accepts <p>abc <br></p> or <p>abc </p>. |
whitespaces/delete-last-word-in-inline-block-editing-host.html | Pass | 1 / 1 | | |
whitespaces/delete-word-around-span.html | Pass | 24 / 24 | | |
whitespaces/forwarddelete-chars-following-collapsible-white-space.html | Fail | 38 / 41 | BUG | 3 of 41 subtests, that only Firefox passes: when the last characters of a line that ends with a <br> are deleted after a space (<p>abc d[]<br></p> with Delete, <p>abc def[]<br></p> with Ctrl+Delete), the space that now ends the line becomes a no-break space before the <br> (<p>abc <br></p>, as in Chrome and Safari); the test accepts <p>abc <br></p> or <p>abc </p>. |
whitespaces/forwarddelete-word-around-span.html | Pass | 24 / 24 | | |
whitespaces/inserttext-at-end-of-block-when-br-always-block.html | Pass | 1 / 1 | | |
whitespaces/keep-collapsible-white-space-after-web-app-delete-padding-br.html | Pass | 4 / 4 | | |
whitespaces/keep-typed-collapsible-white-space-visible-after-muation.html | Pass | 2 / 2 | | |
Meziantou.Framework