Closed
Bug 1249280
Opened 9 years ago
Closed 9 years ago
Touch events in several app seems to be badly broken
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
People
(Reporter: gerard-majax, Assigned: kats)
References
Details
(Keywords: correctness, regression, smoketest, Whiteboard: [gfx-noted])
Attachments
(5 files, 2 obsolete files)
With current mozilla-central git repo, navigating within the SMS app is really hard: it often takes 4-5 touches to be able to do an action. This includes: back button, opening threads, interacting with dialogs. The app is barely usable at all. I have not been able to expose similar issues in other app as much as I could test. A local backout of bug 1020199 does helps
Assignee | ||
Comment 1•9 years ago
|
||
Off the top of my head I don't know why the SMS app would be any different from the other apps, specially with respect to the changes that bug 1020199 made.
Keywords: correctness,
regression
OS: Unspecified → Gonk (Firefox OS)
Whiteboard: [gfx-noted]
Version: unspecified → Trunk
Reporter | ||
Comment 2•9 years ago
|
||
Ok, I have seen this also in Contacts and Calendar
Reporter | ||
Updated•9 years ago
|
Flags: needinfo?(kchen)
Reporter | ||
Comment 3•9 years ago
|
||
Any suggestions on what I should start to look at/for to start debugging this? Thanks!
Flags: needinfo?(bugmail.mozilla)
Assignee | ||
Comment 4•9 years ago
|
||
First thing I would do is enable the logging in gfx/layers/apz/src/InputQueue.cpp and in gfx/layers/apz/util/APZCCallbackHelper.cpp which will provide some useful information on the touch and tap events so we can see what's going on.
Flags: needinfo?(bugmail.mozilla)
Assignee | ||
Comment 5•9 years ago
|
||
(The logging is controlled by #define's at the top of those files, INPQ_LOG and APZCCH_LOG)
Reporter | ||
Updated•9 years ago
|
Summary: Touch events in SMS app seems to be badly broken → Touch events in several app seems to be badly broken
Reporter | ||
Comment 6•9 years ago
|
||
Reporter | ||
Comment 7•9 years ago
|
||
Reporter | ||
Comment 8•9 years ago
|
||
Here we go with attachment 8720870 [details] and attachment 8720871 [details]: both contains two set of log extract.
Flags: needinfo?(bugmail.mozilla)
Assignee | ||
Comment 9•9 years ago
|
||
In both of those logs everything looks normal. In particular the touch events are processed as expected, and we see that the APZCCH is generating mouse events for the tap, so everything up to that point is fine. The coordinates for the tap also look sane assuming a 60px vertical offset between the parent and child process. It could be that the mouse events that are created for the tap are getting lost or not getting to the intended target somehow. My next guess, assuming bug 1020199 was the cause, is that the TakeFocusForClickFromTap mechanism isn't working properly. Can you add some printfs around [1] and in [2] to make sure it is getting called and it is hitting the fm->SetFocus call? There might be a race condition where some focus-related state doesn't get propagated to the child process before the mouse events are actually dispatched. Please leave the logging from INPQ and APZCCH in place so that we can make sure the focus stuff happens in the correct place relative to the other output. [1] http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp?rev=9e71a38057d1#1728 [2] http://mxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp?rev=9e71a38057d1#306
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 10•9 years ago
|
||
This is a video capture of what happens. Matching log:
> 02-18 19:16:23.094 4472 4507 I Gecko : INPQ: discarding depleted touch block 0xa00d1780
> 02-18 19:16:23.094 4472 4507 I Gecko : INPQ: started new touch block 0xa21b8e80 id 52 for target 0xaca7a000
> 02-18 19:16:23.094 4472 4507 I Gecko : INPQ: not waiting for content response on block 0xa21b8e80
> 02-18 19:16:23.094 4472 4507 I Gecko : INPQ: current block is ready with target 0xaca7a000 preventdefault 0
> 02-18 19:16:23.104 5562 5562 I Gecko : APZCCH: For event at (54,66) found scrollable element 0xb0871220 (html@b0871220 lang="fr" dir="ltr" langs="fr en-US")
> 02-18 19:16:23.104 5562 5562 I Gecko : APZCCH: Sending target APZCs for input block 52
> 02-18 19:16:23.104 4472 4507 I Gecko : INPQ: got a target apzc; block=52 guid={ l=6, p=1, v=3 }
> 02-18 19:16:23.114 4472 4507 I Gecko : INPQ: received new event in block 0xa21b8e80
> 02-18 19:16:23.114 4472 4507 I Gecko : INPQ: dropping event due to block 0xa21b8e80 being in mini-slop
> 02-18 19:16:23.114 4472 4507 I Gecko : INPQ: current block is ready with target 0xaca7a000 preventdefault 0
> 02-18 19:16:23.144 4472 4507 I Gecko : INPQ: received new event in block 0xa21b8e80
> 02-18 19:16:23.144 4472 4507 I Gecko : INPQ: dropping event due to block 0xa21b8e80 being in mini-slop
> 02-18 19:16:23.144 4472 4507 I Gecko : INPQ: current block is ready with target 0xaca7a000 preventdefault 0
> 02-18 19:16:23.154 4472 4507 I Gecko : INPQ: received new event in block 0xa21b8e80
> 02-18 19:16:23.154 4472 4507 I Gecko : INPQ: current block is ready with target 0xaca7a000 preventdefault 0
> 02-18 19:16:23.154 4472 4507 I Gecko : INPQ: got a content response; block=52
> 02-18 19:16:23.164 5562 5562 I Gecko : APZCCH: Dispatching single-tap component events to (58,126)
One can observe that while I do tap on the "<" back button (and the color changes), it's like it targets the text input below.
Assignee | ||
Comment 11•9 years ago
|
||
Are you able to tap on things farther down on the screen? I just want to make sure it's not doing something dumb like doubling a scaling factor or translating the point twice. If that were the case then you would never be able to successfully tap on anything near the bottom of the screen.
Reporter | ||
Comment 12•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11) > Are you able to tap on things farther down on the screen? I just want to > make sure it's not doing something dumb like doubling a scaling factor or > translating the point twice. If that were the case then you would never be > able to successfully tap on anything near the bottom of the screen. You might have got a good point. While tapping at bottom exposes the same behavior, it's interesting to suspect that there looks to be a translation of what is being targetted. If you look at the video, you can already see it: back arrow changes color when I tap on it, but then the target seems to the text input (per the cursor and the keyboard showing). If I tap a "Cancel" button in any system dialog message, then I see something similar: color changes from gray to blue and the targets is below.
Assignee | ||
Comment 13•9 years ago
|
||
After some discussion on IRC and digging it looks the code from bug 1020199 removed some calls to AdjustTapToChildWidget so reinstating those should fix the problem.
Reporter | ||
Comment 14•9 years ago
|
||
This is the fix suggested by :kats on IRC. So far with this, I cannot reproduce anymore :)
Reporter | ||
Comment 16•9 years ago
|
||
Let's take this and try to expose this in a mochitest :)
Assignee: nobody → lissyx+mozillians
Assignee | ||
Comment 17•9 years ago
|
||
This affects Windows touch devices with APZ as well. I can repro there and am trying to write a mochitest for it.
Updated•9 years ago
|
Assignee | ||
Comment 19•9 years ago
|
||
Stealing. I was able to write a test for this on windows e10s.
Assignee: lissyx+mozillians → bugmail.mozilla
Assignee | ||
Comment 20•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/35663/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/35663/
Attachment #8721431 -
Flags: review?(bugmail.mozilla)
Assignee | ||
Comment 21•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/35665/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/35665/
Attachment #8721432 -
Flags: review?(jmathies)
Assignee | ||
Comment 22•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/35667/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/35667/
Attachment #8721433 -
Flags: review?(botond)
Assignee | ||
Updated•9 years ago
|
Attachment #8721431 -
Flags: review?(bugmail.mozilla) → review+
Assignee | ||
Comment 23•9 years ago
|
||
Comment on attachment 8721431 [details] MozReview Request: Bug 1249280 - Fix coordinates of APZ-detected gestures when crossing process boundaries. r=kats https://reviewboard.mozilla.org/r/35663/#review32323 I kept Alex as the author of this patch, so r=me
Assignee | ||
Comment 24•9 years ago
|
||
Hm. Well it looks like we can't inject touch events on the windows machines on tryserver, and I forgot Linux and android don't have touch injection code hooked up, so that test isn't going to pass without some more work. I'll land the fix since it's a smoketest blocker and work on getting the test working on some platform.
Assignee | ||
Comment 25•9 years ago
|
||
Comment on attachment 8721432 [details] MozReview Request: Bug 1249280 - Fix synthesized touch injection code on Windows to not apply the scale factor twice. r?jimm Also dropping review on these two patches for now.
Attachment #8721432 -
Flags: review?(jmathies)
Assignee | ||
Updated•9 years ago
|
Attachment #8721433 -
Flags: review?(botond)
Assignee | ||
Updated•9 years ago
|
Attachment #8721431 -
Flags: checkin+
Assignee | ||
Comment 27•9 years ago
|
||
Comment on attachment 8721432 [details] MozReview Request: Bug 1249280 - Fix synthesized touch injection code on Windows to not apply the scale factor twice. r?jimm I'm gonna move the test stuff over to bug 1249915.
Attachment #8721432 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Attachment #8721433 -
Attachment is obsolete: true
Comment 28•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/22d83ceb4b4c
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment 29•9 years ago
|
||
This issue is verified fixed in Flame 2.6 and Aries 2.6. Environmental Variables: Device: Aries 2.6 [Full Flash] BuildID: 20160222133739 Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c Gecko: 789a12291942763bc1e3a89f97e0b82dc1c9d00b Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 47.0a1 (2.6) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:47.0) Gecko/47.0 Firefox/47.0 Device: FlameKK 2.6 [Full Flash][512mb] BuildID: 20160223030219 Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c Gecko: 789a12291942763bc1e3a89f97e0b82dc1c9d00b Gonk: 8a066f7fa7410e32b58def35f322aa33f03db283 Version: 47.0a1 (2.6) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:47.0) Gecko/47.0 Firefox/47.0 Result: Touch events are registering where they are pressed.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-master:
--- → verified
Flags: needinfo?(ktucker)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•