| Summary: | Confusing inconsistencies when programmatically applying edit commands to `display:none` elements | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Tim Horton <thorton> | ||||
| Component: | HTML Editing | Assignee: | Tim Horton <thorton> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap, koivisto, ntim, rniwa, webkit-bug-importer, wenson_hsieh | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
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. |
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.