[Buri][WIFI] The bars of icon are dark when connect to AP

RESOLVED FIXED

Status

Firefox OS
Gaia::System
P2
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: sync-1, Assigned: alive)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

(Whiteboard: QARegressExclude)

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.077
 Firefox os  v1.0.1
 Mozilla build ID:20130414070204
 
 +++ This bug was initially created as a clone of Bug #444116 +++
 
 Created an attachment (id=395485)
 when connect to one AP
 
 DEFECT DESCRIPTION:
 The bars of icon are dark when connect to AP
  REPRODUCING PROCEDURES:
 1.turn on Wi-Fi
 2.connect to one AP(name:NTGR),after connect ,the bars of icon are dark,when I power off screen and power on ,it's normal->KO1
  EXPECTED BEHAVIOUR:
 1.the icon should be normal after connect to AP
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:1/4
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #444116 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
(Reporter)

Comment 1

5 years ago
Clone from brother
(Reporter)

Comment 2

5 years ago
Created attachment 740201 [details]
when connect to one AP

Clone from brother
(Reporter)

Comment 3

5 years ago
Clone from brother
(Reporter)

Comment 4

5 years ago
Created attachment 740202 [details]
power off screen and power on

Clone from brother

Updated

5 years ago
blocking-b2g: --- → tef?
blocking-b2g: tef? → tef+
Vincent, is this something you can take?
Flags: needinfo?(vchang)
Whiteboard: [requires investigation]
vincent, can you take this for now? thanks
Assignee: nobody → vchang
Flags: needinfo?(vchang)
This should be done in Gaia. 
It's very weird that the relSignalStrength value is sometimes very small(relSignalStrength:8) when we just connect to an AP. But it is updated(relSignalStrength:100) later on by a periodically timer in Gecko. This value should be updated in the Gaia as well. 

Logcat in Gecko,
WifiWorker component: Firing connectionInfoUpdate: ({signalStrength:-96, relSignalStrength:8, linkSpeed:36, ipAddress:""})

WifiWorker component: Firing connectionInfoUpdate: ({signalStrength:-55, relSignalStrength:100, linkSpeed:0, ipAddress:"192.168.11.8"})
Drop it because it should be done in Gaia
Assignee: vchang → nobody
Assignee: nobody → tkundu
Status: NEW → ASSIGNED
Gecko calls getConnectionInformation() every 5 secs to get signal strength. 

It seems that libhardware_legacy.command(data.request, cbuf, len.address()) in gecko/dom/wifi_worker.js is returning very small value (ex: relSignalStrength:8) in the first call of SIGANAL_POLL request to getConnectionInfoICS(). When gaia/js/system/statusbar.js sb_updateWifi() sees this small value , it tries to set wifi signal icon level as Math.floor(relSignalStrength / 25) .

But gaia wifi signal icon has only 4 levels so values below 25 showed as No Signal. 

One possible solution can be to request SIGANAL_POLL agian when we see very low value (as this is running in another thread , so it should not block any operations) or We can call getConnectionInformation() more often to solve this problem.

Please suggest.
Flags: needinfo?(vchang)
There is a connectionInfoUpdate event listener API which can be used in Gaia apps to obtain the update to date signal strength every 5 seconds.

But it is a little weird to me that why will we get the very small value from wpa_supplicant in the first time ? Is it related to the wifi driver ?
Flags: needinfo?(vchang)
Steal as :vchang advised, we could refine this from gaia.
Per comment 9/comment 10, the longest time to update the wifi strength would be 5sec after connecting to an AP.
Assignee: tkundu → alive
Component: Gaia::Settings → Gaia::System
(In reply to Alive Kuo [:alive] from comment #11)
> Steal as :vchang advised, we could refine this from gaia.
> Per comment 9/comment 10, the longest time to update the wifi strength would
> be 5sec after connecting to an AP.

Do you have an ETA for this investigation/landing?
(In reply to Alex Keybl [:akeybl] from comment #12)
> (In reply to Alive Kuo [:alive] from comment #11)
> > Steal as :vchang advised, we could refine this from gaia.
> > Per comment 9/comment 10, the longest time to update the wifi strength would
> > be 5sec after connecting to an AP.
> 
> Do you have an ETA for this investigation/landing?

I'll discuss with Vincent tomorrow to make sure we have no other way than set a timer or event handler in gaia. If so, this could be done by this week.
Created attachment 744466 [details]
https://github.com/mozilla-b2g/gaia/pull/9503

The wifi-statuschange event is only triggered when the connection status of wifi is changed. If the wifi is keeping connected but the relative signal length of wifi is changed, we need to use connectionInfoUpdate handler to monitor it and reflect the signal strength change on statusbar wifi icon.
Attachment #744466 - Flags: review?(timdream)
Comment on attachment 744466 [details]
https://github.com/mozilla-b2g/gaia/pull/9503

Looks like the code was accidentally removed in bug 827786?
Attachment #744466 - Flags: review?(timdream) → review+
Adding dependency and regression flag.
Depends on: 827786
Keywords: regression
Whiteboard: [requires investigation]
Ya a sad regression and thanks the reporter has finally found it...

master:
https://github.com/mozilla-b2g/gaia/commit/bc166560b278ef89fa9cb63591ec1d32b810556e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
Resolution: --- → FIXED
Uplifted bc166560b278ef89fa9cb63591ec1d32b810556e to:
v1-train: 5ca207f546a092da812d475dfc5f872fbcdafa56
v1.0.1: 214ec00db8370b9099b765e93fa578f75406ae40
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed

Comment 19

5 years ago
the WiFi bars are normal on Leo and Inari devices

Environmental  Variables:
Inari Build ID: 20130503070205
Kernel Date: Feb 21
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3f3489356bbc
Gaia: 3e232bce289c9e156d92553e752616cba284bc8f
Environmental  Variables:
Leo Build ID: 20130503070204
Kernel Date: Apr 25
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8becaf2a0bc7
Gaia: b0aca0dd1e2955e11190ede725e1fb9ee596438b

Updated

5 years ago
Whiteboard: QARegressExclude
You need to log in before you can comment on or make changes to this bug.