Closed Bug 1249280 Opened 8 years ago Closed 8 years ago

Touch events in several app seems to be badly broken

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Platform:
Unspecified
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla47
Project Flags:
blocking-b2g 2.6?
Tracking Flags:
Tracking Status
firefox47 --- fixed
b2g-master --- verified

People

(Reporter: gerard-majax, Assigned: kats)

References

Details

(Keywords: correctness, regression, smoketest, Whiteboard: [gfx-noted])

Attachments

(5 files, 2 obsolete files)

logs when "back" button does not work
2.89 KB, text/plain
Details
logs when "back" button does work
3.49 KB, text/plain
Details
touch-events.mp4
281.29 KB, video/mp4
Details
fix
1.97 KB, text/plain
Details
MozReview Request: Bug 1249280 - Fix coordinates of APZ-detected gestures when crossing process boundaries. r=kats
58 bytes, text/x-review-board-request
kats
: review+
kats
: checkin+
Details 
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
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
Ok, I have seen this also in Contacts and Calendar
Flags: needinfo?(kchen)
Any suggestions on what I should start to look at/for to start debugging this? Thanks!
Flags: needinfo?(bugmail.mozilla)
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)
(The logging is controlled by #define's at the top of those files, INPQ_LOG and APZCCH_LOG)
Summary: Touch events in SMS app seems to be badly broken → Touch events in several app seems to be badly broken

    
    

    
  


  

    
    

    
  
Here we go with attachment 8720870 [details] and attachment 8720871 [details]: both contains two set of log extract.
Flags: needinfo?(bugmail.mozilla)

    
    

    
  
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)

    
    

    
  

      
      
      
      

        Attached video
          
        touch-events.mp4
        — 
      

    


  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached file
          
        fix
        — 
      

    


  
This is the fix suggested by :kats on IRC. So far with this, I cannot reproduce anymore :)

    
    

    
  
Thanks :kats and :gerard-majax :)
Flags: needinfo?(kchen)

    
    

    
  
Let's take this and try to expose this in a mochitest :)
Assignee: nobody → lissyx+mozillians

    
    

    
  
This affects Windows touch devices with APZ as well. I can repro there and am trying to write a mochitest for it.
blocking-b2g: --- → 2.6?
QA Whiteboard: [QAnalyst-Triage+]
Keywords: smoketest

    
    

    
  
Stealing. I was able to write a test for this on windows e10s.
Assignee: lissyx+mozillians → bugmail.mozilla

        Attachment #8721431 -
        Flags: review?(bugmail.mozilla) → review+

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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)

        Attachment #8721433 -
        Flags: review?(botond)

    
    

    
  
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

        Attachment #8721433 -
        Attachment is obsolete: true

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/22d83ceb4b4c
Status: NEW → RESOLVED
Closed: 8 years ago

          status-firefox47:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47

    
    

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: