Intent to Ship: Compatible join and split node direction in HTML editor

[Masayuki Nakano]

Summary:

Gecko is the only browser engine which joins 2 nodes with deleting left node at deleting an element boundary and creates left node at splitting a node e.g., at inserting new paragraph. I.e., the other browser engines (including Trident) join 2 nodes with deleting right node and create right node at splitting a node. This may cause making web developers need to create Firefox specific path in complicated editable applications, and making it impossible to support Firefox in some cases. Therefore, I've worked on fixing this over a year in over 40 bugs, with changing over 10,000 lines even only in editor/libeditor (+18,711/-12,930, excluding some refactoring which do not directly required).

Fortunately, there is no notable open issue even after Foxfooding. Therefore, I'd like to enable this new behavior by default in the Nightly channel and early beta builds to get feedback from wider testers, especially about intranet applications which can be instantiated in local web servers.

Additionally, I'll land new Gecko specific editing command for enabling the new compatible behavior even before shipping it and for making it can check whether it's the version of Firefox supports the new behavior. (Note that the command cannot disable the new compatible behavior if it's enabled by the pref, thus, I plan to remove the legacy behavior as soon as possible after shipping it due to the maintenance cost.)

Bugs:

• Bug 1820116 - Enable new join/split direction by default in the Nightly channel and early beta builds
• Bug 1810663 - Add new Gecko specific `execCommand` to opt-in to the new split/join node direction

Standard:

Not defined in any specs, but some WPTs depend on the new behavior

Preferences:

• editor.join_split_direction.compatible_with_the_other_browsers (enable/disable the new behavior)
  
• editor.join_split_direction.force_use_traditional_direction (allowed list of the legacy behavior, currently empty)
  
• editor.join_split_direction.force_use_compatible_direction (allowed list of the new behavior, currently empty)

DevTools:

N/A

Platform coverage:

All, and affecting Thunderbird

Other browsers:

Only supports the new behavior, and do not (and must be never) support the command.

web-platform-tests:

https://searchfox.org/mozilla-central/source/testing/web-platform/tests/editing (and see also new passing tests after enabling the pref)

-- 
Masayuki Nakano <masa...@d-toybox.com>
Working on DOM, Events, editor and IME handling for Gecko

[Masayuki Nakano]

On 23/03/20 9:50, Masayuki Nakano wrote:

Additionally, I'll land new Gecko specific editing command for enabling the new compatible behavior even before shipping it and for making it can check whether it's the version of Firefox supports the new behavior. (Note that the command cannot disable the new compatible behavior if it's enabled by the pref, thus, I plan to remove the legacy behavior as soon as possible after shipping it due to the maintenance cost.)

About the new command, I post this separately.

Web apps can enable the new behavior with a call of:

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

This is available when the document is in the design mode or has at least one element which has contenteditable attribute whose value is not "false" and first joining nodes or split node transaction is created. The latter limitation is caused by saving the footprint with not storing the join/split node direction per transaction.

Additionally, once the new behavior is enabled by the pref, web apps cannot disable the new behavior with calling it with "false". The reason is, it's too expensive and hard to support both behavior forever (actually, I created some regressions in a couple of months only in the new behavior mode). Therefore, we need to know that which web apps work only with the legacy behavior.

To detect Firefox which do not support the new compatible behavior, web apps can check the result of the above call or:

document.queryCommandState("enableCompatibleJoinSplitDirection")

with checking the UA is Firefox since the other browsers do not support this Gecko specific command. Therefore, they return false for these calls.

Once we ship the new behavior by default in all channels, we can just make Document return true with nothing to do. (Without evidence of that no web apps use these commands, we cannot remove this new command, unfortunately.)

Since editable apps do not depend on all editing features of browsers, web apps maybe can use the new behavior even before we ship the new behavior in all channels. Therefore, I believe that this new command is useful for web developers.

[ISHIKAWA,chiaki]

Masayuki san,

Thank you for the great improvement.

Just a short question.

I suspect it affects the composition in C-C TB, correct?

How can we enable this new feature for early testing in C-C TB?
(I am locally creating patches and testing by using TB's C-C source tree.)
Do we have to enabble "editor.join_split_direction.compatible_with_the_other_browsers" in the config of TB?

Thank you in advance for your attention.



Chiaki Ishikawa







[Masayuki Nakano]

Hi,

On 23/03/21 3:32, ISHIKAWA,chiaki wrote:

I suspect it affects the composition in C-C TB, correct?

Right.

How can we enable this new feature for early testing in C-C TB?

You can enable it with setting the pref, editor.join_split_direction.compatible_with_the_other_browsers, to true. The pref is already available in any channels (but I think that it's a little bit broken in 111 and earlier).

(I am locally creating patches and testing by using TB's C-C source tree.)
Do we have to enabble "editor.join_split_direction.compatible_with_the_other_browsers" in the config of TB?


No, it'll be enabled in the default settings of Gecko. Unless Thunderbird disables it explicitly, it'll be enabled automatically. Of course, it's not recommended because the legacy mode won't be supported unless we would get bug reports of broken web apps by the change.

[ISHIKAWA,chiaki]

I see thank you. I will monitor mochitest results, especially warnings produced during edit-related operations.
I still see many mysterious warnings in the local log of mochitest when I run it with DEBUG version of C-C TB.
Hopefully, either some of them will disappear or new ones may crop up.
I will report any anomalies to the list or in bugzilla.

Thank you again for improving the compatibility with other browsers.

Chiaki Ishikawa