feat: route deprecated sync clipboard read through permission checks

[deepak1556]

Description of Change

Follow-up to #45277 that makes the feature opt-in behind permission checks to provide a transition period for users.

All the feature related properties and methods are marked deprecated on purpose to hint that this is will removed at some point.

1. enableDeprecatedPaste webpreference will enable support for the permission checks of document.executeCommand("paste")
2. Any invocation of the command will trigger session.permissionCheckHandler with type deprecated-sync-clipboard-read
3. Permission check will not be triggered if there was a recent user interaction since the last permission request was responded. What counts as user interaction relies on https://source.chromium.org/chromium/chromium/src/+/main:content/browser/web_contents/web_contents_impl.h;l=2335-2340. This is based on what is done today for the async clipboard checks https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/chrome_content_browser_client.cc;l=7652-7672

Release Notes

Notes: Add permission support for document.executeCommand("paste")

[erickzhao]

Can we put an explicit version timeline for deprecation before landing this?

[deepak1556]

Can we put an explicit version timeline for deprecation before landing this?

Yes that is something I would like to discuss in this PR. Do we match Chrome and keep the API supported till it gets removed from upstream ? Or is there are Electron specific timeline we want to pursue ?

[MarshallOfSound]

API LGTM

Consider this approved from my API / security perspective, I'll leave in depth code review to other folks.

RE removal timeline, I'd like to get rid of this before Chrome does but I'm open to that timeline being dictated by your migration timeline @deepak1556

[pushkin-]

Would you consider a similar opt out for document.execCommand("copy") since this also appears to be "broken" after #45277

[deepak1556]

@pushkin- can you share example of what is broken with copy ? Unlike the paste command which was disabled completely the copy/cut commands rely on the transient activation state similar to browsers as long as a command is executed with the expected time span of user activation which is set to 5 seconds they should work.

[pushkin-]

@deepak1556 I believe that AllowWriteToClipboard was returning false if I remember correctly. Before, I could execute document.execCommand("copy")in one window while focused in another. Now, I have to be focused in the same window. This requires patching up a number of different places in our code to execute that command on the focused window.

Ultimately, it's an issue with our code, but it's something that used to work, and now broke with the 33.3.2 patch. See discussion here #45144

[deepak1556]

I believe that AllowWriteToClipboard was returning false if I remember correctly

That is correct, however the change from 7ecb8ad does not completely block the cut/copy feature as long as you are focused on the window that needs to execute the action which shouldn't be a breaking change for most apps out there.

I will keep this PR focused on the paste command that actually needs an opt-in to allows apps have a reasonable timeline to migrate.

[codebytere]

API LGTM

[release-clerk]

Release Notes Persisted

Add permission support for document.executeCommand("paste")

[trop]

I was unable to backport this PR to "34-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I was unable to backport this PR to "33-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "35-x-y", please check out #45471

[trop]

@deepak1556 has manually backported this PR to "34-x-y", please check out #45472

[trop]

@deepak1556 has manually backported this PR to "33-x-y", please check out #45473