Closed Bug 822558 Opened 7 years ago Closed 7 years ago

TouchEvent.changedTouches[] includes unchanged touches

Categories

(Core :: DOM: Events, defect)

18 Branch
x86
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
B2G C3 (12dec-1jan)
blocking-basecamp +
Tracking Status
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: djf, Assigned: cjones)

Details

(Keywords: regression)

Attachments

(1 file)

Bug #785554 is back in FirefoxOS!

Steps to reproduce:

0) run adb logcat | grep Console
1) Open gallery app
2) Tap on a thumbnail to view an image
3) Put one finger down on the image
4) Put another finger down on the image
5) Lift either one of your fingers

You'll see this message in logcat:

gesture_detector.js: spurious extra changed touch on touchend. See https://bugzilla.mozilla.org/show_bug.cgi?id=785554

This message is from the gesture_detector.js module and it is printed when the module gets a touchend event with two touches in its changedTouches array. But it happened when you lifted just one finger off the screen!  The message dates back to the original bug #785554.

This bug is now also affecting the Gaia keyboard, which has been converted to use multitouch.  See https://bugzilla.mozilla.org/show_bug.cgi?id=806540#c31

To be honest, I'd forgotten that this bug had been fixed. I remember noticing the "spurious extra touch" message in logcat a couple of times last week (or maybe earlier than that).  

Chris: could this regression be related to https://bugzilla.mozilla.org/show_bug.cgi?id=774458 or to any of the recent event work related to that bug?
cc'ing the people who were cc'ed on the original bug, and Margaret, whose keyboard patch is affected by it now.
Keywords: regression
(In reply to David Flanagan [:djf] from comment #0)
> Chris: could this regression be related to
> https://bugzilla.mozilla.org/show_bug.cgi?id=774458 or to any of the recent
> event work related to that bug?

Nope, that code doesn't participate in scrolling in this test case.

I'm now wondering if this regression is independent from bug 814252, but they've conspired together to break things.
(In reply to David Flanagan [:djf] from comment #0)
> Bug #785554 is back in FirefoxOS!
> 
> Steps to reproduce:
> 
> 0) run adb logcat | grep Console
> 1) Open gallery app
> 2) Tap on a thumbnail to view an image
> 3) Put one finger down on the image
> 4) Put another finger down on the image
> 5) Lift either one of your fingers
> 

In addition, we're firing two touchend events for the single finger lift, and both have multiple touches in changedTouches.
I see this in a 12-6 nightly build, so it's not new.
good:
  git://github.com/mozilla/releases-mozilla-aurora
    607313557a95af6b3d56cf8b211237906ed497b3

bad:
  http://git.mozilla.org/releases/gecko
    372f36fb1a5d6428bcba336499abe5c2d0105433

/me gets really scared ...
This still works on m-c, but somehow it has regressed on the branches.  Sigh.
Summary: TouchEvent.changedTouches[] includes unchanged touches again → TouchEvent.changedTouches[] includes unchanged touches on aurora and b2g18
Bug 814252 works just fine on mozilla-central.  I suspect that whatever regressed this bug also caused bug 814252 to break on branches.

That's we need to develop against gecko-18 / b2g18 :(.

So now this blocks a blocker.
Blocks: 814252
blocking-basecamp: --- → +
Priority: -- → P1
Facts here are
 - fix originally landed to m-c
 - fix rode the train to aurora when it was uplifted
 - as of 11/19, regression not in aurora
 - as of the first b2g build made from beta, 11/20, regression in beta
 - regression currently in aurora
 - current m-c is ok

So we have these regression ranges
 - aurora between 11/19 and now
 - beta between last uplift and 11/20.  I think this is the narrower range but need to double check the uplift date.

