This is failing also in windows, and I'm getting similar results with chromium, so it seems the test depends on mac specific behavior. This is what the test does: document.body.focus(); document.execCommand("InsertHTML", true, "<img></img>"); document.execCommand("SelectAll"); document.execCommand("Underline"); document.execCommand("InsertText", true, "foo"); document.body.textContent = `The underlined text should be 'foo': '${document.querySelector("U").textContent}'`; The difference is when executing Underline command. In mac at that point an empty <u></u> is added, so next command is adding foo inside the <u></u>. But that's not happening in GTK+, Underline command is not modifying the tree (I guess because it's applied to the selection that is considered empty), so next command just inserts the text replacing the selection (img). The result is an exception because querySelector returns null. CONSOLE MESSAGE: line 12: TypeError: null is not an object (evaluating 'document.querySelector("U").textContent')
Thank you for reporting this! If it's okay with you, perhaps we should skip the test on the non-Cocoa platforms? Alternately, since this test was originally just checking that we don't hit a debug assertion, I could relax the requirements for this test and just check that textContent is "foo" at the end, instead of requiring an underline. > But that's not happening in GTK+, Underline command is not modifying the > tree (I guess because it's applied to the selection that is considered > empty), so next command just inserts the text replacing the selection (img). Interesting...does the "Underline" command here have no effect, or is it that the command applies an inline text decoration style rather than wrapping the selection in an underline tag? If it's the latter, I can fix this test by examining the computed style of the text node "foo" for a text decoration.
(In reply to Wenson Hsieh from comment #1) > Thank you for reporting this! If it's okay with you, perhaps we should skip > the test on the non-Cocoa platforms? I marked it as failure on GTK+ already. > Alternately, since this test was originally just checking that we don't hit > a debug assertion, I could relax the requirements for this test and just > check that textContent is "foo" at the end, instead of requiring an > underline. That would work I think, let me know if you want me to try any patch. > > But that's not happening in GTK+, Underline command is not modifying the > > tree (I guess because it's applied to the selection that is considered > > empty), so next command just inserts the text replacing the selection (img). > > Interesting...does the "Underline" command here have no effect, or is it > that the command applies an inline text decoration style rather than > wrapping the selection in an underline tag? If it's the latter, I can fix > this test by examining the computed style of the text node "foo" for a text > decoration. I think it doesn't have effect, because foo is not underlined. I think it's because it's applied to the selection that is later replaced by the text, but I'm not sure.
This is a difference between Mac & non-Mac editing behavior. On Mac, underline is considered present if the beginning of the selection as underline. On Linux & Windows, underline is considered present only if the entire selection is underlined. You can probably fix this by forcing the Mac editing behavior in the test.