Disallow navigating away from custom editors when retainContextWhenHidden is false and the backup has yet to run orfailed

[Tyriar]

Repro 1 (backup not yet run):

1. Create a custom editor extension that uses retainContextWhenHidden: false (the default)
2. Make some change that triggers a CustomDocumentEditEvent
3. Switch to another tab immediately (before backup runs)
4. Switch back

Repro 2 (backup failed):

1. Create a custom editor extension that uses retainContextWhenHidden: false (the default)
2. Make some change in the custom editor which caused an error to be thrown in CustomEditorProvider.backupCustomDocument
3. Switch to another tab
4. Switch back

The custom editor provider will have no option but to load the last known backup or from disk, which differs from the previous state. Resulting in data loss ☹️

For repro 1 #113507 would be ideal, but tab switching should be blocked and a backupCustomDocument request issued immediately (allow maybe ~1 second for it to compete?). For repro 2, navigating away from the tab should be blocked with a dialog to save, don't save or cancel.

[mjbvz]

In both cases, shouldn't your extension's custom document (the one in the extension host) be up to date? When you then switch back to the custom editor tab, we should try to use the existing document instead of trying to load a new one from backup

Maybe I'm misunderstanding the exact scenario though

[Tyriar]

You have more info on this now but to clarify the problem I face:

I want to support things like editing 10000x10000+ files, each layer for such a file will be around 400mb of array buffer data. Currently the editing of such a file works fine, but I was forced to disable hot exit because transferring data for a file of this size takes 20+ seconds. I can cut that down a good chunk by encoding the array buffer into a string (since postMessage doesn't support ArrayBuffers #79257), but it's still really slow.

You're right that I should probably be updating the custom document on every change, rather than just on backup, but it's impossible right now because of this limitation of postMessage blocking the main thread as it freezes the entire webview.

Also you may say 10000x10000 is a lot, but this blocking of the webview is unacceptable even on images as small as 500x500. Any blocking of the main thread is unacceptable especially when drawing an image as pointer events will get lost which means straight jagged lines instead of smoothly following the cursor. See below the gif of a 500x500 image and drawing 2 lines, half way through the second line is when the backup occurs:

To sum up things that would help this situation:

• Giving extensions more control over when the context goes away. If I know that the webview is in the background, I can safely force a backup which will freeze the webview as it's not user visible (this issue and Let custom editors retain context and shut them down only after inactivity or memory pressure #113507).
• Support web workers in the webview. With this I could encode/compress data via SABs without any impact on the webview's responsiveness before sending to the ext host (Support web workers in webviews #87282).
• Support postMessage to the extension host inside a webview web worker. This would be fantastic if possible and would let me enable hot exit/continuous backups for the majority of cases.
• Support efficiently posting ArrayBuffers in postMessage Support transferables in webview postMessage #115411