Closed Bug 1235666 Opened 8 years ago Closed 8 years ago

Long press to paste does not work

Categories

(Web Compatibility :: Site Reports, defect)

Other
Android
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mt, Unassigned)

References

Details

(Whiteboard: [sitewait][css])

Attachments

(3 files)

Works fine in chrome. It doesn't have any relationship to the type of input, as far as I can tell.  I'm using a Swype keyboard.
Can you elaborate a little? 
   - Do you see this as a dup of Bug 1086933?
   - Is it site-specific? 
   - What /do/ you observe, and
   - what were you /expecting/ to observe?

etc?
Flags: needinfo?(martin.thomson)
(In reply to Mark Capella [:capella] from comment #1)
> Can you elaborate a little? 
>    - Do you see this as a dup of Bug 1086933?

No.  That relates to the URL bar.  This is an <input type="text"> (and variations).

>    - Is it site-specific? 

No.

>    - What /do/ you observe, and

STR: copy some text, highlight text box, long press.
OBS: nothing

>    - what were you /expecting/ to observe?

EXPECTED: an option to paste from the clipboard.


> etc?
Flags: needinfo?(martin.thomson)
Ok. We did have an initial issue with Bug 1230582 - Action Bar is not invoked when tapping / long pressing an empty search text area ... but that was corrected around 12/23 ...

For example ... using the "SimpleInput" test [0] I can observe behaviour [1]


[0] https://www.dropbox.com/s/jtbodbxw2qyiykg/simpleInput.html?dl=0
[1] https://www.dropbox.com/s/vorhsop50v443su/bug1235666_simpleInput_test.mp4?dl=0
There is also a bug with type=number text fields. For example the bugzilla OTA field. bug 1224216
iirc, bug 1224216 involved the original (orange/Pointy) Text selection carets ... not sure that's valid as a seperate issue any longer as we default to the new (blue/round) carets now.
I can't paste into Facebook comment fields, and it's annoying. It's a fairly recent regression in Android Nightly.

Mark: if you open your demo and try to type a word, then place the cursor earlier in the sentence (like inside a word) and long-click - do you get a paste option? I don't. It behaves much like it does for me on Facebook.
Flags: needinfo?(markcapella)
(something else that annoys me on that demo and current Fx behaviour: it doesn't seem possible to paste something after what you just typed - long-clicking will select some text that will get overwritten)
We're currently refining the UI in the area of Text Selection, and have gone through a couple of rapid revisions in nightly. 

For some general discussion, see Bug 1240917 - Consider action bar behavior with native text selection.

The current approach to support paste@cursor is being implemented in Bug 1246487 - Support single tap on the caret to show actionbar when selection is collapsed.

This should help, and will be available in tonights nightly.
Flags: needinfo?(markcapella)
Component: Keyboards and IME → Text Selection
Do you notice the new behaviour? Can we close WFM this bug?
Flags: needinfo?(hsteen)
I actually saw this yesterday on a newly pulled nightly, also on Facebook. It's similar in that I can't even seem to move the cursor to another place in the text. It's not always reproducible, but I've seen this a few times in the past week.
I also see better behaviour in the latest nightly and the cursor most of the time moves where I want or expect it. However, the long-click to paste always selects something (like the last word) so it's not possible to paste without overwriting something, and if the last thing in a TEXTAREA is a newline long-click to paste doesn't work at all.
Flags: needinfo?(hsteen)
Hallvord, The new UI is that you can long-press to select a word, which invokes the ActionBar (and soon the Floating Toolbar) ... or you can tap into the field to display the AccessibleCaret for curosr positioning.

Subsequent tapping of the single AccessibleCaret will then invoke the ActionBar for pasting at the cursor.

Chenxia, if you can post STR (URL, Screenshot? contents/text of the <input>?) etc, the next time you spot your issue, it will help, as I've not seen this yet.
Let's leave this open for general discussion, (along with Bug 1249490) ... it seems to be morphing :)
This is a screencast of the problems I've seen lately, on the 2/22 build. Following this cast, I updated to the 2/23 (today's nightly) and I am still seeing it. I also enabled clicks so you can see when I'm clicking or long-pressing.

The problems I am seeing pretty frequently:
* Cursor in a selected text box is not always visible above the keyboard, and Firefox does not autoscroll to it
* After text is typed, single-tap and long-press not registering
* Cursor is flashing even though keyboard is shown
Also need-infoing snorp and jim, because maybe this is an input/touch problem.
Flags: needinfo?(snorp)
Flags: needinfo?(nchen)
This is a Gecko-filtered log for summoning a keyboard that covers the text box, entering text, and failed touch events to reposition the cursor in the text box. (FYI, this isn't the log from the video, this log was collected afterwards.
Randall has been looking at this stuff
Flags: needinfo?(snorp) → needinfo?(rbarker)
I'll have to take a closer look to see where the events are going wrong. I noticed that on my phone that while the text input on fb for "what's on your mind" seems to work mostly as expected. Once the text input area for comments has been selected events seem to stop working or at least going to correct location. Not sure why the text input doesn't scroll completely into view. It may be a combination of being at the bottom of the page and being resized after getting focus. I'll look into that as well.
Flags: needinfo?(rbarker)
Still investigating why the text input box doesn't scroll all the way into view, but got this:

D/GeckoBrowser(29829): Unexpected failure during caret attach: Native touchCaret requested while Gecko enabled.

While trying to tap to show touch carret.
That's a warning trying to confuse you. The old TextSelection SelectionHandler is still invoked but fails expectedly.
Depends on: 1251001
I've created Bug 1251001 which address the input field in fb not panning into view. I will continue to investigate the issue of the long press not displaying selection caret.
Flags: needinfo?(nchen)
I've investigated this bug further and do not believe it is an issue with APZ or AccessibleCaret. I am able to select by long press in comment text fields on FB in Beta which is using native carets and JPZ. However in nigtly, I tested the following: APZ + AccessibleCaret, APZ + Native Caret, JPZ + AccessibleCaret, JPZ + Native Caret. All four configurations displayed the same issue. When long pressing on text in the TextFrame of the comment, the TextFrame returns false when nsFrame::IsSelectable is called.
As a test, I hard coded nsFrame::IsSelectable to be true and selection and long press worked as expected after that.
I see two bugs that landed most recently in nsFrame::IsSelected are Bug 1132768 and Bug 1181130. I backed out Bug 1181130 and the issue was still present.
Component: Text Selection → Selection
Product: Firefox for Android → Core
tracking-fennec: --- → ?
Ehsan, this appears to be a regression with nsIFrame::IsSelectable(). Given that it's Facebook, please look into it soon.
Flags: needinfo?(ehsan)
I need a test case and some more detailed info on what's going on.  I don't have a Fennec debugging environment so I can't look into it myself.
Flags: needinfo?(ehsan)
Also I wasn't the one who wrote the culprit patch.  :-)
(In reply to :Ehsan Akhgari from comment #27)
> Also I wasn't the one who wrote the culprit patch.  :-)

AFAICT, we don't know what patch broke it?
(In reply to :Ehsan Akhgari from comment #26)
> I need a test case and some more detailed info on what's going on.  I don't
> have a Fennec debugging environment so I can't look into it myself.

What's stopping you from setting one up? I think Margaret and probably GFX have phones in Toronto you can borrow, and building for Android is simply 'mach bootstrap' and a couple mozconfig changes.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #29)
> (In reply to :Ehsan Akhgari from comment #26)
> > I need a test case and some more detailed info on what's going on.  I don't
> > have a Fennec debugging environment so I can't look into it myself.
> 
> What's stopping you from setting one up? I think Margaret and probably GFX
> have phones in Toronto you can borrow, and building for Android is simply
> 'mach bootstrap' and a couple mozconfig changes.

You can also use `mach android-emulator` to launch an emulator.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #29)
> (In reply to :Ehsan Akhgari from comment #26)
> > I need a test case and some more detailed info on what's going on.  I don't
> > have a Fennec debugging environment so I can't look into it myself.
> 
> What's stopping you from setting one up?

Lack of time, mostly.  :-)  If we don't even know for sure which patch broke this, someone from QA needs to bisect and find the offending revision first, before we decide who is the right person to fix this.  Also, again, a test case will help tremendously.
Rares, can we try to hunt this down with mozregression?
Flags: needinfo?(rares.bologa)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #32)
> Rares, can we try to hunt this down with mozregression?

I tried to do just that. It may not be a regression. I went back as far as 42 and it was still reproducible. If I request the desktop version of the page, selection works as expected in all versions I tried up to currently nightly.
Also, I looked at the <textarea> and it has -moz-user-select: auto; set. Disabling this property allow the <textarea> to function as expect and the text is selectable with a long press.
Flags: needinfo?(rares.bologa)
Mike, this seems like webcompat?
Flags: needinfo?(miket)
Hmm. https://miketaylr.com/bzla/1235666.html doesn't show the behavior Randall is describing in Comment #34.

Randall, can you confirm?

(Also, is this bug only about Facebook.com?)
Flags: needinfo?(miket) → needinfo?(rbarker)
(In reply to Mike Taylor [:miketaylr] from comment #36)
> Hmm. https://miketaylr.com/bzla/1235666.html doesn't show the behavior
> Randall is describing in Comment #34.
> 
> Randall, can you confirm?
> 
> (Also, is this bug only about Facebook.com?)

I can only reproduce on Facebook in the input field for comments. The "What's on your mind?" input field seems to work.
Flags: needinfo?(rbarker)
(In reply to Randall Barker [:rbarker] from comment #34)
> Also, I looked at the <textarea> and it has -moz-user-select: auto; set.
> Disabling this property allow the <textarea> to function as expect and the
> text is selectable with a long press.

Where is that style coming from?
Hallvord, since you can (or could) repro on FB, could you look into the "-moz-user-select: auto;" angle?
Flags: needinfo?(hsteen)
(In reply to Mike Taylor [:miketaylr] from comment #39)
> I can't reproduce on Nightly: https://www.youtube.com/watch?v=Ii1auIOnY8Q

As stated in comment #37 it is because you are using the "What's on your mind?" input field which does work. It is only in the comment input fields, like commenting on a picture or post that it fails.

You need to type in some text into the input field, then try and long press on the text. It can not be selected.
Oh. My brain interpreted "The "What's on your mind?" input field seems to work." as "you can use this input to reproduce the bug". >_<
(In reply to Mike Taylor [:miketaylr] from comment #42)
> Oh. My brain interpreted "The "What's on your mind?" input field seems to
> work." as "you can use this input to reproduce the bug". >_<

Sorry, I said "seems to work" because the selection carets have their own special issues in nightly right now which can make figuring out what is broken challenging at times.
Attached file Testcase 1235666.htm
I must say this can be very, very annoying on Facebook - whenever you want to comment on something and include a link.. :-/
Flags: needinfo?(hsteen)
The obvious next question is if this is core or evangelism stuff. Basically 

<div style="-moz-user-select: none">
  <textarea style="-moz-user-select: auto">

- isn't auto going to ensure selection is possible in the textarea?
(In reply to Hallvord R. M. Steen [:hallvors] from comment #45)
> The obvious next question is if this is core or evangelism stuff. Basically 
> 
> <div style="-moz-user-select: none">
>   <textarea style="-moz-user-select: auto">
> 
> - isn't auto going to ensure selection is possible in the textarea?

My reading of the MDN article[0] suggests that it would have to be set to 'text' to allow selection again. The 'auto' value isn't covered there, but I think that is supposed to do the same thing as if it were unset, which means the decision falls to the closest parent, which is set to none.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
dbaron, what's the right behavior here? See comments #44 and below.
Flags: needinfo?(dbaron)
https://dxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2793

I don't pretend to understand much of nsFrame::isSelectable, but the following comment suggests snorp is correct in Comment 46:

// Like 'visibility', we must check all the parents: if a parent
// is not selectable, none of its children is selectable.
Yeah, the |-moz-user-select: none| style prevents selection in all of the descendants.  This seems to be a bug on Facebook.

(Note that the only thing Fennec specific about this is the different code they seem to be serving to Fennec.)
Component: Selection → Mobile
Product: Core → Tech Evangelism
Thanks everyone. I'm going to send an email to the fb-moz list and see if we can get some traction there.
Flags: needinfo?(dbaron)
Whiteboard: [sitewait][css]
(In reply to Mike Taylor [:miketaylr] from comment #50)
> Thanks everyone. I'm going to send an email to the fb-moz list and see if we
> can get some traction there.

Great, thank you!
tracking-fennec: ? → ---
ni? Mike to follow up on status here.
Flags: needinfo?(miket)
This is still an issue. Facebook did confirm that they would look into it -- I'll follow up privately with the Engineer who replied to ask about status.
Flags: needinfo?(miket)
Dropping the status flag as this is a site issue that affects all versions of Firefox.
This also prevents going back to correct typos since you can't move the cursor (except by deleting backwards) - very, very annoying :-(
This works for me now!
Long-click to paste works well. I've attempted to find elements still styled with -moz-user-select:none and could not find any, however there's still an issue that prevents moving the cursor by touch inside the textarea. Will open a new bug for that if none exists.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
See Also: → 1266547
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: