912867 - [B2G][Helix][Gaia][ouyangming]Sometimes can't answer the incoming call when the screen is locked.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect, P1)

Description

[lecky]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; aff-kingsoft-ciba; .NET4.0C; .NET4.0E)

Steps to reproduce:

【Detail Description*】：Sometimes can't answer the incoming call when the screen is locked.
【Repro Steps*】：
   1.press the power key,let the device go to sleep.
    2.Use another device call the test device.
【Expect Result*】：the test device can slip the screen to answer the incoming call always. 
【Real Result*】：Sometime the test device can't slip the screen to answer the incoming call. 
【Test Count*】：10
【Found Count*】：1
【Gaia commit ID*】:c0ea0a4943dc8d3751b07f5b5c5d3abe06364a14
【Gecko commit ID*】: 170f9e477571127cd40997fa2abe262ed43f0e4d
【Log*】：NA
【Network environment】：
【Resume operation】：
【Carrier】：

Comment 1

[Wayne Chang [:wchang]]

QAWANTED on this, please nominate if confirmed.

Comment 2

[lecky]

Dear Beatriz Rodriguez,

If this issue is not solved on V1.1HD, Do you accept it?

Thanks

Comment 3

[Wayne Chang [:wchang]]

William, can you address the qawanted here? (or someone from taipei?)

Comment 4

[Beatriz Rodríguez [:brg]]

Dear Lecky, please investigate this real bug in your side as well becaues it seems to be a touch calibration issue. Maybe in your touch driver which is not fine tuned yet.

Comment 5

[William Hsu [:whsu]]

Hi, Lecky,

I cannot reproduce this bug on latest Mozilla build and commercial build (you provided).
Could you please inform your QA to test this bug on latest build to see if it happen again.
If it happen again, please provide the detailed reproduce step and precondition.
Thanks!


* Test Build:
 + Commercial build (you provided)
  - Gaia:     2a20910ea96efb538ec0c99ff25a540ed641f63f
  - Gecko:   
  - BuildID   20130927201119
  - Version   18.0
  ==> Result: Cannot reproduce

 + Mozilla Build:
  - Gaia:     115ecd143eb3f7f633e624685a0a210214d3f2f0
  - Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/211697c9ba2c
  - BuildID   20131014042201
  - Version   18.0
  ==> Result: Cannot reproduce

Comment 6

[lecky]

Dear William,

Our QA test on the latest HD V1.1 and reproduced this issue. You can try the following steps, Thanks.
Build info as following:
gaia：f601fe6e5edb7d5016c07abfad8f069af7354f7b
gecko：60d9e982e07e8d09e9d0e52bad6433c302c17f32
gonk-misc：ca9192d7ef6037016d4723647d86b72f7a410633

Reproduced steps:
(1)prepare two devices, marker as A and B.
(2)Device A turn off the screen, and let the palm cling with the screen of the device A.
(3)Use the device B to call device A, device A not answer the incoming call, just hold on and let it hangup itself.  
(4)Do the steps 2 and 3 about ten times, 
(5)Use the device B to call the device A, and slip the screen to answer the incoming call this time.

Natural, in step 5 can slip the screen to answer the incoming call. But it can't slip the screen to answer the incoming call high probability on our device. Please see the attached file "can't slip the screen to answer the incoming call.3gp"

If this reproduced, the device can't answer the incoming calls till reboot the device.

Can you try the steps mentioned above to reproduce this issue on V1.1? I'm sure you can reproduced this issue less than five times as doing the step (1) to (5).

Thanks.

Comment 7

[lecky]

Attachment: can't slip the screen to answer the incoming call.3gp

Comment 8

[William Hsu [:whsu]]

Thanks for your reminder!
Got it! I will try to reproduce this bug later.

Comment 9

[lecky]

Dear Wayne,

There is a BUG 815629, it is very similar to this issue, Could you have a look at it?

Thanks.

Comment 10

[Wayne Chang [:wchang]]

