1992288 - `TextEditor` becomes not available if reframing the text control in a `beforeinput`/`textInput` event listener

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Found while I investigating bug 1989331. If a beforeinput/textInput event listener reframes the text control frame, the TextEditor is destroyed. Then, the text control won't be reinitialized properly with new TextEditor. So, the text control can get focus but never work.

This is caused by the same root cause of bug 448784, bug 1339052 and bug1620050. We should keep using TextEditor in the TextControlState even after reframing.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1992288 - Make `AutoEditActionDataSetter` manage whether the destroyed editor was reinitialized r=m_kato!

Once the editor is destroyed while dispatching beforeinput event,
e.g., by a reframe of the text control frame, AutoEditActionDataSetter
marks "the editor has destroyed during my lifetime". Then, nested
EditActions always fail because the parent AutoEditActionDataSetter
thinks the editor is not available.

However, the editor can be reinitialized immediately. Then, the nested
EditActions should work (note that it does not mean that another user
input is handled, AutoEditActionDataSetter is used by some query
methods too). Therefore, this patch adds a new bool member to store
whether the editor is initialized again.

I think we could reset mEditorWasDestroyedDuringHandlingEditAction,
but I'm afraid to do that because it forgets the destroyed thing
completely and some features may need to abort handling something even
if the editor is restored since the editable nodes are recreated.
Therefore, this patch adds a new bool member for making this change
safer and anybody can access the details of the state.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5a9aae988c77
https://hg.mozilla.org/integration/autoland/rev/a085296be533
Make `AutoEditActionDataSetter` manage whether the destroyed editor was reinitialized r=m_kato

Comment 3

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/a085296be533

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1992288 - Make `AutoEditActionDataSetter` manage whether the destroyed editor was reinitialized

Once the editor is destroyed while dispatching beforeinput event,
e.g., by a reframe of the text control frame, AutoEditActionDataSetter
marks "the editor has destroyed during my lifetime". Then, nested
EditActions always fail because the parent AutoEditActionDataSetter
thinks the editor is not available.

However, the editor can be reinitialized immediately. Then, the nested
EditActions should work (note that it does not mean that another user
input is handled, AutoEditActionDataSetter is used by some query
methods too). Therefore, this patch adds a new bool member to store
whether the editor is initialized again.

I think we could reset mEditorWasDestroyedDuringHandlingEditAction,
but I'm afraid to do that because it forgets the destroyed thing
completely and some features may need to abort handling something even
if the editor is restored since the editable nodes are recreated.
Therefore, this patch adds a new bool member for making this change
safer and anybody can access the details of the state.

Original Revision: https://phabricator.services.mozilla.com/D271559

Comment 5

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56012 for changes under testing/web-platform/tests

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 7

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/728966a52d20
https://hg.mozilla.org/releases/mozilla-beta/rev/1adda1e095dd

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1992288 - Make `AutoEditActionDataSetter` manage whether the destroyed editor was reinitialized

Once the editor is destroyed while dispatching beforeinput event,
e.g., by a reframe of the text control frame, AutoEditActionDataSetter
marks "the editor has destroyed during my lifetime". Then, nested
EditActions always fail because the parent AutoEditActionDataSetter
thinks the editor is not available.

However, the editor can be reinitialized immediately. Then, the nested
EditActions should work (note that it does not mean that another user
input is handled, AutoEditActionDataSetter is used by some query
methods too). Therefore, this patch adds a new bool member to store
whether the editor is initialized again.

I think we could reset mEditorWasDestroyedDuringHandlingEditAction,
but I'm afraid to do that because it forgets the destroyed thing
completely and some features may need to abort handling something even
if the editor is restored since the editable nodes are recreated.
Therefore, this patch adds a new bool member for making this change
safer and anybody can access the details of the state.

Original Revision: https://phabricator.services.mozilla.com/D271559

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1992288 - Make `AutoEditActionDataSetter` manage whether the destroyed editor was reinitialized

Once the editor is destroyed while dispatching beforeinput event,
e.g., by a reframe of the text control frame, AutoEditActionDataSetter
marks "the editor has destroyed during my lifetime". Then, nested
EditActions always fail because the parent AutoEditActionDataSetter
thinks the editor is not available.

However, the editor can be reinitialized immediately. Then, the nested
EditActions should work (note that it does not mean that another user
input is handled, AutoEditActionDataSetter is used by some query
methods too). Therefore, this patch adds a new bool member to store
whether the editor is initialized again.

I think we could reset mEditorWasDestroyedDuringHandlingEditAction,
but I'm afraid to do that because it forgets the destroyed thing
completely and some features may need to abort handling something even
if the editor is restored since the editable nodes are recreated.
Therefore, this patch adds a new bool member for making this change
safer and anybody can access the details of the state.

Original Revision: https://phabricator.services.mozilla.com/D271559

Comment 10

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/e388bc1dec3c
https://hg.mozilla.org/releases/mozilla-release/rev/b5b23f020523

Comment 11

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/85c0ecb7431f