Closed Bug 1776829 Opened 2 years ago Closed 2 years ago

Considering clipboard access permission API for clipboard.readText()

Categories

(GeckoView :: Permissions, enhancement, P1)

enhancement

Tracking

(firefox104 wontfix, firefox105 wontfix, firefox106 fixed)

RESOLVED FIXED
106 Branch
Tracking Status
firefox104 --- wontfix
firefox105 --- wontfix
firefox106 --- fixed

People

(Reporter: mbrodesser-Igalia, Assigned: m_kato)

References

(Blocks 1 open bug)

Details

(Whiteboard: [geckoview:m104] [geckoview:m105] [geckoview:m106])

Attachments

(1 file)

No description provided.

Gave it a try with current Nightly on my Android phone: https://jsfiddle.net/68hng59s/.

No "Paste" button appeared, the jsfiddle's console didn't show any error message.

No "Paste" button appearing is expected, because Android doesn't know how to deal with <menupopup>.

Severity: -- → N/A

XUL popup won't work on GeckoView. I think that GeckoView has to add anything permission API in GeckoSession.PermissionDelegate. PERMISSION_CLIPBOARD_READTEXT_PASTE?

(In reply to Makoto Kato [:m_kato] from comment #3)

XUL popup won't work on GeckoView. I think that GeckoView has to add anything permission API in GeckoSession.PermissionDelegate. PERMISSION_CLIPBOARD_READTEXT_PASTE?

Thanks for the response. AFAIU, GeckoView (GV) is a layer between Gecko and Fenix. Would additional changes in GV and Fenix be required to support this?

GeckoSession.PermissionDelegate might not be what's desired here, given that on Desktop, deliberately a "Paste" button instead of a permission dialog (e.g. like for GeoLocation requests) is shown. @csadilek: are there reasons to do this differently on Android?

Any context here is appreciated, I know little above GV and Fenix.

Flags: needinfo?(csadilek)

(In reply to Mirko Brodesser (:mbrodesser) from comment #4)

(In reply to Makoto Kato [:m_kato] from comment #3)

XUL popup won't work on GeckoView. I think that GeckoView has to add anything permission API in GeckoSession.PermissionDelegate. PERMISSION_CLIPBOARD_READTEXT_PASTE?

Thanks for the response. AFAIU, GeckoView (GV) is a layer between Gecko and Fenix. Would additional changes in GV and Fenix be required to support this?

Yes, If GeckoView need additional UX such as permission and popup/prompt, we will delegate this action to Fenix/Android-Component (a-c). Mostly, it is implemented by a-c.

GeckoSession.PermissionDelegate might not be what's desired here, given that on Desktop, deliberately a "Paste" button instead of a permission dialog (e.g. like for GeoLocation requests) is shown. @csadilek: are there reasons to do this differently on Android?

Any context here is appreciated, I know little above GV and Fenix.

Why doesn't we use nsIContentPermissionPrompt like other permissions? Doesn't UX team want doorhanger notification for this permission?

Flags: needinfo?(mbrodesser)

(In reply to Makoto Kato [:m_kato] from comment #5)

(In reply to Mirko Brodesser (:mbrodesser) from comment #4)

(In reply to Makoto Kato [:m_kato] from comment #3)

XUL popup won't work on GeckoView. I think that GeckoView has to add anything permission API in GeckoSession.PermissionDelegate. PERMISSION_CLIPBOARD_READTEXT_PASTE?

Thanks for the response. AFAIU, GeckoView (GV) is a layer between Gecko and Fenix. Would additional changes in GV and Fenix be required to support this?

Yes, If GeckoView need additional UX such as permission and popup/prompt, we will delegate this action to Fenix/Android-Component (a-c). Mostly, it is implemented by a-c.

GeckoSession.PermissionDelegate might not be what's desired here, given that on Desktop, deliberately a "Paste" button instead of a permission dialog (e.g. like for GeoLocation requests) is shown. @csadilek: are there reasons to do this differently on Android?

Any context here is appreciated, I know little above GV and Fenix.

Why doesn't we use nsIContentPermissionPrompt like other permissions? Doesn't UX team want doorhanger notification for this permission?

We haven't talked to the UX team about this yet. However, with multiple people, we came to the conclusion that a "Paste" button should be shown to the user. Some more context about this can be found in https://bugzilla.mozilla.org/show_bug.cgi?id=1578321#c8.

Flags: needinfo?(mbrodesser)

@csadilek: are there reasons to do this differently on Android?

Just to add to what :m_kato already shared, we want any popups and prompts to be rendered natively on Android so we have consistent platform-specific look-and-feel. The good news is that we already have a solution for this in GeckoView, since the desired UX here is a "Paste" button that should appear relative to its trigger.

You can see the details in https://searchfox.org/mozilla-central/rev/2946e9b450cb35afaf8dad927a8d187975dcd74d/mobile/android/actors/SelectionActionDelegateChild.jsm#68 and how it handles org.mozilla.geckoview.PASTE for example. It will send a ShowSelectionAction message containing the clientRect, which GeckoView will use to render the action:

Rendering a single paste action looks very similar to your solution on desktop. After talking to Agi, this wouldn't need any A-C/Fenix/Focus changes. You should be able to translate and handle actions in GeckoView's SelectionActionDelegateChild as a starting point.

Flags: needinfo?(csadilek)

(In reply to Christian Sadilek [:csadilek] from comment #8)

@csadilek: are there reasons to do this differently on Android?

Thanks for the bigger picture, that's helpful.

Just to add to what :m_kato already shared, we want any popups and prompts to be rendered natively on Android so we have consistent platform-specific look-and-feel.

Makes sense.

The good news is that we already have a solution for this in GeckoView, since the desired UX here is a "Paste" button that should appear relative to its trigger.

"relative to its trigger" isn't entirely true. On Desktop, it's always next to the mouse position. That's usually relative to the trigger, but not necessarily. A call of navigator.clipboard.readText() may happen a few seconds (at most five, see https://searchfox.org/mozilla-central/rev/4654ce1e24a6af17bc96ab60f1f70c218755142f/modules/libpref/init/StaticPrefList.yaml#3879-3880) after a user action.

Moreover, readText() may be called from different frames (e.g. from an <iframe> and its parent) and only one "Paste" button should be shown for them. I guess it should be possible handle that in GeckoView.

You can see the details in https://searchfox.org/mozilla-central/rev/2946e9b450cb35afaf8dad927a8d187975dcd74d/mobile/android/actors/SelectionActionDelegateChild.jsm#68 and how it handles org.mozilla.geckoview.PASTE for example. It will send a ShowSelectionAction message containing the clientRect, which GeckoView will use to render the action:

Rendering a single paste action looks very similar to your solution on desktop. After talking to Agi, this wouldn't need any A-C/Fenix/Focus changes. You should be able to translate and handle actions in GeckoView's SelectionActionDelegateChild as a starting point.

Thanks for the starting point; will need to learn how this can be accessed from the C++ side of Gecko.

Summary: Investigate behavior on Android → Considering clipboard acess permission API for clipboard.readText()
Summary: Considering clipboard acess permission API for clipboard.readText() → Considering clipboard access permission API for clipboard.readText()

Moving to GV

Component: DOM: Copy & Paste and Drag & Drop → General
Product: Core → GeckoView

clipboard.readText requires clipboard read permission. But this isn't
implemented by nsIContentPermission, so we have to handle
ClipboardReadTextPaste actor, then call
PermissionDelegate.onContentPermission with PERMISSION_CLIPBOARD_READ for
this support.

Also, since it is possible to implement iOS style clipboard read permission
prompt, I add last touch/mouse location to the parameter as clientPoint.

Assignee: nobody → m_kato
Status: NEW → ASSIGNED

P1 since Makoto is working on this bug.

Type: task → enhancement
Priority: -- → P1
Whiteboard: [geckoview:m104]
Depends on: 1778486
Whiteboard: [geckoview:m104] → [geckoview:m104] [geckoview:m105]
Component: General → Web APIs
Component: Web APIs → Permissions

Rolling this bug over to 106

Whiteboard: [geckoview:m104] [geckoview:m105] → [geckoview:m104] [geckoview:m105] [geckoview:m106]

Makoto, you have some code changes planned based on review feedback. Will you have time to make the changes and land them in the Nightly 106 cycle?

Flags: needinfo?(m_kato)
Attachment #9284270 - Attachment description: Bug 1776829 - Add PERMISSION_CLIPBOARD_READ type to PermissionDelegate. r=#geckoview-reviewers → Bug 1776829 - Implement "Paste" permission action for clipboard.readText.

Makoto, you have some code changes planned based on review feedback. Will you have time to make the changes and land them in the Nightly 106 cycle?

I hope this will be fixed in 106 cycle. But dom.events.asyncClipboard.readText is still turned off even if desktop.

Flags: needinfo?(m_kato)

(In reply to Makoto Kato [:m_kato] from comment #16)

Makoto, you have some code changes planned based on review feedback. Will you have time to make the changes and land them in the Nightly 106 cycle?

I hope this will be fixed in 106 cycle. But dom.events.asyncClipboard.readText is still turned off even if desktop.

Yup, we're still addressing some issues blocking turning dom.events.asyncClipboard.readText on on desktop. We plan to turn this feature on on both desktop and android the same time

Attachment #9284270 - Attachment description: Bug 1776829 - Implement "Paste" permission action for clipboard.readText. → Bug 1776829 - Implement "Paste" permission action for clipboard.readText. r=#geckoview-reviewers
Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/bc01b1431aa4
Implement "Paste" permission action for clipboard.readText. r=geckoview-reviewers,owlish
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: