1153935 - Issue with first scrolling at page

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Maksim Lebedev]

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.

Comment 1

[Maksim Lebedev]

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.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Isn't that what's supposed to happen as per what it says at the top of the test?

Comment 3

[Maksim Lebedev]

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.

Comment 4

[Maksim Lebedev]

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.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Why do you expect SetDuringFastMotion to fire on the first touch block?

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 7

[Maksim Lebedev]

(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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(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.

Comment 9

[Maksim Lebedev]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 10

[Maksim Lebedev]

Attachment: 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.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

When you test this what prefs do you have enabled?

Comment 12

[Maksim Lebedev]

dom.w3c_pointer_events.enabled;true
layout.css.touch_action.enabled;true
layers.async-pan-zoom.enabled;true
dom.w3c_touch_events.enabled;1

Comment 13

[Maksim Lebedev]

Did You have a chance to test attached file?

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Not yet, no.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 16

[Maksim Lebedev]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 17

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 18

[Maksim Lebedev]

Some patches ago such behavior have stoped ...on normal windows widget.
But unfortunately on e10s bug can be still reproduced.

Comment 19

[Maksim Lebedev]

(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.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

Great, thanks for checking.