Created attachment 459689 [details] repro case See attached test case. WebKit has an odd behavior where if you try to `insertText` into a contenteditable display:none element, it rejects the editing command, but if you try to do the same into a *child* of the contenteditable display:none element, it works. *Also* interestingly, while the other browser engines behave internally consistently, they do not agree about the correct behavior: Blink rejects the editing command in both cases. Gecko allows the editing command in both cases.
I believe the root of the inconsistency in WebKit is the `display: none` check in computeEditabilityFromComputedStyle, which only checks the style of the immediate starting node, not whether or not you're in a `display: none` subtree. However, I'm not sure which of the more-consistent behaviors to align us with :)
I *think* that Antti introduced this in https://trac.webkit.org/changeset/160966/webkit
https://bugs.webkit.org/show_bug.cgi?id=133371 suggests that display:none things should be editable. Humorously, while https://trac.webkit.org/changeset/160966/webkit progressed bug 133371 in the case where you're querying isContentEditable on a child of the display:hidden element, it still says NO if you query *exactly* the display:hidden element. Also, both Chrome and Firefox say isContentEditable=true for all elements (the direct display:none element and the children). I believe that the fact that Chrome doesn't allow editing in my original test case does not have to do with editability, but rather with selection behavior in display:none, so not necessarily related to this bug. All of this together, plus the fact that changing this only affects a single test, makes me think that aligning on the Firefox behavior is the way to go. I'm going to prepare a patch to do so. Please shout if you disagree!
display:none shouldn't affect the result of isContentEditable but I don't think the rest of editing code can deal with the display:none content. If there aren't any editing tests that rely on this, then either approach sounds okay for now.
Pull request: https://github.com/WebKit/WebKit/pull/964
Committed r294753 (250921@main): <https://commits.webkit.org/250921@main> Reviewed commits have been landed. Closing PR #964 and removing active labels.
<rdar://problem/93843189>