If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Flame][Dialer]The device doesn't display some of the emergency phone number on call view

RESOLVED DUPLICATE of bug 1149555

Status

Firefox OS
Gaia::Dialer
RESOLVED DUPLICATE of bug 1149555
3 years ago
3 years ago

People

(Reporter: SandKing, Unassigned)

Tracking

(Depends on: 1 bug, {regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(b2g-v2.0 unaffected, b2g-v2.1 affected, b2g-v2.1S affected, b2g-v2.2 unaffected, b2g-master unaffected)

Details

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
Created attachment 8549483 [details]
Bug video: 1114.mp4

[1.Description]:
[Flame][v2.1][Dialer]When user retart the device and call the emergency number "911" , the device doesn't display the phone number.
Bug log:"logcat_1114.txt"
Bug video:"1114.mp4"
Found Time: 11:14

[2.Testing Steps]: 
1.  Launch "Phone".
2.  Input "911" and call out.
Note: "110","119", "999","112" are OK.


[3.Expected Result]: 
2. The device should display the emergency phone number.

[4.Actual Result]: 
2. The device doesn't display the phone number(911).

[5.Reproduction build]: 
Flame 2.1:
Gaia-Rev        6957ac8a322234ec99c8abb7cc18dc6a2e0176db
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6600eba54256
Build-ID        20150114001300
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150114.035135
FW-Date         Wed Jan 14 03:51:46 EST 2015
Bootloader      L1TC000118D0

Flame 2.2:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/748b20315f75
Build-ID        20150114002502
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150114.040029
FW-Date         Wed Jan 14 04:00:40 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test
(Reporter)

Comment 1

3 years ago
Created attachment 8549488 [details]
Bug log: logcat_1114.txt

Comment 2

3 years ago
[Blocking Requested - why for this release]:

This seems a regression bug and bad user experience.
Thanks.
blocking-b2g: --- → 2.1?
Flags: needinfo?(jlorenzo)
Triage: The dialer lacks consistency in a case which is really important for a user.

QA wanted to check 2.0.
blocking-b2g: 2.1? → 2.1+
Flags: needinfo?(jlorenzo)
Keywords: qawanted
On Flame 2.1 the bug only occurs on the first try after flashing/rebooting the device. It won't occur on subsequent tries, and it won't occur if user has called another number prior to calling 911 after a reboot.

Issue does NOT reproduce on Flame 2.0. The call screen correctly shows '911'. Repro rate: 0/4, with rebooting device between each attempt.

Device: Flame 2.0 (shallow flash, 319MB mem)
BuildID: 20150116081702
Gaia: 736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko: 316fc887675c
Version: 32.0 (2.0)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

--------

Also confirmed 3.0 is unaffected.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → unaffected
status-b2g-master: --- → unaffected
Flags: needinfo?(ktucker)
Keywords: qawanted → regression
Let's get a regression window.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng
(Reporter)

Comment 6

3 years ago
Hi Ktucker,
This issue still exists on oldest(for our side) Flame2.1,

Flame 2.1 build:
Gaia-Rev        7ef2e1e59637a34ca4489c329b3bdee93df3ac6c
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/e3d495eb85c6
Build-ID        20141008161201
Version         34.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141008.195811
FW-Date         Wed Oct  8 19:58:25 EDT 2014
Bootloader      L1TC000118D0
Flags: needinfo?(ktucker)

Comment 7

3 years ago
Hi! Evelyn,

Could someone of your team take a look? Thanks

--
Keven
Flags: needinfo?(ehung)
Sean, do you have time to check this bug? Thanks
Flags: needinfo?(ehung) → needinfo?(selee)
Hi SandKing,

Here is STR:
1. Restart the phone.
2. Launch "Phone".
3. Input "110" and call out.
4. No emergency phone number '110' is shown.

If another emergency phone call is dialed again without rebooting the device, the emergency phone number is shown correctly.
The first emergency phone number will not be shown, so I think this issue will not depend on a specific emergency phone number.

Could you help to confirm the behavior above?

Thank you.
Flags: needinfo?(selee)
Flags: needinfo?(wangxin)
(Reporter)

Comment 10

3 years ago
Hi Sean,
You are right, Phenomenon and STR are correct. Indeed, you needs to restart device, and call the first time.
Flags: needinfo?(wangxin) → needinfo?(selee)
Assignee: nobody → selee
Flags: needinfo?(selee)
Created attachment 8552257 [details]
Trail Patch for v2.1

Hi Douglas,

This issue is caused by race condition, and there is a solution at function formatPhoneNumber in handled_call.js in my trail patch.
I think this.numberNode.textContent and this._cachedInfo should be always the same content when replacePhoneNumber function is called, because restorePhoneNumber need _cachedInfo to restore the correct value back.

So here is the correct code sequence: 
    this.numberNode.textContent = phoneNumber;
    this._cachedInfo = phoneNumber;
    this.formatPhoneNumber(ellipsisSide);

Here is our exist code which is an INCORRECT sequence:
    this.numberNode.textContent = phoneNumber;
    this.formatPhoneNumber(ellipsisSide);
    this._cachedInfo = phoneNumber;

You can see the following log that formatPhoneNumber will be called by replacePhoneNumber and restorePhoneNumber .
Once this.numberNode.textContent and this._cachedInfo are not the same content, another formatPhoneNumber called will make the content of numberNode.textContent as empty string (which is assigned at this._cachedInfo = ''; line 28 ).

handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680312
handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680312
handled_call.js:284 in hc_replacePhoneNumber: DEBUG_LOG replacePhoneNumber
handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680578
handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680643
handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680643
handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680650
handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680650
handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680578
handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216683890
handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216683890

May I have your suggestions?
Thank you.
Attachment #8552257 - Flags: feedback?(drs.bugzilla)
2.1 Aurora branch regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140904101238
Gaia: cae91d4ade9e4ac83ddb59abe0b9920361803348
Gecko: 72d40c69f3b0
Version: 34.0a2 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140904112239
Gaia: 01bb4c77f4a3672b9f8d939c125f5724840590ce
Gecko: c1e0cea51571
Version: 34.0a2 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: 01bb4c77f4a3672b9f8d939c125f5724840590ce
Gecko: 72d40c69f3b0

First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: cae91d4ade9e4ac83ddb59abe0b9920361803348
Gecko: c1e0cea51571

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/cae91d4ade9e4ac83ddb59abe0b9920361803348...01bb4c77f4a3672b9f8d939c125f5724840590ce

Caused by the patch for bug 1061012.
QA Whiteboard: [QAnalyst-Triage?]
Keywords: regressionwindow-wanted
Etienne, could you take a look at this please? Looks like the work done on bug 1061012 might have caused this issue.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(etienne)
Comment on attachment 8552257 [details]
Trail Patch for v2.1

(In reply to Sean Lee [:seanlee] from comment #11)
> May I have your suggestions?
> Thank you.

I'm not sure what fixed this on v2.2 off the top of my head, but it may be bug 977056. Rather than doing more investigation and thinking, I would suggest bisecting on v2.2 to see what fixed it, and then considering uplifting that to v2.1.

I'm clearing Etienne's needinfo because we're not going to fix this by backing out bug 1061012. I also don't think that he is the best person to work on this, knowing that it's fixed on v2.2.
Flags: needinfo?(etienne)
Attachment #8552257 - Flags: feedback?(drs.bugzilla) → feedback-
Hi Douglas,

I test the issue with the patch in bug 1061012 on gecko v2.2 and v2.1 .
The issue can not be reproduced on gecko v2.2 but v2.1 .

The strange behavior mentioned at comment 11 can not be reproduced on gecko v2.2 .
When this line ( var viewFont = computedStyle.fontFamily; [1] ) is executed, the resize event will be triggered immediately.
I think the event should be put in the event queue rather than triggering it.

[1] https://github.com/weilonge/gaia/blob/v2.1/shared/js/dialer/font_size_manager.js#L75
[2] https://github.com/weilonge/gaia/blob/v2.1/apps/callscreen/js/calls_handler.js#L365
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #14)
> I'm not sure what fixed this on v2.2 off the top of my head, but it may be
> bug 977056. Rather than doing more investigation and thinking, I would
> suggest bisecting on v2.2 to see what fixed it, and then considering
> uplifting that to v2.1.

Just FYI, before I posted the window at comment 12 I've already looked into finding the fixed window. The problem is, in Central 2.2 the behavior is different when it got fixed.

The timeline of behaviors in Central looks roughly like this:

Bug 1121882 --> Another Bug --> Fixed (now)

So if you want a fixed window you'll be looking at a fix from another bug and NOT from this bug 1121882. That's why I chose to find the actual regression window in 2.1.

Comment 17

3 years ago
Any progress with this issue?

Comment 18

3 years ago
This issue does not exist on wooduck2.0M flame2.0  flame2.1 Dolpin2.1S flame2.2 flame 3.0
Build ID               20150301000203
Gaia Revision          366aaa19ac474dc58b79d62a91cff41756ae9dfe
Gaia Date              2015-02-22 20:25:01
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/1bd33f5447d2
Gecko Version          32.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150301.034812
Firmware Date          Sun Mar  1 03:48:22 EST 2015
Bootloader             L1TC000118D0

Flame 3.0:
Build ID               20150301010223
Gaia Revision          f34ce82a840ad3c0aed3bfff18517b3f6a0eb37f
Gaia Date              2015-02-27 15:48:31
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/eea6188b9b05
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150301.045059
Firmware Date          Sun Mar  1 04:51:10 EST 2015
Bootloader             L1TC000118D0

Woodduck
Build ID               20150302050313
Gaia Revision          a1b5959728c8bc2a82354e197bb161922d419866
Gaia Date              2015-02-13 09:00:02
Gecko Revision         d9b299dc1087f23c83321b4dccc92e0f52309e8e
Gecko Version          32.0
Device Name            jrdhz72_w_ff
Firmware(Release)      4.4.2
Firmware(Incremental)  1425243887
Firmware Date          Mon Mar  2 05:05:08 CST 2015

Flame 2.1
Build ID               20150301001349
Gaia Revision          5d3479fdd438412adee4452720856b6b771fe5cd
Gaia Date              2015-02-25 18:20:09
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9bf4c663241f
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150301.034808
Firmware Date          Sun Mar  1 03:48:19 EST 2015
Bootloader             L1TC000118D0

FLame2.2:
Build ID               20150301002505
Gaia Revision          77609916ca5ab721150fab2b7bc5c37f43ee3a5a
Gaia Date              2015-02-27 16:35:06
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/27ab8aa34201
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150301.040042
Firmware Date          Sun Mar  1 04:00:53 EST 2015
Bootloader             L1TC000118D0
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 19

3 years ago
Created attachment 8571711 [details]
Fail log: logcat.txt

Hi Mike,
This bug still exists on latest Flame 2.1 and Dolphin 2.1s(512M),
STR:
1. Insert SIM card.
2. Restart device.
3. Launch Phone.
4. Call "911".
**You can see the device doesn't display the phone number(911).
See latest log:"logcat.txt".
See video:"verify.mp4"
Found Time: 09:54

Flame 2.1 build: 
Build ID               20150302001220
Gaia Revision          5d3479fdd438412adee4452720856b6b771fe5cd
Gaia Date              2015-02-25 18:20:09
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9bf4c663241f
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150302.035532
Firmware Date          Mon Mar  2 03:55:42 EST 2015
Bootloader             L1TC000118D0

Dolphin 2.1S_512 version:
Build ID               20150302001206
Gaia Revision          a43d64ae01ef108aa4dcc971c770fecd8416a764
Gaia Date              2015-02-26 09:24:39
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2437280c634f
Gecko Version          34.0
Device Name            scx15_sp7715ea
Firmware(Release)      4.4.2
Firmware(Incremental)  122
Firmware Date          Thu Feb  5 12:42:58 CST 2015
Flags: needinfo?(mlien)
(Reporter)

Comment 20

3 years ago
Created attachment 8571713 [details]
Fail video: Verify.mp4
(Reporter)

Updated

3 years ago
Status: RESOLVED → REOPENED
status-b2g-v2.1S: --- → affected
Resolution: WORKSFORME → ---

Comment 21

3 years ago
wait for developer's reply
Flags: needinfo?(mlien)
Based on my comment 11 and comment 15, I suspect the root cause is that the unexpected behavior of resize event is not sent at next tick. Can some Gecko guys help to see this issue?

However, I've provided a trail patch attachment 8552257 [details] of Gaia.
This is a workaround to fix the unexpected behavior of resize event.

I will take the issue later after confirming how to approach this issue.

Thank you.
Assignee: selee → nobody
Hi Vincent,

Could you help to see the issue? Thank you!
Flags: needinfo?(vliu)

Comment 24

3 years ago
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #14)

> I'm not sure what fixed this on v2.2 off the top of my head, but it may be
> bug 977056. Rather than doing more investigation and thinking, I would
> suggest bisecting on v2.2 to see what fixed it, and then considering
> uplifting that to v2.1.
> 

From the bug observation, it seems that we can also asking for a reverse regression window to get help from QA.
Keywords: regression → qawanted
(In reply to Vincent Liu[:vliu] from comment #24)
> From the bug observation, it seems that we can also asking for a reverse
> regression window to get help from QA.

Please read comment 16. I can find a fixed window as long as we are all aware of the fact on comment 16.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
Keywords: regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)

Comment 26

3 years ago
(In reply to Pi Wei Cheng [:piwei] from comment #12)
> 2.1 Aurora branch regression window:
> 
> Last Working Environmental Variables:
> Device: Flame
> BuildID: 20140904101238
> Gaia: cae91d4ade9e4ac83ddb59abe0b9920361803348
> Gecko: 72d40c69f3b0
> Version: 34.0a2 (2.1)
> Firmware: V18D-1
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
> 
> First Broken Environmental Variables:
> Device: Flame
> BuildID: 20140904112239
> Gaia: 01bb4c77f4a3672b9f8d939c125f5724840590ce
> Gecko: c1e0cea51571
> Version: 34.0a2 (2.1)
> Firmware: V18D-1
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
> 
> First Broken Gaia & Last Working Gecko - issue DOES repro
> Gaia: 01bb4c77f4a3672b9f8d939c125f5724840590ce
> Gecko: 72d40c69f3b0
> 
> First Broken Gecko & Last Working Gaia - issue does NOT repro
> Gaia: cae91d4ade9e4ac83ddb59abe0b9920361803348
> Gecko: c1e0cea51571
> 
> Gaia pushlog:
> https://github.com/mozilla-b2g/gaia/compare/
> cae91d4ade9e4ac83ddb59abe0b9920361803348...
> 01bb4c77f4a3672b9f8d939c125f5724840590ce
> 
> Caused by the patch for bug 1061012.

Hi! Sean,

Could you confirm that this issue is caused by patch of bug 1061012? Thanks

--
Keven
Flags: needinfo?(selee)
Hi Keven,

Thanks for your concern.
========================================================
--- Can be REPRODUCED ---
commit 01bb4c77f4a3672b9f8d939c125f5724840590ce
Author: Etienne Segonzac <etienne@segonzac.info>
Date:   Mon Sep 1 16:57:09 2014 +0200

    Bug 1061012 - Fixing the callscreen window visibility and preventing the creation of an audio context at preload.
========================================================
--- Can NOT be REPRODUCED ---
commit cae91d4ade9e4ac83ddb59abe0b9920361803348
Author: Guilherme Goncalves <guilherme.p.gonc@gmail.com>
Date:   Fri Aug 29 13:27:45 2014 -0300

    Bug 1058330 - Use the 'geolocation-noprompt' permission in Find My Device r=mgoodwin
========================================================

And it's caused by the line:
diff --git a/apps/system/js/callscreen_window.js b/apps/system/js/callscreen_window.js
index 8f5d0fe..53de0db 100644
--- a/apps/system/js/callscreen_window.js
+++ b/apps/system/js/callscreen_window.js
@@ -155,6 +155,7 @@
     setTimeout(function nextTick() {
       this.browser.element.src = src;
     }.bind(this));
+    this.setVisible(false);
   };

But I think this line is to fix the problem discussed at bug 1061012 comment 6.

Hi Etienne,

Could you help to give some suggestions if we can remove the line in my above comment?
Thank you.
Flags: needinfo?(selee) → needinfo?(etienne)
Redirect Etienne's NI to Alive.

Hi Alive,

Could you help to give some suggestions if we can remove the line in my above comment?
Thank you.
Flags: needinfo?(etienne) → needinfo?(alive)
Uh, I don't think it's related to this issue... Etienne?

BTW, could you explain why removing it fixing your problem?
Flags: needinfo?(alive) → needinfo?(etienne)
Hi Alive,

This bug is reproduced at 01bb4c77f4a3672b9f8d939c125f5724840590ce (commit for bug 1061012).
After removing this.setVisible(false);, this bug is fixed.
I have no idea why this line can fix this issue.
(In reply to Sean Lee [:seanlee] from comment #27)
> Hi Keven,
> 
> Thanks for your concern.
> ========================================================
> --- Can be REPRODUCED ---
> commit 01bb4c77f4a3672b9f8d939c125f5724840590ce
> Author: Etienne Segonzac <etienne@segonzac.info>
> Date:   Mon Sep 1 16:57:09 2014 +0200
> 
>     Bug 1061012 - Fixing the callscreen window visibility and preventing the
> creation of an audio context at preload.
> ========================================================
> --- Can NOT be REPRODUCED ---
> commit cae91d4ade9e4ac83ddb59abe0b9920361803348
> Author: Guilherme Goncalves <guilherme.p.gonc@gmail.com>
> Date:   Fri Aug 29 13:27:45 2014 -0300
> 
>     Bug 1058330 - Use the 'geolocation-noprompt' permission in Find My
> Device r=mgoodwin
> ========================================================
> 
> And it's caused by the line:
> diff --git a/apps/system/js/callscreen_window.js
> b/apps/system/js/callscreen_window.js
> index 8f5d0fe..53de0db 100644
> --- a/apps/system/js/callscreen_window.js
> +++ b/apps/system/js/callscreen_window.js
> @@ -155,6 +155,7 @@
>      setTimeout(function nextTick() {
>        this.browser.element.src = src;
>      }.bind(this));
> +    this.setVisible(false);
>    };
> 
> But I think this line is to fix the problem discussed at bug 1061012 comment
> 6.
> 
> Hi Etienne,
> 
> Could you help to give some suggestions if we can remove the line in my
> above comment?
> Thank you.

We can't regress bug 1061012 (keep an audiocontext alive, drain the battery etc...) just to fix a race condition in the callscreen code, especially since this race was apparently fixed at some point.
My suggestion is to find which callscreen patch fixed it.
Flags: needinfo?(etienne)
Hi Etienne,

Before finding the callscreen patch fixed it, could you take a look my patch attachment 8552257 [details] which can fix this issue?
My concept is based on my previous comment 11 and comment 15.
Thank you.
Flags: needinfo?(etienne)
Hi Etienne,

I explain the log that I provided before. Wish this could be helpful to see my comments. :)

IMHO, these two lines should be executed in the same tick, and 'tag' is to mark that they are in pair. 
console.log('DEBUG_LOG formatPhoneNumber START ' + tag);
console.log('DEBUG_LOG formatPhoneNumber END ' + tag);

If there is any formatPhoneNumber START/END log which are not at adjacent sequence, I think this could be the problem.
[NG] is marked for saying this log could be the problem. Please see below:

handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
[OK] handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680312
[OK] handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680312
handled_call.js:284 in hc_replacePhoneNumber: DEBUG_LOG replacePhoneNumber
[NG] handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680578
handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
[OK] handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680643
[OK] handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680643
handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
[OK] handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216680650
[OK] handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680650
[NG] handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216680578
handled_call.js:291 in hc_restorePhoneNumber: DEBUG_LOG restorePhoneNumber
[OK] handled_call.js:249 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber START 1421216683890
[OK] handled_call.js:277 in hc_formatPhoneNumber: DEBUG_LOG formatPhoneNumber  END  1421216683890

Please correct me if there is anything wrong.
Thank you.
(In reply to Sean Lee [:seanlee] from comment #32)
> Hi Etienne,
> 
> Before finding the callscreen patch fixed it, could you take a look my patch
> attachment 8552257 [details] which can fix this issue?
> My concept is based on my previous comment 11 and comment 15.
> Thank you.

Doug already feedback'ed this one. So I'll let him to it.
But yes I think the fix is probably in this area.
Flags: needinfo?(etienne) → needinfo?(drs.bugzilla)

Comment 35

3 years ago
Hi! Doug,

No update for a while.
Any feedback from you? Thanks
Thanks

--
Keven

Comment 36

3 years ago
(In reply to Sean Lee [:seanlee] from comment #23)
> Hi Vincent,
> 
> Could you help to see the issue? Thank you!

We bi-sect commits on gecko v2.2 and find this commit fix the problem.
2e05d4f Bug 1081811 - Part 1: Remove some callschanged event firing and associated parameters. r=aknow

I will try to apply this patch to v2.1 to see if it works.
Flags: needinfo?(vliu)

Comment 37

3 years ago
Hi Ben,

We suspect that this bug has something to do with main thread message ordering.
Although the root cause is still unclear, as described in comment#36, the patch in Bug#1081811 can solve this bug.

I will dive deeper to find the root.
Meanwhile, can you comment on this commit? Is it safe to cherry-pick that patch to v2.1?
(2e05d4f Bug 1081811 - Part 1: Remove some callschanged event firing and associated parameters. r=aknow)

Thanks
Flags: needinfo?(bhsu)

Comment 38

3 years ago
Hi, Wenyuan

I think it's quite safe to apply this commit, since this commit just removes some useless "callschanged" event firing. However, if there anything that I can help or the commit does break something, please feel free to NI me again.
Flags: needinfo?(bhsu)

Comment 39

3 years ago
Hi Ben, 

We identify the root cause. This patch helps because it change the message order.
We will provide another patch to address the message order issue.
Thanks for your time.

Comment 40

3 years ago
Hi Olli,

We found the log symptom described in Comment#33 is possible caused by this line of code [1].
It will fire DOM resize event directly and registered callback functions will be invoked, and therefore causing the logs like Comment#33.

Sean and I write a sample page to reproduce this symptom.
(http://weilonge.bitbucket.org/resizeTest/)
The code is fairly straightforward. You can look at the page source directly. What we try to do is to monitor when the resize callback is invoked.

In this sample page, you can click "Resize Me" button multiple times and observer the log.
The expected result should be
====
A BEGIN
resizeChild BEGIN
resizeChild ENDDD
A ENDDD
innerHtml RESIZE!!!!!
====

But we get this log instead. (We believe it is the root cause of this issue.)
====
A BEGIN
resizeChild BEGIN
resizeChild ENDDD
innerHtml RESIZE!!!!!
A ENDDD
====

However, Both Safari and Chrome works as expected.
We are not sure if this kind of behavior is reasonable to Gecko or not. 

Can you comment on this?

Thanks.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#4224
Flags: needinfo?(bugs)
Yes, [1] is the thing which causes us to fire resize eagerly.
We could probably move that to refreshdriver.

Note, resize event isn't very well spec'ed, but per current spec it should fire synchronously.
Flags: needinfo?(bugs)
Why you think Safari/Chrome behavior is the expected one? And when does Safari/Chrome actually fire the event. Asynchronously? or around animation frame callbacks? Or microtask?
I'm not saying Safari/Chrome behavior is worse, but just curious, why you expect that behavior, given that it is not what is spec'ed currently
(well, the spec is rather vague).

Please file a layout bug to figure out when resize event should fire, and if you need to
have some workaround in gaia, perhaps
window.addEventListener("resize", function() { window.requestAnimationFrame(function() { /* the actual functionality */} )}, true);
would work well enough.
(btw, I think the spec can be changed if needed.)
Hi Olli,

These two line codes:
    var viewWidth = view.getBoundingClientRect().width;
    var viewFont = computedStyle.fontFamily;

are supposed to be executed synchronously, so I suppose the executing function won't be interrupted by any event.
(In this case, it is interrupted by "resize" handler.)

I have no idea how Safari/Chrome actually fire the event, but no matter getBoundingClientRect or fontFamily is executed or not, "resize" event will be triggered asynchronously. This behavior is different with Gecko.
You can try the test page ( http://weilonge.bitbucket.org/resizeTest/ ) again. I update a checkbox to switch get-width.

IMHO, we need well-documented "resize" event behavior to describe the event will be triggered synchronously when style queue is flushed.


Thanks a lot for your comments and solution. I've tested setTimeout can solve this issue as well.
   function updateAllPhoneNumberDisplays() {
-    handledCalls.forEach(function(call) {
-      call.restorePhoneNumber();
+    setTimeout(function nextTick() {
+      handledCalls.forEach(function(call) {
+        call.restorePhoneNumber();
+      });
     });
   }
   window.addEventListener('resize', updateAllPhoneNumberDisplays);
(In reply to Sean Lee [:seanlee] from comment #44)
> Hi Olli,
> 
> These two line codes:
>     var viewWidth = view.getBoundingClientRect().width;
This flushes layout (forces reflow), and as of now that may cause scripts to be executed, like in
this case dispatch resize event.

In a way the current behavior makes more sense than postponing the resize event, since
it ensures that after layout flush there isn't a resize event pending.
I guess one can argue one or another.

dbaron might have different opinion.
Flags: needinfo?(dbaron)

Updated

3 years ago
Depends on: 1149555
Ok, there is actually a spec for this
https://html.spec.whatwg.org/multipage/webappapis.html#run-the-resize-steps
and 
http://dev.w3.org/csswg/cssom-view/#resizing-viewports

So resize should fire only around animation frame callbacks per that.
I could live with such behavior. Filed Bug 1149555 to get the Gecko changed.
No longer depends on: 1149555
Flags: needinfo?(dbaron)

Updated

3 years ago
Depends on: 1149555

Comment 47

3 years ago
Let's dup this to 1149555 and continue investigate there.
Status: REOPENED → RESOLVED
blocking-b2g: 2.1+ → ---
Last Resolved: 3 years ago3 years ago
Flags: needinfo?(drs)
Resolution: --- → DUPLICATE
Duplicate of bug: 1149555
You need to log in before you can comment on or make changes to this bug.