Closed Bug 1145359 Opened 9 years ago Closed 9 years ago

Signal icons not updating properly on status bar

Categories

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

x86
Linux
defect
Not set
normal

Tracking

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master wontfix)

VERIFIED FIXED
2.2 S9 (3apr)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- verified
b2g-master --- wontfix

People

(Reporter: pgravel, Assigned: gmarty)

References

Details

(Whiteboard: [caf priority: p2][CR 809623][systemsfe])

Attachments

(3 files)

Please see attached video.

The signal icons are getting stuck on searching even though they should show connected. As soon as the minute flips over though, the status bar seems to finally refresh and show the right icons.

It doesn't appear to be a problem with notifications/having the wrong data, since there is absolute no new information fetched or pushed at the time of refresh (when the minute flips over)

It also doesn't seem to be a drawing issue, since the "searching" icons still animates properly. Maybe this is a problem with the layout not refreshing/updating?
Attached video status_bar_update.mp4
Can QA reproduce on the flame?
Component: Gaia → Gaia::System
Keywords: qawanted
Whiteboard: [systemsfe]
I was unable to reproduce this issue. After rebooting or resetting the device with 2 SIMs, the signal icons appeared properly. Could you elaborate your steps please? Did you mean it took you over a minute to get the signal icons? Was that after the FTU or just rebooting with 2 SIMs?

Environmental Variables:
Device: Flame 2.2
BuildID: 20150319100137
Gaia: 4e0633463571377ad4badc680b666771684e862d
Gecko: 535ec28fb36f
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(pgravel)
This was seen with both single sim and dual sim.

It doesn't need to be a clean flash, it is reproducible on simple reboots. It's somewhat tricky to catch as you need to be careful about booting up in the right time window. If the minute on the clock changes while the UI is still coming up, then you will not see the issue. 

It's not that it takes a minute for the signal icon to fix themselves, it that they only fix themselves when the clock updates when the minute change (as seen in the video 1:47 -> 1:48). If the minute advances shortly after the UI boots, it might simply seem like the phone took a few seconds to completely camp, even though usually the phone has plenty of time to fully camp before the UI finishes loading.

Anything that force the status bar to fully redraw will cause the issue to go away. This includes opening new apps or scrolling the home page down some amount.

This might related to a known issue? https://bugzilla.mozilla.org/show_bug.cgi?id=1102183#c2
Flags: needinfo?(pgravel)
Chris, gmarty, can you combine your gfx, statusbar expertise and attack this issue?
Flags: needinfo?(gmarty)
Flags: needinfo?(chrislord.net)
blocking-b2g: 2.2? → 2.2+
There are definite invalidation issues with -moz-element (i.e. platform problem), is this a situation where we're showing the -moz-element instead of the real element?

Guillaume, could you break down for me under which situations we show the -moz-element and why? And would we be open to the possibility of refactoring things so that we can get rid of it? (even aside from the bugs, it's pretty bad from a performance standpoint too)
Just spoke to gmarty offline - I misread the bug report, this has nothing to do with -moz-element. Which is good :)
Flags: needinfo?(chrislord.net)
I don't think I was able to reproduce this issue. First, I always boot up with full bars of signal so I don't get to see the phone searching for a signal at all. I tried to solve this by putting the phone in a faraday bag, and I observed that the phone updates signal independently from anything else on the status bar.

My STR:
0) Set display to never time out, disable lockscreen, and put phone in a faraday bag
1) Reboot phone
2) Observe signal strength on status bar, along with the clock and everything else on status bar

What I observed: I did witness signal strength being updated at the same time as time changes, twice, in ~10 attempts. Most of the attempts the signal updates independently from the time.

Leaving QAwanted tag for others to attempt.

Tested on:
Device: Flame 2.2 (KK, full flash, 319MB mem)
BuildID: 20150320002502
Gaia: c8136ef4094fc5509551ab7b1d5f6141491f00ef
Gecko: 12139abae350
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Whiteboard: [systemsfe] → [CR 811091][systemsfe]
Whiteboard: [CR 811091][systemsfe] → [caf priority: p2][CR 811091][systemsfe]
I haven't been able to reproduce it myself. I will check with our IT if we have a faraday bag or buy one otherwise.
I'm on it but I'm not assigning myself to this bug right now until I'm able to reproduce it.
Flags: needinfo?(gmarty)
Brogan, can you try with a faraday bag please?
QA Whiteboard: [QAnalyst-Triage-]
Flags: needinfo?(bzumwalt)
I tried this issue on 3.0 and 2.2 with and without the faraday bag but could not reproduce it.  Leaving the tag for Brogan to give his check on this issue.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150323052026
Gaia: 8eac260ee81a8aca05770d18c5736536d44ee7a7
Gecko: bc85c479668a
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Environmental Variables:
Device: Flame 2.2
BuildID: 20150323083624
Gaia: a9c115c2bfec193d0e9e55f760c92aabe9005b02
Gecko: 80aff14f7bdb
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
I might be getting this to occur on Flame 2.2 and 3.0

