search

wordpress-mobile / gutenberg-mobile

Mobile version of Gutenberg - native iOS and Android
GNU General Public License v2.0
250 stars 56 forks source link

[Embed block] Paragraph block does not detect embeddable link that is pasted from Gboard #4203

Open jd-alexander opened 2 years ago

jd-alexander commented 2 years ago

Describe the bug

When the Gboard, Google Keyboard is utilized as the default Keyboard on Android and the clipboard content is channeled via Google Keyboard's clipboard the Paragraph does not detect that the content is being pasted, therefore the Embed block Bottom Sheet is not triggered.

To Reproduce

  1. Ensure Google Keyboard is set as your default keyboard.
  2. Copy an embeddable link to the device's clipboard.
  3. Open the app and create a new post.
  4. Notice that the embeddable link is on the Google Keyboard's UI.
  5. Press the embeddable link.
  6. Notice the Paragraph is populated with the link but the Embed Bottom Sheet is not displayed.

Expected behavior

The Embed Bottom Sheet should be shown when link-based content from the clipboard is pasted into a Paragraph block.

Screenshots

https://user-images.githubusercontent.com/1509205/140267078-e33c10da-1d15-4c31-9f76-667699a0273d.mov

Smartphone (please complete the following information):

jd-alexander commented 2 years ago

Based on my investigation this issue occurs because the clipboard content that is shown to the user as a suggestion on Gboard is actually typed in as text, and is not actually pasted. I verified this by utilizing the following troubleshooting steps below.

  1. I put a console.log within the onSelectionChange of the rich-text component. (function reference)
  2. I also put a console.log within the onPaste of the rich-text component. (function reference)
  3. After setting up the logging, I noticed that when I long pressed on the Paragraph block and did the standard Android paste action, the onPaste function was triggered.
  4. However, if Gboard's suggestion of the pasted link is clicked then only onSelectionChange is triggered.
jd-alexander commented 2 years ago

@fluiddot I want to hear your thoughts on a potential solution for this issue. Thanks in advance 🙇🏾

Potential ideas

Preferred solution

  1. Introduce Gboard detection logic within the RichText component - We could modify the oonSelectionChangeFromAztec function (reference) and detect that the selection change that was received is Gboard related. Once this is ascertained, we could then propagate this Selection Change to the onPaste handler with the event object it accepts.

Other potential solutions and considerations

  1. Send keyboard name over the bridge - Since this is affecting Gboard's there's a mechanism for fetching the name of the keyboard via the [InputMethodManager](https://developer.android.com/reference/android/view/inputmethod/InputMethodManager#getEnabledInputMethodList()). This would need to be sent over the bridge so it might not be ideal.

    1. Modify Aztec Android's onSelectionChange - I was thinking that it could be resolved by modifying Aztec Android to detect when the Gboard paste takes place based on the behavior of the onSelectionChange i.e since its a longer input being entered than one letter at a time, we should be able to write logic to detect this change and trigger the onPaste. I am looking at https://github.com/WordPress/gutenberg/pull/32471 for inspiration. The mechanism for achieving this would be similar to a Clipboard event in Android and send this data via the ReactAztec onPaste mechanism.

    Prioritization

Before an attempt is made on this issue, I am also wondering if this bug is one that should be prioritized for a fix. This thought came to my mind because the user can still long-press on the Paragraph block and utilize the normal Paste functionality instead of the keyboard itself. This solution would be introducing custom behavior for a Keyboard. Nonetheless, we have done this before for other issues, therefore it is worth consideration.

hypest commented 2 years ago

👋 I had a super quick look at the case where GBoard inserts the copied text as text change event (instead of Paste event) and I think we can probably tap into the onTextUpdate() function and detect the URL from there. The only "fear" I have is of a case where GBoard won't insert the text as a whole but break it down to separate text insertion events for reasons.

I went ahead and tried using a modified version of the onPaste function (to pick up the text property from the nativeEvent) which kinda worked. It detected the URL but I didn't see the bottomsheet popup. I feel there's some potential there though.

fluiddot commented 2 years ago

I'd like to highlight that this issue also affects other pasting features like creating blocks when pasting HTML, so I'd lean towards finding a way to detect when the Gboard is being used and somehow detect when the content is pasted.

Not sure if it will work but maybe we could check in the onTextChanged function (reference) if the text change matches the content from the clipboard (in case Gboard exposes this data via the ClipboardManager) and the Gboard is being used.

fluiddot commented 2 years ago

Before an attempt is made on this issue, I am also wondering if this bug is one that should be prioritized for a fix. This thought came to my mind because the user can still long-press on the Paragraph block and utilize the normal Paste functionality instead of the keyboard itself. This solution would be introducing custom behavior for a Keyboard. Nonetheless, we have done this before for other issues, therefore it is worth consideration.

Good point, to be honest, I'm not sure how critical we should consider the issue but, as I commented in the previous comment, all the functionality we do when pasting content in the RichText component is not executed when pasting from the Gboard keyboard, not just the one for the embed block. Not sure how many users use the Gboard (or other keyboards that might have the same issue) to consider this high priority 🤔 .

jd-alexander commented 2 years ago

👋 I had a super quick look at the case where GBoard inserts the copied text as text change event (instead of Paste event) and I think we can probably tap into the onTextUpdate() function and detect the URL from there. The only "fear" I have is of a case where GBoard won't insert the text as a whole but break it down to separate text insertion events for reasons. I went ahead and tried using a modified version of the onPaste function (to pick up the text property from the nativeEvent) which kinda worked. It detected the URL but I didn't see the bottomsheet popup. I feel there's some potential there though.

Thanks for chiming in 🙇🏾 I agree that the text being broken down into separate insertion events would be something to look out for as it would impact the ability of the logic to pickup URLs.

Good point, to be honest, I'm not sure how critical we should consider the issue but, as I commented in the previous comment, all the functionality we do when pasting content in the RichText component is not executed when pasting from the Gboard keyboard, not just the one for the embed block. Not sure how many users use the Gboard (or other keyboards that might have the same issue) to consider this high priority 🤔 .

Agreed. I will put a low priority label for now since the long-press paste functionality works as expected and would be the ideal channel to trigger the paste behavior. If we get more reports of this impacting users then we can combine some of the discussed ideas to create a solution.