It's really bizarre that this isn't a problem on current m-c :/.
Looks like the uplift was 11/19 ...
(In reply to Chris Jones [:cjones] [:warhammer] from comment #6)
> good:
>   git://github.com/mozilla/releases-mozilla-aurora
>     607313557a95af6b3d56cf8b211237906ed497b3
> 

More bad things here ... a build made from hg.m.o/aurora from what should be the same commit is bad.  Taking a long time to iron out.
A local build from 

  <project name="gaia" path="gaia" remote="b2g" revision="41b694e189e806b6654d813722dd6d8b2e8d8d4e"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="b3dcea6f682ce40f4ac32d8035f65971dbc2115e"/>

has the regression, but flashing the 11-15 nightly that manifest was made from is clean.  More badness.
Flashing just the gecko build made locally from the manifest is OK.  Same with the gaia build.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #6)
> bad:
>   http://git.mozilla.org/releases/gecko
>     372f36fb1a5d6428bcba336499abe5c2d0105433

Flashing just gecko built from this on top of 11-15 is good.
Target Milestone: --- → B2G C3 (12dec-1jan)
Assigning to Chris for now since he is working on it, let us know if you need this load balanced to someone else by unassigning it.
Assignee: nobody → jones.chris.g
Indeed, this doesn't reproduce with the *most recent* gecko-18 build flashed on top of the 11-15 nightly.  (Yay that old gaia works with new gecko.)

That means either there's a kernel issue or something in the non-gecko environment.

Was anyone who filed regressions against bug 814252 testing with unagi?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #18)
> Was anyone who filed regressions against bug 814252 testing with unagi?

The "'contextmenu' triggers even if scrolling was performed" regression filed as bug 821864 in the e-mail was experienced (by dietrich) and reproduced (by me) on auto-updated unagi.

I just auto-updated to the 20121219070201 nightly on unagi and the 'contextmenu' regression appears to have disappeared.
Good to know, thanks.  Not an otoro/unagi difference.

The regressing patch was backed out, btw.
Aha

 1. Flash 11/15 build.  No bug.
 2. |./flash.sh gecko| for 0e660766a5581caee81cc1def6a098d0d37a9083 (12/19).  No bug.
 3. |make reset-gaia| then reboot for d38689acc60bddc6e54deda688a82e2777e9826c (12/19).  Bug.

Now I reproduce.
 1. Flash 11/15 build and enable console in settings app.  Bug.

So this regressed before the oldest nightly I have.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #10)
>  - current m-c is ok

(Re-checked for sanity and console seems to be enabled by default in latest builds.  Disable+enable doesn't show the "assertion" failure in logcat.  This also matches the observation that bug 814252 didn't regress the same way on m-c.)
The problem exists as of 10/11.
Bug 790454 landed early November. Could it have caused this?
Right now it's looking like bug 785554 didn't actually fix the original problem.

Bug 790454 might actually have *fixed* it ;).
The parent process is lying to the content process

First finger down

I/Gecko   (  526): [526] Starting dispatch of touchstart ...
I/Gecko   (  526):     touch ID 0 (changed? yes)

Second finger down

I/Gecko   (  526): [526] Starting dispatch of touchstart ...
I/Gecko   (  526):     touch ID 1 (changed? yes)
I/Gecko   (  526):     touch ID 0 (changed? no)

Second finger up

I/Gecko   (  526): [526] Starting dispatch of touchend ...
I/Gecko   (  526):     touch ID 0 (changed? yes)
I/Gecko   (  526):     touch ID 1 (changed? yes)

Touch 0 didn't change.
Alas, bug 790454 was uplifted already.
First finger down

I/Gecko   (  605): TOUCH [nsAppShell][605] Starting dispatch of touchstart ...
I/Gecko   (  605):     touch ID 0 (changed? no)
I/Gecko   (  667): TOUCH [TabChild][667] Starting dispatch of touchstart ...
I/Gecko   (  667):     touch ID 0 (changed? yes)

makes sense so far ...  Second finger down

I/Gecko   (  605): TOUCH [nsAppShell][605] Starting dispatch of touchstart ...
I/Gecko   (  605):     touch ID 1 (changed? no)
I/Gecko   (  605):     touch ID 0 (changed? no)
I/Gecko   (  667): TOUCH [TabChild][667] Starting dispatch of touchstart ...
I/Gecko   (  667):     touch ID 1 (changed? yes)
I/Gecko   (  667):     touch ID 0 (changed? no)

still sensical.  Second finger up

I/Gecko   (  605): TOUCH [nsAppShell][605] Starting dispatch of touchend ...
I/Gecko   (  605):     touch ID 1 (changed? no)
I/Gecko   (  667): TOUCH [TabChild][667] Starting dispatch of touchend ...
I/Gecko   (  667):     touch ID 0 (changed? yes)
I/Gecko   (  667):     touch ID 1 (changed? yes)

Gonk widgetry is reporting the right thing (it doesn't have to track changed touches), but something in the DOM code is getting the changed list wrong.
And we have a winner, TabParent is confusing remote content

I/Gecko   (  739): TOUCH [nsAppShell][739] Starting dispatch of touchend ...
I/Gecko   (  739): TOUCH    touch ID 1 (changed? no)
I/Gecko   (  739): TOUCH [TabParent][739] Starting dispatch of touchend ...
I/Gecko   (  739): TOUCH    touch ID 0 (changed? no)
I/Gecko   (  739): TOUCH    touch ID 1 (changed? yes)
I/Gecko   (  811): TOUCH [TabChild][811] Starting dispatch of touchend ...
I/Gecko   (  811): TOUCH    touch ID 0 (changed? yes)
I/Gecko   (  811): TOUCH    touch ID 1 (changed? yes)
I have a fix for this bug (which we should take), but this bug isn't causing bug 814252.
No longer blocks: 814252
blocking-basecamp: + → ?
Priority: P1 → --
Third-party content is affected by this because we will dispatch crazy touch series to them.  It will undoubtedly break like our gallery app did.

The patch is small and safe.
Attachment #694086 - Flags: review?(mwu)
blocking-basecamp: ? → +
(The reason the test didn't fail on m-c was because touch events were completely broken.)
Summary: TouchEvent.changedTouches[] includes unchanged touches on aurora and b2g18 → TouchEvent.changedTouches[] includes unchanged touches
Attachment #694086 - Flags: review?(mwu) → review+
https://hg.mozilla.org/mozilla-central/rev/8cbe2966ec8a
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.