With 2 AT&T SIM cards in device, lockscreen disabled, and display timeout set to never restarting phone inside Faraday bag, then removing phone from bag shows that this issue appears on one of the two SIM cards at a time. Out of three tests on 3.0, two tests had SIM 1 showing a connecting animation until the moment the clock updated in the status bar, and the remaining test showed the same behavior with SIM card 2 (in each test the remaining SIM card icon updated at a random point separate from any status bar update.

With the same test in 2.2, I had the issue possibly occur 1 out of 3 attempts, this time only SIM 2 loaded connected status as the clock updated in the status bar. I am hesitant to say that this for sure occurred in 2.2 as it may have been a random coincidence that the phone signal update occurred at same time as clock update.


Leaving qawanted for further tests.

Device: Flame 2.2
Build ID: 20150323002504
Gaia: 7f367fc98ffdd183f21d2cdfe20556ab877ece34
Gecko: 3ea0eaeda353
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 3.0
Build ID: 20150323010204
Gaia: 9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gecko: e730012260a4
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(bzumwalt) → needinfo?(ktucker)
Hi all,

I have been doing some additional testing on my end.

I wrote a simple marionette test script (unable to share it, apologies in advance) that just changes the phone's registration state every 5 seconds (notSearching -> searching -> registered -> notSearching -> ...) and it becomes very obvious that the UI is not updating properly.

I found that I could resolve this issue with a simple fix in statusbar.js's sb_updateSignal() function.
In addition to all the "previous" states that this function is tracking (previousHiddenState, previousActiveState, previousRoamingHiddenState), it should also be tracking the SearchingState and set the isDirty bit true if it notices a change in searching state.

With that fix, the UI properly updates as expected on every state change.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee: nobody → gmarty
Whiteboard: [caf priority: p2][CR 811091][systemsfe] → [caf priority: p2][CR 809623][systemsfe]
(In reply to pgravel from comment #13)
> I found that I could resolve this issue with a simple fix in statusbar.js's
> sb_updateSignal() function.
> In addition to all the "previous" states that this function is tracking
> (previousHiddenState, previousActiveState, previousRoamingHiddenState), it
> should also be tracking the SearchingState and set the isDirty bit true if
> it notices a change in searching state.

This refers to v2.2 branch. I can write a patch and unit test for that.

The master has a completely different architecture for the status bar. Can you please confirm if the bug is present on master too? If so, I'll need your help to test the patch.
Flags: needinfo?(pgravel)
(In reply to Guillaume Marty [:gmarty] from comment #14)
> This refers to v2.2 branch. I can write a patch and unit test for that.
> 
> The master has a completely different architecture for the status bar. Can
> you please confirm if the bug is present on master too? If so, I'll need
> your help to test the patch.

When I try to run my test on master, the signal icon disappears entirely :(
However I would take that with a grain of salt since I had to hack up a few things to even get the test running on master on my device. So as it currently stands I can't really check if this issue exists on master.

I am quite willing and able to test any patch you prepare for v2.2 though.
Flags: needinfo?(pgravel)
Comment on attachment 8583914 [details] [review]
[gaia] gmarty:Bug-1145359-Signal-icons-not-updating-properly-on-status-bar-v2.2 > mozilla-b2g:v2.2

Here is a branch for v2.2. Can you please provide feedback about whether this patch fixes the issue?
Attachment #8583914 - Flags: feedback?(pgravel)
Comment on attachment 8583914 [details] [review]
[gaia] gmarty:Bug-1145359-Signal-icons-not-updating-properly-on-status-bar-v2.2 > mozilla-b2g:v2.2

Tested and working,

Thanks!
Attachment #8583914 - Flags: feedback?(pgravel) → feedback+
Comment on attachment 8583914 [details] [review]
[gaia] gmarty:Bug-1145359-Signal-icons-not-updating-properly-on-status-bar-v2.2 > mozilla-b2g:v2.2

Etienne, can you review this patch? It's on v2.2 branch.
Attachment #8583914 - Flags: review?(etienne)
Target Milestone: --- → 2.2 S9 (3apr)
Comment on attachment 8583914 [details] [review]
[gaia] gmarty:Bug-1145359-Signal-icons-not-updating-properly-on-status-bar-v2.2 > mozilla-b2g:v2.2

r=me with a test added to the "Signal icons" suite in statusbar_test.js.

(This suite is spying on the internal _updateIconVisibility already which I'm not a fan of but it's better than nothing :))
Attachment #8583914 - Flags: review?(etienne) → review+
Landing to get into QA builds. Let's add the test in a followup

master: https://github.com/mozilla-b2g/gaia/commit/b81477116fd8be278e7fb8f7517c70eea9a115f8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment on attachment 8583914 [details] [review]
[gaia] gmarty:Bug-1145359-Signal-icons-not-updating-properly-on-status-bar-v2.2 > mozilla-b2g:v2.2

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Not a regression, but a longstanding bug probably.

[User impact] if declined:
Signal status icons in statusbar show invalid results sometimes.

[Testing completed]:
Manually tested by developer and bug reporter. Unit tests forthcoming.

[Risk to taking this patch] (and alternatives if risky):
This is probably the only way to fix this properly, and it makes us update the statusbar slightly more often so it's low risk.

[String changes made]: none.
Attachment #8583914 - Flags: approval-gaia-v2.2?
Whoops, I didn't read closely enough that we only had a patch for v2.2 here. Backing out, and leaving the uplift approval.

v2.2: https://github.com/mozilla-b2g/gaia/commit/ca32692cd4c1bb98f3878268c3234d84716ee8a9
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I have a patch for master but I can't test it. I need a SIM that takes long before connecting to the network.
Alex, if you bump into this issue in a predictable way, can you try this patch and see if that fixes it?
https://github.com/mozilla-b2g/gaia/pull/29296

I'll work on unit test when both branches are fixed to see if I can share tests.
Flags: needinfo?(lissyx+mozillians)
Guillaume, do you have an ETA for this fix?
Flags: needinfo?(gmarty)
For the master branch I can't test this patch as I'm not able to replicate. I need a SIM with a long delay before actually connecting, which I don't have.
I'm hoping that Alex can reproduce the bug and test this patch.

For v2.2, the patch is ready and waiting on uplift approval.
Flags: needinfo?(gmarty)
needs uplift approval please bajaj
Flags: needinfo?(bbajaj)
(In reply to Candice Serran (:cserran) from comment #28)
> needs uplift approval please bajaj

So i was waiting for relanding on master before landing on branch. But comment#27 isn't promising yet. :gmarty, do we want to land this on the branch and continue to investigate on master?
Flags: needinfo?(bbajaj)
(In reply to bhavana bajaj [:bajaj] from comment #29)
> (In reply to Candice Serran (:cserran) from comment #28)
> > needs uplift approval please bajaj
> 
> So i was waiting for relanding on master before landing on branch. But
> comment#27 isn't promising yet. :gmarty, do we want to land this on the
> branch and continue to investigate on master?

Spoke offline with gwagner and given the code on master is different, I'll uplift this on the branch for now.
Attachment #8583914 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Since this is fixed on 2.2, and marked as a 2.2 blocker. Let's close this one, and open a new bug for the problem on master.

Bug 1151502 will be used to track the problem on master.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Flags: needinfo?(lissyx+mozillians)
Brogan, could you help verify if this bug has been fixed on v2.2?
Flags: needinfo?(bzumwalt)
Verified fixed on Flame 2.2

With two SIM cards in device, restarting device in faraday bag, then removing from faraday bag results in one of the two SIM cards connecting to network (according to status bar icon), then the time being updated to correct time followed shortly by the remaining SIM card connecting to network. Incorrect time progressing by a minute or correct time progressing by a minute while SIMs are still connecting to network do not appear to have any relation to the SIM status changing.

Device: Flame 2.2
Build ID: 20150417002504
Gaia: d50b8a3919a7b4d8d289f150d3b9bed704ebafa9
Gecko: 5ebf32030512
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(bzumwalt) → needinfo?(ktucker)
Keywords: verifyme
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: