Closed Bug 1816039 Opened 1 year ago Closed 1 year ago

Fix the failure of web-platform/tests/inert/inert-and-contenteditable.html

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

defect

Tracking

()

RESOLVED FIXED
112 Branch
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.

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().

Oddly, it passes without WPT test harness...
https://jsfiddle.net/d_toybox/qrab129c/3/

Ah, okay, I can reproduce it with this:
https://jsfiddle.net/d_toybox/qrab129c/4/

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.

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

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).

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(masayuki) → needinfo?(emilio)

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.

Flags: needinfo?(emilio)

(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.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: