hasStrings for web

[justinmc]

Awhile back, I added the Clipboard.hasStrings platform channel method to all of our platforms, except web, in order to support showing the Paste button only when there was pasteable content on the clipboard. I couldn't just use getData because some platforms show a permissions dialog when accessing clipboard data directly. Instead, those platforms offer alternative methods that just check whether there is some text on the clipboard, but don't actual read it.

At the time, I did not implement hasStrings for web because the web didn't use Flutter's context menu, so there was never a Paste button to show. That changed with #38682, which offers a way to disable the browser's built-in context menu.

Now if you disable the browser's context menu on web and use the Flutter-rendered context menu, the paste button will just never show up (flutter/flutter#129692). So I set out in this PR to add hasStrings to web and fix that issue.

Flutter web by default	Flutter web with browser context menu disabled and this PR applied

The problem

It turns out that there is no hasStrings-like method in the browser's clipboard API, but at least on Chrome, it still shows a permission notification when getData is accessed!

Solution 1: Do nothing

Close this PR. The paste button will never show on web when the built-in context menu is disabled. But really, that menu is not exactly meant to work out of the box for web. Concerned app developers can implement their own custom context menu for their web app and do whatever behavior they want.

Solution 2: Ignore hasStrings on web

Also close this PR, and in the framework, just ignore the result of hasStrings on web. The paste button will always appear. If it's pressed when there is no string available, it will just not paste anything. It's easy for app developers to change this behavior if they want.

Solution 3: Merge this PR

All Flutter web apps that disable the browser's context menu and don't implement their own custom context menu will show the above notification the first time it is run. If a user selects "allow", the paste button will appear only when there is something on the clipboard. If they select "block", the paste button will never appear. It's still easy for app developers to change this behavior if they want.

Resources

Fixes flutter/flutter#129692

@yjbanov @mdebbar I'm interested in your thoughts!

[yjbanov]

I think it is expected behavior that when custom menus are used the browser will pop-up a permissions dialog. What may be surprising is if this becomes the default behavior on the web.

Perhaps what we're struggling with is we want one concept of a context menu and we want it to work in all situations. I wonder if instead it makes sense to formalize the concepts of "platform context menu" and "custom context menu" at the framework level. By default the framework would choose the most appropriate strategy for the platform, but the developer may override based on their app's needs (e.g. Google Docs chooses to ask for permissions and use custom menus). On the web, the default would be the "platform context menu" that does not require permissions or attempt to access the Clipboard API. Other platforms may choose a different default. This is similar to how focus traversal works. On the web, when you reach the last focusable widget on the page, the next TAB will take you out of the page and into browser UI (back button, address bar, etc). But on other platforms there's no "browser UI", the Flutter app is the full app, and the focus traversal must stay within the app (but also customizable by the developer).

[mdebbar]

@justinmc, sorry for the very late review.

My general approach is to try to minimize requests for user's permission, especially for widgets readily available by the framework. App developers may be unaware that their use of such widget causes a permission dialog to popup on their web app.

Based on that, I have a few suggestions:

1. Any widgets or helpers that directly or indirectly use hasStrings should explicitly state that, on the web, they may result in a permission dialog showing up.
2. Avoid calling hasStrings on common code paths. If, for example, a widely used widget requires access to hasString, consider adding a {bool requestWebClipboardPermission = false} property to the widget. This way, only developers who really want the permission dialog to show up would set this property to true.
3. When permission is denied by the user, handle it gracefully by returning false from hasStrings.

[justinmc]

Thanks for your input @mdebbar and @yjbanov! I think we should do the following:

1. Disable hasStrings for web in the framework by default (Handle hasStrings on web flutter#132093).
2. Merge this PR second. No one will get the permissions dialog on app start unless they choose to after this PR is merged.

The resulting behavior will be that on web by default, the paste button will always be shown, even when there is nothing to paste on the clipboard. Pressing paste for the first time will show the permissions dialog. Doing so with nothing on the clipboard will just paste nothing (default behavior on the non-Flutter web already).

If a user wants to change the behavior by using hasStrings on web, that can do so by writing their own context menu. If this ends up being popular, I can make it easier by adding a parameter as suggested above, but I won't plan to for now.

If this plan sounds good, I'd appreciate a review here and on flutter/flutter#132093 please!

[mdebbar]

The app is only checking whether the clipboard contains strings, it's not doing a paste. This error is going to be confusing in that case. It basically says that the "paste" operation has failed.

I suggest that we fail silently here and just return false to the hasStrings call. This covers the case when the user denies clipboard permission, in which case we should tell the app that there are no strings in the clipboard (basically treat the clipboard as if it were empty).

[justinmc]

Good call! Fixed and added a test.

[mdebbar]