Closed Bug 1123262 Opened 9 years ago Closed 9 years ago

[Midori 2.0]WLAN:signal strenght levels are not supported on notification bar

Categories

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

defect

Tracking

(blocking-b2g:2.0M+, b2g-v2.0 affected, b2g-v2.0M fixed, b2g-v2.1 affected, b2g-v2.1S affected, b2g-v2.2 wontfix, b2g-v2.2r wontfix, b2g-master verified)

RESOLVED FIXED
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0 --- affected
b2g-v2.0M --- fixed
b2g-v2.1 --- affected
b2g-v2.1S --- affected
b2g-v2.2 --- wontfix
b2g-v2.2r --- wontfix
b2g-master --- verified

People

(Reporter: sync-1, Assigned: yifan)

References

Details

(Keywords: dev-doc-complete)

Attachments

(4 files)

Mozilla Build ID: 20141019000201
 
 Regression: Yes
 Can not reproduce on FFOS v1.3.
 
 Note: It also can reproduce on Flame FFOS v2.0.
 
 Description: 
 
 signal strenght levels are not supported on notification bar
 to reproduce:
 1. Connect to any AP
 2. Go to wifi setup menu
 3. Go away from AP, to see signal strenght decrease
 result:
 from the wifi setup menu there is signal strenght levels which are correct according real signal level available
 from the notification bar the signal strenght level is always the same, no matter if signal is full or weak - screen attached
   
 Customer Impact Statement: 
 
 this can cause confusion and later complaints on FF2.0 OS
 
 Expected Behaviour: 
 
 signal strenght levels are to be supported on notification bar same as in wifi setup menu.
 
 this is correct for Carriers Network signal level on notification bar
 		
 
  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:
Summary: [Midori 2.0][HOMO][TMO 62685]WLAN:signal strenght levels are not supported on notification bar → [Midori 2.0]WLAN:signal strenght levels are not supported on notification bar
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Dear Wesly,

This issue is a regression. It can not reproduce on FFOS 1.3, but can reproduce on FFOS 2.0 now. Please help to check, thank you for your help!
Flags: needinfo?(wehuang)
Dear Mozilla,

In gecko,  this line http://mxr.mozilla.org/mozilla-b2g32_v2_0/source/dom/wifi/DOMWifiManager.js#413
"connectionInfoUpdate" should be "connectionInfoUpdate".
And in gaia, http://mxr.mozilla.org/gaia/source/apps/system/js/statusbar.js#907
'wifiManager.connectionInfoUpdate' should be 'wifiManager.onconnectionInfoUpdate'.
My test w/ Flame v18D image I can see wifi signal level changes but indeed looks strange (change very slow, and if I just screen off and on then signal bar might have sudden change in same location). Also TCL Guoqiang has some findings in comment#3.

qawanted to double confirm if there is such issue, in 2.0 and 2.2 first. thanks.

[Triage]
Need more information before a decision. Could be minor if only UI problem and not impact actual wifi usability, but anyway confusing to user.
status-b2g-v2.0: --- → ?
status-b2g-v2.2: --- → ?
Flags: needinfo?(wehuang)
Keywords: qawanted
Attached image screenshot
This problem can be repro on latest Flame2.0/2.2.
See attachments: Flame2.0_screenshot.png & logcat_1800.txt
Repro time: 18:00
Flame2.0 repro rate: 3/5
Flame2.2 repro rate: 5/5

Flame 2.0 build:
Gaia-Rev        736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/6c9aefc84244
Build-ID        20150119000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150119.033618
FW-Date         Mon Jan 19 03:36:29 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build: 
Gaia-Rev        f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/bccee1a13ba6
Build-ID        20150119002502
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150119.035831
FW-Date         Mon Jan 19 03:58:42 EST 2015
Bootloader      L1TC000118D0
Attached file logcat
Hi Yifan:

just saw Bug 1121398 during woodduck Triage and looks related, do you think Bug 1121398 will also fix this one? Thanks.
Flags: needinfo?(yliao)
See Also: → 1121398
It is possible if there are multiple wifi APs with the name 'Mgsei_YTB' in the test environment. If yes, please apply the patch and see if it fixes the issue. If not, we probably have a different problem.

The API in gaia should be correct according to MDN https://developer.mozilla.org/en-US/docs/Web/Events/connectionInfoUpdate .
Flags: needinfo?(yliao)
I don't think this issue is totally the same as bug 1121398.
This issue at here is about the WifiManager API has a mistake name in gecko and gaia.

