For an easy solution for web apps which are broken by switching the split/join node direction in bug 1735608, we should provide new Gecko specific command to opt-in/out the new behavior. E.g.,

document.execCommand("enableLegacyJoinSplitDirection", false, "true");

Should take the legacy join/split node direction back if the editor does not have related undo/redo transactions yet.

And also

document.execCommand("enableLegacyJoinSplitDirection", false, "false");

Should enable the new behavior (compatible with the other browsers) even before shipping the new behavior by default.

Currently, I'm thinking this as:

For opt-in to new behavior (compatible with the other browsers), I believe that there should be new Gecko specific command to enable it such as:

document.execCommand("enableCompatibleJoinSplitDirection", false, "true");

This works only when there is no transaction which uses join/split nodes. The merits of this API is, web app developers can ship their products in their schedules (i.e., even if we fail to ship the new behavior by default in some release cycles, they can keep using the new behavior in their products. Additionally, even if web developers use some test frameworks which can run browsers only in release channels within the default settings, they can test Firefox with this API.

However, we (especially I) don't want to keep maintaining the legacy join/split node direction mode. Therefore, using Origin Trials is more reasonable than creating new (public) API to opt-out from the new behavior even after shipping it.

(I'll ask this in #standards)

Oh, one of the motivation of adding API to opt-out from the new (cross-browser) behavior is, the API works with intranet applications which are instantiated in local web server of the organization.

Emilio: Is it suitable to use origin trials for this purpose? In my understanding, each organization needs to raises their hand for using opt-out feature if we use origin-trials.

Opt-in to new behavior API:
https://treeherder.mozilla.org/jobs?repo=try&revision=da04f5d0fcbff3e0b094e24d15214236dc888eb7

Yes, that's called a reverse origin trial and might be reasonable to use for this kind of case.

That way if nobody requests an origin trial for that feature we could remove it eventually even.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Yes, that's called a reverse origin trial and might be reasonable to use for this kind of case.

That way if nobody requests an origin trial for that feature we could remove it eventually even.

Just a confirmation, if the intranet app vendor requests to use the opt-out from the new behavior API, it works in any domains/IP addresses owned by each customer of the product? It's just checked the token ID without checking the running domain etc? (I'm confused at the meaning of "origin"?)

No, the origin needs to be in the token, and we check it. We have support for subdomain wildcards tho.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

No, the origin needs to be in the token, and we check it. We have support for subdomain wildcards tho.

Oh, thanks, it's bad for my scenario. Then, we need to expose new API if we need...

Perhaps, for now, we should just provide API for opt-in to the new feature.

This API is temporarily available and useful for web app developers who want to
stop supporting Gecko specific join/split direction handling as soon as possible
and who do not want Mozilla block their release schedule by rescheduling of
shipping the new behavior. Additionally, adding this command allows web apps
detects whether Gecko supports the new behavior and whether it's enabled.

On the other hand, We don't want to ship opt-out API because it's hard to keep
maintaining the legacy behavior specific paths. Therefore, the command does
nothing if web app calls
Document.execCommand("enableLegacyJoinSplitDirection", false "true") if the
new behavior is enabled by default.

If we add a web-exposed API that we intend to be temporary, I think we should communicate a timeline for removing the API again and log in devtools console when it's used for enabling the legacy behavior. And then actually remove it when we say we would.

(In reply to Simon Pieters [:zcorpan] from comment #9)

I think we should communicate a timeline for removing the API again and log in devtools console when it's used for enabling the legacy behavior.

No, the API cannot enable the legacy behavior once the new behavior is enabled by default. Therefore, we don't need to remove it except code clean up because it can be useful for "feature detection".

So the plan is to ship an opt-in to the new behavior for some time, and then remove it again when we ship the new behavior on by default?

(In reply to Simon Pieters [:zcorpan] from comment #11)

So the plan is to ship an opt-in to the new behavior for some time, and then remove it again when we ship the new behavior on by default?

If it'd be possible. However, the API can be used as feature detection, so, we need to be careful for removing it. (I think it's the best that returning fixed value even after we ship the new behavior without doing nothing.)

This API is temporarily available and useful for web app developers who want to
stop supporting Gecko specific join/split direction handling as soon as possible
and who do not want Mozilla block their release schedule by rescheduling of
shipping the new behavior. Additionally, adding this command allows web apps
detects whether Gecko supports the new behavior and whether it's enabled.

On the other hand, We don't want to ship opt-out API because it's hard to keep
maintaining the legacy behavior specific paths. Therefore, the command does
nothing if web app calls
Document.execCommand("enableCompatibleJoinSplitDirection", false "false") if
the new behavior is enabled by default.

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/6b2a01cfda34