Dragging text selection markers selects the wrong text on Android with layout.reflow.synthMouseMove=true
Categories
(Core :: Layout, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox73 | --- | fixed |
People
(Reporter: m_kato, Assigned: TYLin)
References
Details
Attachments
(1 file)
+++ This bug was initially created as a clone of Bug #1580669 +++
Copied from: https://github.com/mozilla-mobile/fenix/issues/5037
Steps to reproduce
1-Launch Fenix
2-Go to any website for example: https://en.wikipedia.org/wiki/Main_Page
3-long press on any paragraph to select a word and try to slide the selector bubble to select more words from the article.
Expected behavior
Select word by word or maybe by letters it depends on how fast you move the selector bubble
Actual behavior
when long press on a word it will be selected but when trying to select more words the selector goes to the other direction, it's quite impossible to select a sentence.
Device information
Huawei P8 lite 2017
- Android device: Android 8.0
- Fenix version:
Nightly 190830 06:05 (Build #12420615)
📦: 10.0.1, a573b4116
🦎: 70.0a1-20190826094255
Trying to select the paragraph
From "when" to "sentence."
Gif of Fenix behavior:
https://user-images.githubusercontent.com/50635951/64729857-0a132100-d4ac-11e9-823b-28200e639b52.gif
|
Reporter | |
Comment 1•5 years ago
|
||
When debugging Accessibility Caret, eTouchMove is correct point, but eMouseMove (by convert from touch event?) is incorrect point. Why point of touchmove and mousemove is different?
|
||
Comment 2•5 years ago
|
||
The mousemove events are the ones dispatched from the synth mouse move system. They are created by layout and don't correspond to actual user input.
The events are created here:
https://searchfox.org/mozilla-central/rev/4218cb868d8deed13e902718ba2595d85e12b86b/layout/base/PresShell.cpp#5443
Notably we compute the refpoint there too.
And then they are dispatched here:
https://searchfox.org/mozilla-central/rev/4218cb868d8deed13e902718ba2595d85e12b86b/layout/base/PresShell.cpp#3654
Note that they are dispatched to the view manager which is just a thin wrapper and then the view manager dispatches to the presshell. This means that the event never touches the widget layer, different from touch moves. Botond can probably say more about the implications of that from an apz perspective.
I would expect that we should only get synth mouse moves after a reflow or a scroll. It sounds like they are happening frequently from what you say.
|
|
Reporter | |
Comment 3•5 years ago
|
||
Invalid mousemove event is fired by reflow since accessibility caret flushes layout. mouse ref point will be stored by https://searchfox.org/mozilla-central/rev/4218cb868d8deed13e902718ba2595d85e12b86b/layout/base/PresShell.cpp#6504. So invalid mousemove seems to have WidgetMouseEvent::eSynthesized.
|
||
Comment 4•5 years ago
|
||
TYLin: Would you be able to help take a look at this?
|
Assignee | |
Comment 5•5 years ago
|
||
I debug this a bit today. The event point of a synthesized mouse move event is wrong if it is from touch move events. However, the point is correct if the synthesized one is from a mouse move event. Maybe bug 1549355 can fix this.
From AccessibleCaret's perspective, the synthesized mouse move is not needed when dragging the carets because it already works well with layout.reflow.synthMouseMove=false. If our goal is to turn on layout.reflow.synthMouseMove for the reasons described in bug 1545393. I can workaround AccessibleCaretEventHub to consume the synthesized mouse move events while dragging the caret.
Re comment 2:
I would expect that we should only get synth mouse moves after a reflow or a scroll. It sounds like they are happening frequently from what you say.
AccessibleCaret is position:absolute anonymous divs, so we change its top and left value to move it as we drag it. It's expected to reflow them.
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
||
Comment 8•5 years ago
|
||
| bugherder | ||
Description
•