In gecko, you will find the line http://mxr.mozilla.org/mozilla-b2g32_v2_0/source/dom/wifi/DOMWifiManager.js#413 has a mistake name for the API event.
The event name "connectioninfoupdate" should be modified to the right name "connectionInfoUpdate".
The name should be in CamelCasing according to the webidl.

In gaia, http://mxr.mozilla.org/gaia/source/apps/system/js/statusbar.js#907
'wifiManager.connectionInfoUpdate' should be 'wifiManager.onconnectionInfoUpdate'.

Thanks!
Thanks Shine, Yifan and xiuping!

@Xiuping:

since you've pointed out the possible root cause in comment#9 I assume you are able to fix this issue already?

@

also qawnated for 2.0m and 2.1.
status-b2g-v2.1: --- → ?
Keywords: qawanted
Thanks Shine, Yifan and xiuping!

@Xiuping:

Since you've pointed out the possible root cause in comment#9 I assume you are able to fix this issue already? 

Also, would you help clarify the signal level issue in status bar, is only a display problem, or will actually impact wifi speed that user can get? Thank you.

@Yifan: is it possible for you to check the code that Xiuping mentioned in comment#9? Thank you.

also qawnated for 2.0m and 2.1.
Flags: needinfo?(yliao)
Flags: needinfo?(longxiuping)
(In reply to Wesly Huang from comment #11)
> @Xiuping:
> 
> Since you've pointed out the possible root cause in comment#9 I assume you
> are able to fix this issue already? 

Yes, we could fix it according comment#9.

> 
> Also, would you help clarify the signal level issue in status bar, is only a
> display problem, or will actually impact wifi speed that user can get? Thank
> you.

Hi Wesly,

The signal level indicator the wifi strength, but with this issue, signal level will not update according to the real strength, user will confuse.

Although it is a display issue, but this is a really issue, because it is about API for WIFI info.
https://developer.mozilla.org/en-US/docs/Web/API/WiFi_Information_API

Thanks!
Flags: needinfo?(longxiuping)
I'm occupied in another bug, will have a look later. Please feel free to submit a fix, thank you!
Flags: needinfo?(yliao)
This issue does occur on 2.1 Flame KK.  I also verified that it occurs on 3.0 Master builds for Flame KK.  I do not have access to 2.0m builds so another will have to check those.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150122053733
Gaia: 966b3a7a13a7f0d5b86cbc9e64cb78d43ec7dba8
Gecko: 86f9d0128ccf
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Environmental Variables:
Device: Flame 2.1
BuildID: 20150122134245
Gaia: 2119de79b6edfbcd4f112b2f797dbd7dba17ea69
Gecko: a79c389d56fb
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Thank you Xiuping for the findings! Confirmed fixing problems in comment#9 resolves this issue. Following the documentation on MDN we need to fix this in both gecko and gaia. But 'wifiManager.onconnectioninfoupdat' has been used in settings app.

Hi Alive, should we just change 'wifiManager.connectionInfoUpdate' to 'wifiManager.onconnectioninfoupdate'? Or should we fix this in both gecko and gaia? The later approach requires changes in settings app though but it's a more generic fix.
Assignee: nobody → yliao
Status: NEW → ASSIGNED
Flags: needinfo?(alive)
This is fixed in bug 1098168.

I don't get your point - wifiManager.onconnectioninfoupdate in settings app won't affect the same handler in system app.

(In reply to yifan [:yifan][:yliao] from comment #15)
> Thank you Xiuping for the findings! Confirmed fixing problems in comment#9
> resolves this issue. Following the documentation on MDN we need to fix this
> in both gecko and gaia. But 'wifiManager.onconnectioninfoupdat' has been
> used in settings app.
> 
> Hi Alive, should we just change 'wifiManager.connectionInfoUpdate' to
> 'wifiManager.onconnectioninfoupdate'? Or should we fix this in both gecko
> and gaia? The later approach requires changes in settings app though but
> it's a more generic fix.
Flags: needinfo?(alive)
To make the problem clearer(note the capital letter differences in 'connectionInfoUpdate'), here are a list of relative issues:

1. The API definition is different from gecko source code and MDN('connectioninfoupdate' & 'connectionInfoUpdate'):
   gecko: http://mxr.mozilla.org/mozilla-b2g32_v2_0/source/dom/wifi/DOMWifiManager.js#413
   MDN: https://developer.mozilla.org/en-US/docs/Web/API/WiFi_Information_API#Ongoing_connection
   
   settings app follows the definition in gecko.

2. system app follows an incorrect MDN page which uses 'wifiManager.connectionInfoUpdate':
   MDN: https://developer.mozilla.org/en-US/docs/Web/Events/connectionInfoUpdate

   settings app uses 'wifiManager.onconnectioninfoupdate'.

There are 2 approaches to fix this:

1. Simply use 'wifiManager.onconnectioninfoupdate' in system app, update all MDN references(but by doing this the event name 'connnectioninfoupdate' seems to be inconsistent with other camel case event names)

2. Change the event name in gecko to camel case, fix 'wifiManager.connectionInfoUpdate' to 'wifiManager.onconnectionInfoUpdate' in system app and also update the change in settings app.

Since it works originally in settings app, also flagging Arthur for opinions. Thanks!
Flags: needinfo?(arthur.chen)
Flags: needinfo?(alive)
It seems all other events of wifi manager are not camel case, so option one makes more sense to me. ni Vincent for confirming this.
Flags: needinfo?(arthur.chen) → needinfo?(vchang)
Keywords: qawanted
(In reply to Arthur Chen [:arthurcc] from comment #18)
> It seems all other events of wifi manager are not camel case, so option one
> makes more sense to me. ni Vincent for confirming this.

Agree with Arthur. I think we should follow the definition of https://dxr.mozilla.org/mozilla-central/source/dom/webidl/MozWifiManager.webidl.
Flags: needinfo?(vchang)
+1 to Arthur, thanks for clarifying.
Flags: needinfo?(alive)
Attached file pull request
Thank you all for the confirmation! The wifi API usage is corrected.
Attachment #8554395 - Flags: review?(alive)
The MDN pages related to wifi API should be updated accordingly:
https://developer.mozilla.org/en-US/docs/Web/Events/connectionInfoUpdate
https://developer.mozilla.org/en-US/docs/Web/API/WiFi_Information_API#Ongoing_connection
Flagging 'dev-doc-needed' to track update progress.
Keywords: dev-doc-needed
blocking-b2g: 2.0? → 2.0M?
Attachment #8554395 - Flags: review?(alive) → review+
Hi Kai-Zhen,
Could you help to land this on 2.0M? Thanks!
Blocks: Woodduck
blocking-b2g: 2.0M? → 2.0M+
Flags: needinfo?(kli)
master: https://github.com/mozilla-b2g/gaia/commit/d34aff2c9066785d2cfb37a05a6c1106a5b514a0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(kli)
Resolution: --- → FIXED
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/2116/
Flags: in-moztrap+
ni Josh for suggestions on 2.1 & 2.2 approval.
Flags: needinfo?(jocheng)
Hi Vance,
Do we still need this for 2.1/2.1S?
Thanks!
Flags: needinfo?(vchen)
This bug has been verified as pass on latest Nightly build of Flame master and Nexus5 master.
STR:
1. Connect a Wifi in "Settings".
2. Place mobile to a place where the siginal is weak. 
3. Observe signal strength change of connected wifi shown in Status bar and that shown in wifi list.

Actual result: Signal strength change of connected wifi in Status bar synchronizes with that shown in wifi list view.

See attachment: Flame_master.mp4
Reproduce rate: 0/5

Device: Flame master(Pass):
Build ID               20150715160204
Gaia Revision          b9968cdc4a1dee49848fed6159a59c378cea062d
Gaia Date              2015-07-15 12:13:34
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/49683d4e9ebd
Gecko Version          42.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150715.192231
Firmware Date          Wed Jul 15 19:22:42 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus5 master(Pass):
Build ID               20150715160204
Gaia Revision          b9968cdc4a1dee49848fed6159a59c378cea062d
Gaia Date              2015-07-15 12:13:34
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/49683d4e9ebd
Gecko Version          42.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150715.191550
Firmware Date          Wed Jul 15 19:16:07 EDT 2015
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Hi Wesley,
Do you need this for feature phone on 2.2r?
Thanks
Flags: needinfo?(jocheng) → needinfo?(whuang)
2.2r is a derived branch from 2.2.
We supposedly only add feature phone relevant features and critical bug fixes.
Other than that I think should be the same as 2.2.
Flags: needinfo?(whuang)
Don't need this one for 2.1s, however, I would recommend this one to land on 2.2r since feature phone will still has a wifi signal bar display on idle screen
Flags: needinfo?(vchen)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: