Issue with first scrolling at page

RESOLVED WORKSFORME

Status

()

Firefox
Untriaged
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: Maksim Lebedev, Unassigned)

Tracking

Trunk
All
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150320202338

Steps to reproduce:

http://w3c-test.org/pointerevents/pointerevent_change-touch-action-onpointerdown_touch-manual.html
1. (If main page have y-scrollbar) when we first time try scroll black content at page - nothing happens.
2. (If main page have no y-scrollbar) when we first time try scroll black content at page - black content is scrolled and get a lot of scroll events.
3. when we second (and following) time try to scroll black content at page - black content is scrolled and get a lot of scroll events.


Actual results:

Issue is that first and second touches have different behavior.
(In case main page have y-scrollbar).
If main page have no y-scrollbar first and second touches have the same behavior.


Expected results:

First and second behavior should be the same in both cases.
(Reporter)

Comment 1

3 years ago
Some investigation: Looks like, first and second cases have different behavior in
nsBaseWidget::DispatchAPZAwareEvent()
{
...
    nsEventStatus result = mAPZC->ReceiveInputEvent(*aEvent, &guid, &inputBlockId);
    if (result == nsEventStatus_eConsumeNoDefault) {
        return result;
...
}
In second case result is nsEventStatus_eConsumeNoDefault, but in first case result have another value.
Blocks: 736048
OS: Windows 8 → Windows
Hardware: x86_64 → All
Isn't that what's supposed to happen as per what it says at the top of the test?
(Reporter)

Comment 3

3 years ago
Description of test is a little bit wrong. It should be like:
"Press and hold your touch. Try to scroll text in any direction. Expected: black area scrolling.
Then release your touch and try to scroll again. Expected: no panning".

Issue is that first touch and scroll do not initiate black area scrolling.
(Reporter)

Comment 4

3 years ago
I assume that correct sequence is like this:
  mAPZC->ReceiveInputEvent(TOUCH_START, ...);
    InputQueue::ReceiveTouchInput()
(*)   block->SetDuringFastMotion()
  mAPZC->ReceiveInputEvent(TOUCH_MOVE, ...);
    InputQueue::ReceiveTouchInput()
      block->IsDuringFastMotion();
        result = nsEventStatus_eConsumeNoDefault;
But in first time (*) did not fired and sequence become incorrect.
Why do you expect SetDuringFastMotion to fire on the first touch block?
Also the test is about touch-action:none support which is not fully implemented so I would expect the test to fail. What you described however sounds like what I would expect to see when the test passes, so probably I'm misunderstanding what you are describing.
(Reporter)

Comment 7

3 years ago
(In reply to Kartikaya Gupta from comment #5)
> Why do you expect SetDuringFastMotion to fire on the first touch block?
I found such behavior during the second touch motion.

(In reply to Kartikaya Gupta from comment #6)
> Also the test is about touch-action:none support which is not fully
> implemented so I would expect the test to fail. What you described however
> sounds like what I would expect to see when the test passes, so probably I'm
> misunderstanding what you are describing.
Issue is not related with results of test. Issue is related only with first touch motion.
I will try to provide test-file with some changes for more comfortable testing.
Flags: needinfo?(alessarik)
(In reply to Maksim Lebedev from comment #7)
> (In reply to Kartikaya Gupta from comment #5)
> > Why do you expect SetDuringFastMotion to fire on the first touch block?
> I found such behavior during the second touch motion.

That's probably because the first touch block started a pan, and the content was still panning rapidly when you started the second touch block. I wouldn't expect the first touch block to be in fast-motion because the content isn't panning when that touch block arrives.
(Reporter)

Comment 9

3 years ago
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8)
> That's probably because the first touch block started a pan, and the content
> was still panning rapidly when you started the second touch block. I
> wouldn't expect the first touch block to be in fast-motion because the
> content isn't panning when that touch block arrives.
I make first touch motions, then I wait some time for eliminate issues related with internal calculations, then I make second touch motion.
(Reporter)

Comment 10

3 years ago
Created attachment 8592698 [details]
check_first_touch.html

This is simplified version of official test.
Test has no style changes during test work.
And test has small event logs.

First touch motion puts sequence to event logs: d, auto, u.
As result we can see that all page is scrolled.

Second touch motion puts sequence to event logs: d, auto, s, s, s, ...
As result we can see that black area is scrolled. (it is expected).

I assume that first touch motion should be the same behavior.
Flags: needinfo?(alessarik)
When you test this what prefs do you have enabled?
(Reporter)

Comment 12

3 years ago
dom.w3c_pointer_events.enabled;true
layout.css.touch_action.enabled;true
layers.async-pan-zoom.enabled;true
dom.w3c_touch_events.enabled;1
(Reporter)

Comment 13

3 years ago
Did You have a chance to test attached file?
Flags: needinfo?(bugmail.mozilla)
Not yet, no.
I was able to reproduce the issue on your test page on an older build, but on the latest code it doesn't happen. It might have been fixed - can you still reproduce it?
Flags: needinfo?(alessarik)
Flags: needinfo?(bugmail.mozilla)
Blocks: 1122211
(Reporter)

Comment 16

3 years ago
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #15)
> I was able to reproduce the issue on your test page on an older build, but
> on the latest code it doesn't happen. It might have been fixed - can you
> still reproduce it?
I used 240346:570bb53a3e7b changeset as latest changes from m-c yesterday night.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=88f333162854
Described issue is still reproduced.
Flags: needinfo?(alessarik)
Ok, I think this is fixed by bug 1154478. Or you can set the layout.event-regions.enabled pref to true if you're still on a build without that fix.
(Reporter)

Comment 18

3 years ago
Some patches ago such behavior have stoped ...on normal windows widget.
But unfortunately on e10s bug can be still reproduced.
Flags: needinfo?(bugmail.mozilla)
(Reporter)

Comment 19

3 years ago
(In reply to Maksim Lebedev from comment #18)
> But unfortunately on e10s bug can be still reproduced.
Looks like on release build all is OK on e10s.
Issue can be closed.
Flags: needinfo?(bugmail.mozilla)
Great, thanks for checking.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.