(In reply to lecky from comment #6)

> (2)Device A turn off the screen, and let the palm cling with the screen of
> the device A.

The fact that your palm is touching the screen before the screen/touch panel was activated, and then activated via incoming call suggests this being a touch driver issue. You need to be able to calibrate this palm clinging on to screen scenario if this is what you are going to test.

> (3)Use the device B to call device A, device A not answer the incoming call,
> just hold on and let it hangup itself.  
> (4)Do the steps 2 and 3 about ten times, 

Please suggest in what use case would a user be holding on to the phone and ignoring incoming call ten times.



> Can you try the steps mentioned above to reproduce this issue on V1.1? I'm
> sure you can reproduced this issue less than five times as doing the step
> (1) to (5).

Did you do this on a Mozilla build?

Comment 11

[Alan Huang]

(In reply to Beatriz Rodríguez [:brg] from comment #4)
> Dear Lecky, please investigate this real bug in your side as well becaues it
> seems to be a touch calibration issue. Maybe in your touch driver which is
> not fine tuned yet.

Lecky, I believe you can check by "getevent" first. This is a basic tool to check the correctness of different kind of input events.

Comment 12

[Wayne Chang [:wchang]]

removing nomination based on the STR required. Marking POVB

Comment 13

[lecky]

(In reply to Alan Huang [:ahuang] from comment #11)
>Lecky, I believe you can check by "getevent" first. This is a
> basic tool to check the correctness of different kind of input events.

We use the "getevent" and find all the touch points are correctly, "getevent" tool print the correct points direction when the issue occured. So our touch driver is ok.

When the issue occured, it can't slip the screen, the incoming call animation is playing all the while. But it can slip the screen to unlock when it hangup.
Maybe there is somthing wrong with the incoming call animation.

Thanks.

Comment 14

[viral [:viralwang]]

Hi Lecky,

Shall we have getevent log when issue happened?
I know there are huge amount events, please just record as few as you can for the time UI didn't response.
Thanks.

Comment 15

[Alan Huang]

Why ni me?

Comment 16

[lecky]

(In reply to viral [:viralwang] from comment #14)
> Hi Lecky,

>Shall we have getevent log when issue happened?
>I know there are
> huge amount events, please just record as few as you can for the time UI
> didn't response.
>Thanks.

Thanks for help.

We got the events log when the UI didn't response, please refer the attached file "getevent-log.txt".

We trace the code and found that: in \gaia\apps\communications\dialer\js\swiper.js, handleEvent function didn't receive the touchstart/touchmove/touchend events when the UI didn't response.

Thanks.

Comment 17

[lecky]

Attachment: getevent-log.txt

Comment 18

[viral [:viralwang]]

Hi Lecky,

I can only find the touch event below, but it looks like you start to capture events when your finger already on it, right?

/dev/input/event0: 0003 0030 00000006
/dev/input/event0: 0003 0031 00000006
/dev/input/event0: 0003 0034 00000000
/dev/input/event0: 0003 0035 0000015a
/dev/input/event0: 0003 0036 000002e4
/dev/input/event0: 0003 0039 00000000
/dev/input/event0: 0000 0002 00000000
/dev/input/event0: 0000 0000 00000000
/dev/input/event0: 0003 003a 00000039
/dev/input/event0: 0003 0030 00000006
/dev/input/event0: 0003 0031 00000005
/dev/input/event0: 0003 0034 00000000
/dev/input/event0: 0003 0035 0000015f
/dev/input/event0: 0003 0036 000002d0
/dev/input/event0: 0003 0039 00000000
/dev/input/event0: 0000 0002 00000000
/dev/input/event0: 0000 0000 00000000
/dev/input/event0: 0003 003a 00000000
/dev/input/event0: 0003 0030 00000000
/dev/input/event0: 0003 0031 00000000
/dev/input/event0: 0003 0034 00000000
/dev/input/event0: 0003 0035 0000015f
/dev/input/event0: 0003 0036 000002d0
/dev/input/event0: 0003 0039 00000000
/dev/input/event0: 0000 0002 00000000
/dev/input/event0: 0001 014a 00000000
/dev/input/event0: 0000 0000 00000000

Please help to check the code in gecko/widget/gonk/libui/InputReader.cpp to see if gecko can get event or not.
One easy way is to enable debug flag as below:

#define DEBUG_RAW_EVENTS 1

we need to check the log in gecko first to analysis this bug.
Thanks.

Comment 19

[lecky]

Dear Viral,

We got the gecko log, please refer the taached file "Touch_debug_log - 20131113.txt".

It looks like get the events in InputReader.cpp, as following:
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x003a keycode=0x0000 value=0x00000020 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0030 keycode=0x0000 value=0x00000002 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0031 keycode=0x0000 value=0x00000002 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0034 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0035 keycode=0x0000 value=0x0000014f flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0036 keycode=0x0000 value=0x000001ea flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0039 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0000 scancode=0x0002 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): Input event: device=6 type=0x0000 scancode=0x0000 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.989: INFO/GonkCameraControl(155): syncTouch: pointerCount 1 -> 1, touching ids 0x80000000 -> 0x80000000, hovering ids 0x00000000 -> 0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): BatchSize: 10 Count: 10
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x003a keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0030 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0031 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0034 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0035 keycode=0x0000 value=0x0000014f flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0036 keycode=0x0000 value=0x000001ea flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0003 scancode=0x0039 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0000 scancode=0x0002 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0001 scancode=0x014a keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): Input event: device=6 type=0x0000 scancode=0x0000 keycode=0x0000 value=0x00000000 flags=0x00000000
11-13 10:53:33.999: INFO/GonkCameraControl(155): syncTouch: pointerCount 1 -> 0, touching ids 0x80000000 -> 0x00000000, hovering ids 0x00000000 -> 0x00000000

We change the log tag to "GonkCameraControl", please ignore it. When we got the log, our finger move on the screen, but it can't unlock the screen.

Thanks.

Comment 20

[lecky]

Attachment: Touch_debug_log - 20131113.txt

Comment 21

[viral [:viralwang]]

Hi Lecky,

Shall this bug also happened in mozilla gecko/gaia?
We will try to reproduce it in our build and do more analysis.
If you can also help to reproduce it in your side, it will help a lot.
Thanks.

Comment 22

[William Hsu [:whsu]]

Hi, TPE members,

I had a device that can continuously to reproduce this bug.
I think it is a software bug not a hardware issue (Touch sensor).
Because I only cannot swipe the screen to answer the call.

Attaching the video.
Please contact me if you see the message.
Thanks!

Comment 23

[William Hsu [:whsu]]

Attachment: Cannot answer the call

Comment 24

[William Hsu [:whsu]]

Attaching the log. FYI.

Comment 25

[William Hsu [:whsu]]

Attachment: Adb_logcat_20131114

Comment 26

[viral [:viralwang]]

Hi Evelyn,

It looks like home key still working, but not for dialer lockscreen.
Could you please help to check why dialer didn't handle touch event well?
Thanks!

Comment 27

[lecky]

(In reply to viral [:viralwang] from comment #21)
> Hi Lecky,

Shall this bug also happened in mozilla gecko/gaia?
We will try
> to reproduce it in our build and do more analysis.
If you can also help to
> reproduce it in your side, it will help a lot.
Thanks.

Yes,I find the bug in mozilla gecko/gaia.

Comment 28

[Wayne Chang [:wchang]]

Confirmed bug with Evelyn and Viral. We should fix this.

Comment 29

[Evelyn Hung]

A JS error occurs:
E/GeckoConsole( 4011): [JavaScript Error: "TypeError: this.overlay is null" {file: "app://communications.gaiamobile.org/dialer/js/suggestion_bar.js" line: 23}]

Comment 30

[Evelyn Hung]

(In reply to Evelyn Hung [:evelyn] from comment #29)
> A JS error occurs:
> E/GeckoConsole( 4011): [JavaScript Error: "TypeError: this.overlay is null"
> {file: "app://communications.gaiamobile.org/dialer/js/suggestion_bar.js"
> line: 23}]

on master, we fix the bug in bug 869465 six month ago. should we uplift the patch there?

Comment 31

[Wayne Chang [:wchang]]

If it had landed on master that long ago, it should have been included in v1.1HD when it branched, can you find out/confirm the patch 
1> is not already included on v1.1HD
2> fixes this bug

If both are true, dupe this to the old bug and I will HD+ that one for uplifting. But we should know why it isn't there already...

Comment 32

[Evelyn Hung]

(In reply to Wayne Chang [:wchang] from comment #31)
> If it had landed on master that long ago, it should have been included in
> v1.1HD when it branched, can you find out/confirm the patch 
> 1> is not already included on v1.1HD
> 2> fixes this bug
> 
> If both are true, dupe this to the old bug and I will HD+ that one for
> uplifting. But we should know why it isn't there already...

1. no, bug bug 869465 was fixed after branching out and didn't get an approval to uplift.
2. the patch promise there is no JS error like this anymore, if JS error is the root cause of this bug.

Comment 33

[lecky]

Hi Evelyn,

 Do you mean you are not sure whether the patch can fix the bug?

Comment 34

[Wayne Chang [:wchang]]

Lecky,
Can you try the patch from bug 869465 and reproduce this?

Thanks.

Comment 35

[lecky]

Hi Wayne,

   Our oncall.js file(apps/communications/dialer/js/oncall.js) is as follow:
   
line831   window.addEventListener('load', function callSetup(evt) {
line832     window.removeEventListener('load', callSetup);
line833
line834     OnCallHandler.setup();
line835     CallScreen.init();
line836     CallScreen.syncSpeakerEnabled();
line837     KeypadManager.init(true);
line838
line839   });

  The oncall.js of the patch form bug 86965 is follow:
 
        window.addEventListener('load', function callSetup(evt) { 
line723   CallScreen.init(); 
line724   CallScreen.syncSpeakerEnabled(); 
line725   KeypadManager.init(true); 
line726     
line727  }); 

    So I cannot meger the patch.

    Our build:
       Gaia: d5b7a6e3cedb657699748913f437f9a8f7c1d38a

Comment 36

[Evelyn Hung]

(In reply to lecky from comment #33)
> Hi Evelyn,
> 
>  Do you mean you are not sure whether the patch can fix the bug?

The patch fixes the JavaScript error, but we don't know why it runs into that case. However, by tracing the code, we should do this error handling. I will say, picking the patch in bug 869465 won't cause any regression and we should do that.

Comment 37

[Evelyn Hung]

(In reply to lecky from comment #35)
> Hi Wayne,
> 
>    Our oncall.js file(apps/communications/dialer/js/oncall.js) is as follow:
>    
> line831   window.addEventListener('load', function callSetup(evt) {
> line832     window.removeEventListener('load', callSetup);
> line833
> line834     OnCallHandler.setup();
> line835     CallScreen.init();
> line836     CallScreen.syncSpeakerEnabled();
> line837     KeypadManager.init(true);
> line838
> line839   });
> 
>   The oncall.js of the patch form bug 86965 is follow:
>  
>         window.addEventListener('load', function callSetup(evt) { 
> line723   CallScreen.init(); 
> line724   CallScreen.syncSpeakerEnabled(); 
> line725   KeypadManager.init(true); 
> line726     
> line727  }); 
> 
>     So I cannot meger the patch.
> 
>     Our build:
>        Gaia: d5b7a6e3cedb657699748913f437f9a8f7c1d38a

It's just an empty line causing the conflict. Would you please ignore it?

Comment 38

[lecky]

Hi Evelyn ,
  
     Our oncall,js add line832 and line834 than the old build,but the patch has only 1 deletion for oncall,js.If I merge the patch ,i will delete three lines.

Comment 39

[lecky]

Hi Evely,


    Sorry, I can megre the patch.I will try to reproduce the bug later.

Comment 40

[lecky]

Hi Evely,

    I merge the patch and also repoduce the problem.

Comment 41

[lecky]

Attachment: 20131120_Logcat_Log.txt

Comment 42

[Evelyn Hung]

Thanks for trying. Rex will help on finding out the root cause.

Comment 43

[KM Lee [:rexboy] (inactivate after Sep. 22)]

I really can't reproduce it after adding some log dump code last Friday;
William also can't reproduce it until very late evening.
We may need to find a reliable way to reproduce it first.

Comment 44

[lecky]

Hi , Rex,

   The repro steps are as follows:
    
1.press the power key, let the device go to sleep;
2.Put your hand in the screen(this is important) and use another device call the test device;
3.Don't receive the call and let the call disconnect automatically;
   
Do the test followed by the above steps repeatedly(about 20 times), you can reproduce the bug easily. If you have any question, you can ask my colleague, Stone ,to help your to reproduce the bug.

Comment 45

[Evelyn Hung]

Rex, if you are busy because of comms team work week event, feel free to pass this issue to Luke. Thanks.

Comment 46

[William Hsu [:whsu]]

Hi, Rex,

Sorry. I forgot to update the issue.
------------------------------------------------------
Hi, Lecky,

We still cannot easy to reproduce this problem.
In order to save time and effort, we can inject some debug logs on your build and you help us collect the logs.
What do you think?
Thanks!

Comment 47

[lecky]

Hi, William ,

>>>> In order to save time and effort, we can inject some debug logs on your build and you help us collect the logs.
What do you think?
     
  Ok,please tell me how to inject the debug logs?


Thanks

Comment 48

[lecky]

Hi,


   In addtion, give me the command to catch the logs.

Comment 49

[William Hsu [:whsu]]

Hi, Lecky,

Thanks a million!

-------------------------------------------------------------

Hi, Rex,

Could I have your help?
Could you please guide Lecky to inject the debug logs on their build?
I will also do the same thing on my local build to see if I can catch anything.

If you are busy and will pass this issue to Luke, please let me know.
Thanks!

Comment 50

[lecky]

Hi, Rex,

    Can you give the patch which is helpful to find root cause of the bug?

Comment 51

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: log_patch

I made a guess on the cause and inserted some log lines. Please apply the patch.
If we are very lucky, the bug can be solved after applying it.
Otherwise please dump all logcat line containing "communications" and paste it up.

Comment 52

[lecky]

Attachment: 20131126_adb_log.txt

Comment 53

[lecky]

Attachment: communications.txt

The file communications.txt include lines containing "communications".

Comment 54

[lecky]

 Hi, Rex,

     I merged the log_patch in my build,and also reporduced the bug.I attach the logs for you.
 
The logs are as follows in communications.txt:
Line 2705: 11-26 20:19:59.839 E/GeckoConsole(  576): [JavaScript Warning: "HTTP "Content-Type" of "text/html" is not supported. Load of media resource app://communications.gaiamobile.org/dialer/oncall.html failed." {file: "app://communications.gaiamobile.org/dialer/oncall.html#locked" line: 0}]
Line 2705: 11-26 20:19:59.839 E/GeckoConsole(  576): [JavaScript Warning: "HTTP "Content-Type" of "text/html" is not supported. Load of media resource app://communications.gaiamobile.org/dialer/oncall.html failed." {file: "app://communications.gaiamobile.org/dialer/oncall.html#locked" line: 0}]
Line 2707: 11-26 20:19:59.859 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:194 in sw_init: DOMContentLoaded
Line 2709: 11-26 20:19:59.859 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:21 in ls_init: init
Line 2711: 11-26 20:19:59.859 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:22 in ls_init: false
Line 2713: 11-26 20:19:59.859 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:142 in ls_getAllElements: getAllElements
Line 2715: 11-26 20:19:59.869 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:143 in ls_getAllElements: false
Line 2717: 11-26 20:19:59.869 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:165 in ls_setElasticEnabled: setElasticEnabled:true
Line 2719: 11-26 20:19:59.869 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:166 in ls_setElasticEnabled: true
Line 2721: 11-26 20:19:59.869 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:32 in ls_init: init_end
Line 2889: 11-26 20:20:01.349 E/GeckoConsole(  576): [JavaScript Error: "TypeError: this.overlay is null" {file: "app://communications.gaiamobile.org/dialer/js/suggestion_bar.js" line: 23}]
Line 2891: 11-26 20:20:01.799 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:36 in ls_handleEvent: handleEvent:transitionend
Line 2893: 11-26 20:20:01.799 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:37 in ls_handleEvent: true
Line 2895: 11-26 20:20:01.799 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:36 in ls_handleEvent: handleEvent:transitionend
Line 2897: 11-26 20:20:01.799 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:37 in ls_handleEvent: true
Line 2899: 11-26 20:20:01.799 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:36 in ls_handleEvent: handleEvent:transitionend
Line 2901: 11-26 20:20:01.799 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:37 in ls_handleEvent: true
Line 3265: 11-26 20:20:18.449 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:36 in ls_handleEvent: handleEvent:mousedown
Line 3267: 11-26 20:20:18.449 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:37 in ls_handleEvent: true
Line 3393: 11-26 20:20:19.539 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:36 in ls_handleEvent: handleEvent:mousedown
Line 3395: 11-26 20:20:19.539 E/GeckoConsole(  576): Content JS LOG at app://communications.gaiamobile.org/dialer/js/swiper.js:37 in ls_handleEvent: true

Comment 55

[lecky]

Hi, Rex,
  
     Once the device rans into the problem, if we want to recieve a call normally,we must restart the device.

Comment 56

[KM Lee [:rexboy] (inactivate after Sep. 22)]

The log indicated that we received mouseevent rather than touchevent. If it's working in a correct way, we should receive touchstart here rather than mousedown. The correct log should looks like:

handleEvent:transitionend
handleEvent:transitionend
handleEvent:touchstart
handleEvent:touchmove
handleEvent:touchmove
...

but Now it's
handleEvent:transitionend
handleEvent:transitionend
handleEvent:mousedown
(Then nothing happened because it's not designed to handle mouseevent)

But the problem is... I don't think we can solve this problem in Gaia.
Viral do you have any idea or someone we can ask for?

Comment 57

[lecky]

Hi,Rex,
   
>I don't think we can solve this problem in Gaia.

 Yes,I support your opinion.The problem is in Gecko.From my parnter's analysis aboove,we are sure the Gecko can receive the touch event, but don't dipatch the event to gaia, so we doubt that the touch event is lose in Gecko.
 
 The important point is that analyse what lead to the touch event lose.


Thanks

Comment 58

[Evelyn Hung]

redirect to Alphan, maybe he can provide some information.

Comment 59

[viral [:viralwang]]

Hi Lecky,

I didn't see idc file in your device, I expect there should be a file system/usr/idc/synaptics.idc
some information like:

touch.deviceType = touchScreen

Shall this bug still happened if we have idc included?

Comment 60

[Wayne Chang [:wchang]]

Lecky, can you try to reproduce this after including the idc file mentioned in comment 59 on the device?

Comment 61

[lecky]

Hi Wayne,

    I add the file synaptics.idc on the device in dir system/usr/idc/  and aslo reproduce it.

Comment 62

[lecky]

(In reply to viral [:viralwang] from comment #26)

>Could you please help to check why dialer didn't handle touch event well?
 
 The dialer cannot receive the touch event.

Comment 63

[lecky]

Hi, Viral,


     I add the log in fucntion sendTouchEvent().When the problem takes place, we can see the value of msg is as fllowing:

  the msg is 5200(msg = NS_TOUCH_START)
  the msg is 5201(msg = NS_TOUCH_MOVE)
  the msg is 5201(msg = NS_TOUCH_MOVE)
        ...
  the msg is 5202(NS_TOUCH_END)

Comment 64

[lecky]

Hi, Viral,

    I doubt the problem is in nsWindow::DispatchInputEvent(event,captured)(in function adedTouchEvent()).

Comment 65

[lecky]

   
Sorry. I doubt the problem is in nsWindow::DispatchInputEvent(event,captured)(in function sendTouchEvent()).

Comment 66

[viral [:viralwang]]

Hi Lecky,

Please allow me to confirm the bug. (please confirm you use our code base in your testing)

Q1) When issue reproduce, we can see sendTouchEvent() still working in dialer and all other apps(like status bar)

Q2) when issue happened, the only way to recover is to reboot device, otherwise we can not answer phone anymore.

Q3) I'm worried about the message transaction got some problems.

Here's the log I would like to add

========================================
diff --git a/dom/ipc/TabParent.cpp b/dom/ipc/TabParent.cpp
index d56da7c..25f8214 100644
--- a/dom/ipc/TabParent.cpp
+++ b/dom/ipc/TabParent.cpp
@@ -728,6 +732,8 @@ bool TabParent::SendRealTouchEvent(WidgetTouchEvent& event)
 
   MapEventCoordinatesForChildProcess(mChildProcessOffsetAtTouchStart, &e);
 
+  LOG("Status: %d", e.message);
+
   return (e.message == NS_TOUCH_MOVE) ?
     PBrowserParent::SendRealTouchMoveEvent(e, guid) :
     PBrowserParent::SendRealTouchEvent(e, guid);
========================================

Please help to check the log here still working even issue reproduce.

Q4) is there any possible that you can add some logs in status bar to see what event type status bar received when issue happened?

Thanks.

Comment 67

[lecky]

Hi, Viral,

    The codes in my build is not the same as the codes which you give.I used the build is moz branch v1.1. I also add the log in similar place.If you have question you can ask help for my panter.

   Output Log 
   ==================================
   Status: 5200
   Status: 5201
   Status: 5201
       ...
   Status: 5201
   Status: 5202
   
 From the log, maybe the proble is not here.

Comment 68

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Deassign myself for now since this doesn't seems like a Gaia bug.

Please ni? me if needed.

Comment 69

[viral [:viralwang]]

Hi Lecky,

Now we confirm event is sent and need to check who receive the touch events.
/gecko/dom/ipc/TabParents.cpp

bool TabParent::SendRealTouchEvent(WidgetTouchEvent& event)
+ LOG("Touch Send: %d", e.message);

/gecko/dom/ipc/TabChild.cpp
TabChild::RecvRealTouchEvent(const WidgetTouchEvent& aEvent,
                             const ScrollableLayerGuid& aGuid)
+ LOG("Touch Receive: %d", aEvent.message);

Please check the pid of the process who receive the touch event.

Comment 70

[lecky]

Hi, Viral,

    How can I to check the pid of process?

Comment 71

[lecky]

(In reply to viral [:viralwang] from comment #69)

Hi, Viral,
 The logs are as following:

 Output Log
 =====================================
 Touch Send: 5200
 Touch Receive : 5200
 Touch Send: 5201
 Touch Receive : 5201
 ...
 Touch Send: 5201
 Touch Receive : 5201
 Touch Send: 5202
 Touch Receive : 5202

Comment 72

[lecky]

 
 The logcat log:
 ======================================================================
11-29 16:06:28.969 E/Gonk    (  186): chengchangying Touch Receive 5200 
11-29 16:06:28.969 E/Gonk    (  521): chengchangying Touch Receive: 5200
11-29 16:06:28.989 E/Gonk    (  186): chengchangying Touch Receive 5201 
11-29 16:06:28.989 E/Gonk    (  521): chengchangying Touch Receive: 5201
                             ...                                                 
11-29 16:06:32.039 E/Gonk    (  186): chengchangying Touch Receive 5201 
11-29 16:06:32.039 E/Gonk    (  521): chengchangying Touch Receive: 5201
11-29 16:06:32.049 E/Gonk    (  186): chengchangying Touch Receive 5202 
11-29 16:06:32.059 E/Gonk    (  521): chengchangying Touch Receive: 5202

b2g-info
=========================================================================                                                     
                         |     megabytes    |                
           NAME PID NICE  USS  PSS  RSS VSIZE OOM_ADJ USER   
            b2g 186    0 52.5 55.6 66.5 228.4       0 root   
          Usage 450   18  9.8 12.1 22.0  65.9       6 app_450                       
     Homescreen 456   18 12.7 15.2 25.6  71.9       4 app_456
 Communications 521   18 24.7 27.4 38.0  88.2       6 app_521
(Preallocated a 578   18  7.7  9.7 18.6  62.8       6 root   
                                                             
System memory info:                                          
                                                             
            Total 373.8 MB                                   
     Used - cache 130.7 MB                                   
  B2G procs (PSS) 120.1 MB                                   
    Non-B2G procs  10.6 MB                                   
     Free + cache 243.1 MB                                   
             Free 146.6 MB                                   
            Cache  96.5 MB                                   
                                                             
Low-memory killer parameters:                                
                                                             
  notify_trigger 10240 KB                                    
                                                             
  oom_adj min_free                                           
        0  8192 KB                                           
        1 10240 KB                                           
        2 12288 KB                                           
        3 14336 KB                                           
        4 20480 KB                                           
        6 40960 KB

Comment 73

[lecky]

Hi viral,


      From the log we can find the communcitons app receive the touch event, but I don't know why it is not handled in swiper.js( handleEvent: function ls_handleEvent(evt) ).
     This is my own opinion,you can ask my partner to discuss it .


Thanks.

Comment 74

[Luke Chang [:lchang] (inactive)]

We found the 100% reproducible steps as follows:

1. lock the screen
2. make an incoming call
3. use two fingers to tap and hold the top line of the "area" element
4. drag that line up or down a little bit and still hold with two fingers
5. wait for the incoming call hanging up
6. release two fingers when you confirm that the "oncall" page is closed and lockscreen is back
7. make another incoming call and you'll see this bug

When this symptom occurs, you can tap anywhere on the "oncall" page with two fingers and this bug will be recovered.

I still have no idea why this issue happens but now we can make sure that the whole window of both dialer/index.html and dialer/oncall.html don't receive any touch events at that time.

Comment 75

[Wayne Chang [:wchang]]

More findings with a different STR:

1. Launch dialer
2. make an incoming call
3. touch the incoming call attention screen with two fingers and hold fingers on screen
4. hang up at the remote calling party
5. hold fingers from step 3 until the attention screen disappears

From here, the dialer's number pad doesnt work, call history scrolling doesnt work, subsequent incoming attention screen doesn't receive touches, however all other clicks still work.

Recoverable with doing any multi-touch gesture in the dialer app, or kill and relaunch dialer app.

Comment 76

[viral [:viralwang]]

Attachment: touch.patch

Hi Lecky,

Can you help also try this patch in your side?
Thanks.

Comment 77

[lecky]

Hi, viral,

  We megered the patch and can not reproduce the bug.But find an another problem, when a call is coming,we touch the screen first, the device do noting. We must touch the screen secondly to expand the incoming call attention screen.
  Could you give us some advive(or some special scenes) for testing the pach to reduce risking?


Thanks

Comment 78

[Wayne Chang [:wchang]]

(In reply to lecky from comment #77)
> Hi, viral,
> 
>   We megered the patch and can not reproduce the bug.But find an another
> problem, when a call is coming,we touch the screen first, the device do
> noting. We must touch the screen secondly to expand the incoming call
> attention screen.


This is a different problem and also exists without Viral's patch. This is a much more minor problem and we should not consider blocking with this here. Viral has a follow up bug for this which we'll address in a future release.

Comment 79

[Wayne Chang [:wchang]]

Viral provided a patch here as a short term workaround which we will not likely land, lets track this problem in bug 946164 for ongoing releases as this problem goes deeper than what we had expected. Removing blocking status.

Comment 80

[mac]

I can confirm the bug on Alcatel One Touch Fire (hamachi) on b2g 1.4 built by myself on 12/29/13.

STR:
1. Phone is locked, screen is turned off.
2. Incoming call occurs.
3. Unlock screen, tap on top to get into incoming call bar on the bottom.
4. Incoming call bar on the bottom doesn't react for swipe in any direction but everything except the incoming bar works properly and answer for gestures.

Comment 81

[Yorik van Havre]

Attachment: screenshot showing bu 912867.jpg

Comment 82

[Yorik van Havre]

Hi there,

I still experience the same problem on Alcatel One Touch Fire (hamachi) with b2g 2.5 compiled 3 weeks ago (have had this bug since 1.3 or so).

Same symptoms as above, with also the following particularities (see attachment "screenshot showing bug 912867.jpg"):

- As far as I could test, this bug only happens when the caller calls from a cellphone, if the call comes from a landline the bug doesn't occur
- The caller name and number don't appear on the call screen (see screenshot). But as soon as the caller hangs out, the caller name correctly appears in the notifications, and in the missed calls list.
- The time switches back to 12h mode (I have it configured to 24h), only on the call screen (continues normal after it closes)

Comment 83

[Yorik van Havre]

Not sure this is the same for others, but I found the cause of the issue in my case: the Openwall application. Uninstalling it solves the problem. Reinstalling it makes the problem happen again, uninstalling it again makes the problem disappear again.

Apparently the app locks the contact list somehow (the contact image should appear on the screenshots I submitted in comment 81, actually...) It could maybe explain why the bug didn't happen with a call from a landline...

Should still test further, but so far everything seems to work normally again.

Comment 84

[Yorik van Havre]

Sorry, typo in my last message... The app is Openwapp, not Openwall...

Comment 85

[omega_canta]

@Yorik

I also have a Hamachi with the same problem since v2. I never installed "Openwapp". Is it some kind of system app?

Comment 86

[Yorik van Havre]

The problem happened again for me today, without openwapp (it is a messaging application) and from a landline, so my two suspects above are invalid. Sorry for the false alarm...

The calling number always fails to display on the call screen when this problem occurs (the screen is blank) so it might still have something to do with the contacts app...

Comment 87

[omega_canta]

Please note there are other bugs regarding this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1111710

https://bugzilla.mozilla.org/show_bug.cgi?id=1116730

https://bugzilla.mozilla.org/show_bug.cgi?id=1074379


I think we should group into this one, as it's older and has your screenshot showing the problem.

I can confirm this problem with my Hamachi (Alcatel One Touch Fire) in every v2+ (from 2.0 to 2.5).

Comment 88

[BMO Automation]

Firefox OS is not being worked on