In the most cases, the new behavior works fine. On the other hand, we need feedback from wider testers because web apps which are major product but instantiated in any servers cannot be fall it back to the traditional behavior with the blocklist per domain pref nor even if we shipped new API to opt-out from the new behavior with Origin Trials. Therefore, we may need hack for such applications like bug1514940 in the worst cases. Getting bug reports of this kind of web apps gives chance to add such hack before shipping in release builds. Therefore, I don't like to make it ride the train immediately.

Enabling the new behavior causes a lot of unexpected-passes in WPT. However, in my understanding, we don't have a way to change expected result in the ini files of WPT with referring a pref value. So, do we need to enable the pref in all release channels in this case?

Checking new result after enabling the new behavior...
https://treeherder.mozilla.org/jobs?repo=try&revision=53a002c65810f51b977d2f3b7ba4ee51bbc11a2e

(I hope new unexpected failure will appear...)

You can either enable the pref everywhere in the wpt metadata files, or make the results depend on if not eary_beta_or_earlier, depending on how important it is to test the pref-off behaviour on other channels. In this case I guess the latter makes more sense?

Thank you, yeah, the latter is better because the tests are imporant for both modes.

Actually, I see new failures in the new behavior mode. I need to fix them first.

For collecting more feedback from testers, let's enable the new and better
join-split node direction in the Nightly channel and early beta builds.
One of the main purposes of this change is, if we get feedback of some intranet
web apps which are instantiated in local servers, we can write a hack like
bug 1514940 before shipping the release since the block-list per domain cannot
support such apps.

I'll write "intent to ship" post before landing.

The Intent to Ship post: https://groups.google.com/a/mozilla.org/g/dev-platform/c/Ob-T1HSe-4I

https://hg.mozilla.org/mozilla-central/rev/8cb18a317ce4

Is this something we should call out in the Fx113 Nightly relnotes?

Yes, of course! I'll request it with suggesting the words.

Release Note Request (optional, but appreciated)
[Why is this notable]: This is one of the biggest basic editor behavior changes.
[Affects Firefox for Android]: Yes.
[Suggested wording]:
Starting from Firefox 113 (currently only in the Nightly channel or early beta builds), the builtin editor behaves similar to the other browsers when splitting a node (e.g., typing Enter to split a paragraph) and joining two nodes (e.g., typing Backspace at start of a paragraph to join the paragraph and the previous one). When a node is split, builtin editor creates new node after the original one, i.e., creates the right node. Similarly, when two nodes are joined, the builtin editor deletes the latter node and move its children to end of the preceding node.

This new behavior can be enabled by web apps themselves in all channels with a call of document.execCommand("enableCompatibleJoinSplitDirection", false, "false") (introduced in bug 1810663). This command is available only when designMode is set to "on" or there is at least one editable element which has contenteditable attribute, and the builtin editor has not handled insertParagraph, delete nor forwardDelete command.
[Links (documentation, blog post, etc)]:
No documentation, no blog post, unfortunately.

I've added the note to the Fx113 Nightly relnotes but do not plan to move it as-is to the Beta/Release notes once it rides the trains. Though maybe we'll still want to call out the second half of the note where sites can opt in to the new behavior if they want? With a note that it will become the default behavior in a later release?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #13)

Though maybe we'll still want to call out the second half of the note where sites can opt in to the new behavior if they want?

Right.

With a note that it will become the default behavior in a later release?

Yeah, hopefully after testing in the Nightly channel and early beta builds in a couple of cycles. (Not yet fixed the schedule.)

this is riding the trains in 115 with bug 1735608 and the relnote+ is added there