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)
Firefox OS Graveyard
Gaia::System
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)
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:
Updated•9 years ago
|
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
Comment 2•9 years ago
|
||
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)
Comment 3•9 years ago
|
||
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'.
Comment 4•9 years ago
|
||
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.
Comment 5•9 years ago
|
||
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
Comment 6•9 years ago
|
||
Updated•9 years ago
|
Comment 7•9 years ago
|
||
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)
Assignee | ||
Comment 8•9 years ago
|
||
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)
Comment 9•9 years ago
|
||
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!
Comment 10•9 years ago
|
||
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.
Comment 11•9 years ago
|
||
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.
Updated•9 years ago
|
Flags: needinfo?(yliao)
Flags: needinfo?(longxiuping)
Comment 12•9 years ago
|
||
(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)
Assignee | ||
Comment 13•9 years ago
|
||
I'm occupied in another bug, will have a look later. Please feel free to submit a fix, thank you!
Flags: needinfo?(yliao)
Comment 14•9 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee | ||
Comment 15•9 years ago
|
||
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)
Comment 16•9 years ago
|
||
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)
Assignee | ||
Comment 17•9 years ago
|
||
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)
Comment 18•9 years ago
|
||
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)
Comment 19•9 years ago
|
||
(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)
Assignee | ||
Comment 21•9 years ago
|
||
Thank you all for the confirmation! The wifi API usage is corrected.
Attachment #8554395 -
Flags: review?(alive)
Assignee | ||
Comment 22•9 years ago
|
||
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
Assignee | ||
Updated•9 years ago
|
blocking-b2g: 2.0? → 2.0M?
Updated•9 years ago
|
Attachment #8554395 -
Flags: review?(alive) → review+
Comment 23•9 years ago
|
||
Hi Kai-Zhen, Could you help to land this on 2.0M? Thanks!
Comment 24•9 years ago
|
||
master: https://github.com/mozilla-b2g/gaia/commit/d34aff2c9066785d2cfb37a05a6c1106a5b514a0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(kli)
Resolution: --- → FIXED
Comment 25•9 years ago
|
||
v2.0m: https://github.com/mozilla-b2g/gaia/commit/53526a3a5c913efc851b35e3d083cadf93cf8bef
status-b2g-v2.1S:
--- → affected
Comment 26•9 years ago
|
||
Documentation updated: * https://developer.mozilla.org/en-US/docs/Web/API/WiFi_Information_API#Ongoing_connection * https://developer.mozilla.org/en-US/docs/Web/API/WifiManager.onconnectioninfoupdate * https://developer.mozilla.org/en-US/docs/Web/API/WifiManager#Event_handlers
Keywords: dev-doc-needed → dev-doc-complete
Comment 27•9 years ago
|
||
Test case has been added in moztrap: https://moztrap.mozilla.org/manage/case/2116/
Flags: in-moztrap+
Assignee | ||
Comment 28•9 years ago
|
||
ni Josh for suggestions on 2.1 & 2.2 approval.
Flags: needinfo?(jocheng)
Comment 29•9 years ago
|
||
Hi Vance, Do we still need this for 2.1/2.1S? Thanks!
Flags: needinfo?(vchen)
Comment 30•9 years ago
|
||
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+]
Comment 31•9 years ago
|
||
Hi Wesley, Do you need this for feature phone on 2.2r? Thanks
Flags: needinfo?(jocheng) → needinfo?(whuang)
Comment 32•9 years ago
|
||
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.
status-b2g-v2.2r:
--- → wontfix
Flags: needinfo?(whuang)
Updated•9 years ago
|
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.
Description
•