Fix the failure of web-platform/tests/inert/inert-and-contenteditable.html
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox112 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
It's caused by perhaps differences of focus handling at changing Selection
from a contenteditable
element to outside of it.
Updated•1 year ago
|
Assignee | ||
Comment 1•1 year ago
|
||
Hmm, it's not caused by Selection
behavior difference because porting our Selection
behavior tests to public WPTs do not cause failures in Chrome around Selection.collapse()
.
Assignee | ||
Comment 2•1 year ago
|
||
Oddly, it passes without WPT test harness...
https://jsfiddle.net/d_toybox/qrab129c/3/
Assignee | ||
Comment 3•1 year ago
|
||
Ah, okay, I can reproduce it with this:
https://jsfiddle.net/d_toybox/qrab129c/4/
Assignee | ||
Comment 4•1 year ago
|
||
Both Chrome and Safari reject execCommand
when Selection
is collapsed in inert
attributed element. However, Gecko does not take care. Let's follow the other browsers behavior.
Assignee | ||
Comment 5•1 year ago
|
||
According to the WPTs and their result in the other browsers, we should:
- do not work with a range anchored from a node in an element which has
inert
. - collapse the range first when it ends at a node in an element which has
inert
.
See new WPT for the detail.
Note that inert
with contenteditable
must not be so major cases. Therefore,
this patch does not fix the edge cases like the nsFrameSelection
use cases
and replacing Selection
cases of the other edit commands/operations.
Depends on D169037
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/e91291cda07a Make `HTMLEditor` handle selection ranges which starts from or ends in `<foo inert>` r=m_kato
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/38533 for changes under testing/web-platform/tests
Comment 8•1 year ago
|
||
Curious, why walking the whole ancestor chain instead of checking the style of the element which should have the right inertness?
There can be non-inert elements inside inert elements (like a modal dialog).
Assignee | ||
Comment 9•1 year ago
|
||
Since I find only setter here:
https://searchfox.org/mozilla-central/rev/84fb1c4511312a0b9187f647d90059e3a6dd27f8/dom/html/nsGenericHTMLElement.cpp#718
In my understanding, the state is set in only the element which has inert
attribute. Is there better API to get it?
There can be non-inert elements inside inert elements (like a modal dialog).
That's good to know although I guess such content is not in contenteditable though.
Ah, is it nsStyleUI::IsInert
? Is it safe to use without flushing layout? Although it's currently called very start of handling, so editor can flush layout at that time though.
Comment 10•1 year ago
|
||
Yeah, exactly, nsStyleUI::IsInert
is the thing to check. That said I'm not sure when the editor deals with style... How do you deal with e.g. user-select
? In general you need to ensure you've flushed style/frames at least.
Assignee | ||
Comment 11•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
Yeah, exactly,
nsStyleUI::IsInert
is the thing to check.
Thank you. I'll file a bug and post a patch for it.
That said I'm not sure when the editor deals with style...
Currently, editor flushes layout when it needs to do it. However, I plan to block running script between beforeinput
and input
in the future. Therefore, I'd like to not flush pending selections in deep point of editor module because flushing pending layout is not allowed while script runner is there.
How do you deal with e.g.
user-select
? In general you need to ensure you've flushed style/frames at least.
user-select
is not handled in editor now because editor was designed before it's standardized. Perhaps, there are tons of bugs if you try to write tests.
Comment 12•1 year ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Description
•