Open Bug 1524380 Opened 10 months ago Updated 3 months ago

Cannot paste a selected text into WordPress Gutenberg


(Firefox for Android :: Text Selection, defect, P3)




Tracking Status
firefox65 --- unaffected
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fix-optional


(Reporter: shinymewy, Unassigned)


(Blocks 1 open bug)


(Keywords: regression)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I attempted to copy text and paste it into a WordPress multisite setup without any success.

Actual results:

I was unable to paste text into the text field, the toolbar would not appear to paste text until I there was at least one character put in the field first.

Expected results:

I should have been able to paste text into the Gutenberg text field

Thanks for your report!
I wasn't able to reproduce this issue with OnePlus 5T(Android 9). Could you please make a video with the exact steps? You can download AZ screen recorder from Google Play.

Component: General → Text Selection
Flags: needinfo?(shinymewy)

I don't get why Firefox would be acting in this way but here's how I managed to break Firefox on my Galaxy s8

Model number:


Flags: needinfo?(shinymewy)


I was able to reproduce your issue on the latest Nightly 67.0a1 (2019-02-04) with Samsung Galaxy S6 (Android 7.0).
I will confirm the issue.

Thank you!

Ever confirmed: true
Keywords: regression
OS: Unspecified → Android
Hardware: Unspecified → ARM
Summary: I can't post text into WordPress Gutenberg → Cannot paste a selected text into WordPress Gutenberg
Version: Firefox 65 → Trunk

Can this be reproduced on desktop? Either way, Masayuki may have ideas what's causing this.

Flags: needinfo?(masayuki)

I have no idea and I don't have any WordPress instance to test it. According to the video, looks like that this is a bug of AccessibleCarent or APZC.

TYLin: Any ideas?

Flags: needinfo?(masayuki) → needinfo?(aethanyc)

I forgot to ask miralobontiu or shinymewy if they could reproduce this issue on desktop.

Flags: needinfo?(shinymewy)
Flags: needinfo?(mirabela.lobontiu)

Hi Andrew,
It is not reproducible on desktop - tested on Windows 10, with the latest Nightly 67.0a1.
Thank you!

Flags: needinfo?(mirabela.lobontiu)

Thanks for verifying. I think having a reproducible test case would make a solution here much more tractable.

shinymewy, do you have or know of a publicly-accessible site that we could use?

Hi shinymewy,

I looked at the video in comment 2. It looks like you're trying to summon the caret and toolbar in an empty text field by tapping. Typically, it requires long press on any empty text field (like an empty google search box) to bring up the caret and toolbar. I believe other browsers on Android such as Google Chrome behaves the same way.

Does long press action work for you? If long pressing on it does nothing, then this is a bug.

Flags: needinfo?(aethanyc)

long press did nothing for me, and I was able to get the same thing to work on chrome. So I was pretty sure it was some kind of firefox mobile bug.

Flags: needinfo?(shinymewy)

Hmm, I cannot reproduce this bug in the editor of adding "Blog Posts" or "Site Pages" on on Pixel 2.

It seemed like the only other person who could get the bug working was another Samsung phone user... So does it have to do with Samsung phones?

Hi all,
I was able to reproduce the issue on a One Plus 5T (Android 9) device also, so it is not device specific.

mirabela - Can you try reproducing this on Chrome, the reference browser or Focus to see if you can reproduce there?

Flags: needinfo?(mirabela.lobontiu)

Hi Marcia,
I tested on Chrome, Reference browser and Focus, and it wasn`t reproducible on neither of them.
Tested with One Plus 5T (Android 9).

Flags: needinfo?(mirabela.lobontiu)
Priority: -- → P3

Ting-Yu, any further findings into a possible cause?

Flags: needinfo?(aethanyc)

I investigate a bit more today and find that in order to bring up the caret, you need to long-tapping on the green area. (See my screenshot.) If long-tapping on the red area, the editing area loses focus, and the keyboard is going down.

The technical details: the WordPress visual editor is an iframe. When it's empty, the green area is a focusable and editable <p>, so long-tapping on it is going to bring up the caret. Whereas the red area is the non-focusable and non-editable <html>, long-tapping there does nothing.

Google Chrome behaves the same when long-tapping on the green and red areas as well. Though Chrome shows the caret when single-tapping on the editor, but this is more like a bug or inconsistent behavior to me because single-tapping on an empty editable area doesn't suppose to show the caret.

Flags: needinfo?(aethanyc)

Sorina does this reproduce with geckoview?

Flags: needinfo?(sorina.florean)

Hi Liz,

I wasn't able to reproduce on the latest build of Firefox Preview (Fenix) 1.0.1920 (#build 11391807), with Samsung Galaxy S8 (Android 9), and Samsung Galaxy S6 (Android 7.0).

Thank you,

Flags: needinfo?(sorina.florean)

Might be off-topic, however, I once had a similar issue (which was fixed after reading something on wpza , thankfully), where a Grammarly browser extension messed up the way my inputs and textareas worked within WordPress; especially after the Gutenberg update.

Hope this helps anyone thinking that it's an issue with FF (debug your extensions first!)

You need to log in before you can comment on or make changes to this bug.