Potential workaround (which I'm also going to see if I can use as the basis for the mobile tryTeardown internals): still call tryTeardown, but rather than using its promise-return, just listen for the teardown event from the target/surface.

In T406738#11255951, @DLynch wrote:

Potential workaround (which I'm also going to see if I can use as the basis for the mobile tryTeardown internals): still call tryTeardown, but rather than using its promise-return, just listen for the teardown event from the target/surface.

Thanks, this mostly unblocks us for the case where the user actually closes the editor.
However, this still does leave an edge case:

1. on mobile
2. when the user ignored the revise tone dialog for a moment and edited the article
3. and then declines that initial dialog
4. and then is prompted whether they want to discard their changes
5. and then chooses to keep editing
6. and then saves their edit
7. then our cancellation-related callback that we registered for the teardown in step 3 is still firing

We can probably work around this by also listening for a save-hook and when that fires we can un-register the teardown hook, but that is a lot of complexity for what should be just reacting to a resolved promise and ignoring a rejected one.

Change #1195040 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] MobileArticleTarget.tryTeardown should return a promise

https://gerrit.wikimedia.org/r/1195040

That patch does it based on some detailed internal knowledge of exactly what the EditorOverlay is going to do, so it shouldn't be vulnerable to an error like the teardown handler sticking around. (The most likely thing that could go wrong if I missed a case somewhere would be that the promise might fail to be rejected if the user decides to not abandon their changes.)

Change #1195040 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] MobileArticleTarget.tryTeardown should return a promise

https://gerrit.wikimedia.org/r/1195040