950185 - [B2G] [Settings] Network type does not show user friendly options such as 2G and 3G

Status: RESOLVED FIXED

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

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: 2013-12-13-12-13-33.png

Description:
Network type does not show user friendly options such as 2G and 3G. The available options shown are WCDMA preferred, GSM, WCDMA, GSM preferred, EVDO preferred, CDMA, EVDO and Automatic.

Repro Steps:
1)  Updated Buri to Build ID: 20131213004002
2)  Tap on "Settings".
3)  Tap on "Cellular & Data".
4)  Tap on "Network Operator".
5)  Tap on the "Network type" drop down and look at the available options.
 
Actual:
The network type options do not have user friendly options such as 2G and 3G.

Expected:
The network type drop down showns more user friendly options such as 2G and 3G.

Environmental Variables
Device: Buri v 1.3.0 Mozilla RIL
Build ID: 20131213004002
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/dfae9c83bfbc
Gaia: 888f9df5515a47d2f5806efee77485e05e1e5416
Platform Version: 28.0a2

Notes:
Repro frequency: 100%
Link to failed test: https://moztrap.mozilla.org/manage/case/3536/
See attached: screenshot

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue does not occur on the Buri v 1.3.0 Mozilla RIL

Environmental Variables
Device: Buri v 1.2.0 Mozilla RIL
Build ID: 20131211004007
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/43d7b300241a
Gaia: 096722a9e2510ecdfe45ba7382d7d50826b82feb
Platform Version: 26.0

The user can select 2G, 3G and automatic in Network type.

Comment 2

[Jason Smith [:jsmith]]

Kevin - I'm confused by your above comments vs. status flags. What build isn't this reproducing on? What build is this reproducing on?

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

In reply to comment 2 that was a mistake. The corrected variables are below:


This issue does not occur on the Buri v 1.2.0 Mozilla RIL

Environmental Variables
Device: Buri v 1.2.0 Mozilla RIL
Build ID: 20131211004007
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/43d7b300241a
Gaia: 096722a9e2510ecdfe45ba7382d7d50826b82feb
Platform Version: 26.0

The user can select 2G, 3G and automatic in Network type.

Comment 4

[gbennett]

No build was spun on 8/4/2013 and the last working has the selection as mentioned in comment 3.

.:Last Working Build:.
Environmental Variables:
Device: Buri 1.2 mozRIL
BuildID: 20130803070217
Gaia: 33984fd5596c7bd329819700b01294896e30ccfb
Gecko: 0a63cd911b4f
Version: 25.0a1
RIL Version: 01.02.00.019.102
Firmware Version: 20131115

.:First Broken Build:.
Environmental Variables:
Device: Buri 1.2 mozRIL
BuildID: 20130805070203
Gaia: 0ca0dba246d1372eb815772c8108395ab0abd0a4
Gecko: ad0ae007aa9e
Version: 25.0a1
RIL Version: 01.02.00.019.102
Firmware Version: 20131115

Comment 5

[Jason Smith [:jsmith]]

So I think the regression window above is likely when this first regressed previously in the 1.2 timeframe. We're looking for the regression window when this regressed in the 1.3 timeframe.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: we are not sure if this is a intention UI presentation for engineering builds.

Ken, I am told that Gecko should supply device capability like this? Need your help.

Comment 7

[Ken Chang[:kenkai]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> Triage: we are not sure if this is a intention UI presentation for
> engineering builds.
> 
> Ken, I am told that Gecko should supply device capability like this? Need
> your help.
We should get UX feedback. Which icon do they want to show for user?
Moreover, we wonder if there is a platform being able to support one search for all 3G radio technologies or all 2G radio technologies.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> Triage: we are not sure if this is a intention UI presentation for
> engineering builds.
> 
> Ken, I am told that Gecko should supply device capability like this? Need
> your help.

This isn't related to engineering builds. The bug as filed here is a production moz official build issue.

This is a confirmed regression that regressed again (it was broken & fixed in 1.2, and then broke here in 1.3 again).

Comment 9

[Sarah Parsons]

This issue started to occur on the Buri 1.3 Build ID: 20130925174530

Gaia   7e42b4d690049709c62e8783910f16ab20869f42
SourceStamp fa0e6916f88c
BuildID 20130925174530
Version 27.0a1


Last working Buri 1.3 Build ID: 20130924040201

Gaia   a22ba4a3a9efd99f94adf9ece8a2b391d4df295b
SourceStamp 1fda74e33e06
BuildID 20130924040201
Version 27.0a1

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Jason Smith [:jsmith] from comment #8)
> This is a confirmed regression that regressed again (it was broken & fixed
> in 1.2, and then broke here in 1.3 again).

Could you grab the bug number? Thanks.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Please disregard the last comment. Just talked to Arthur and he will leave a re-cap on this bug. Thanks Arthur.

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

Currently we use build time customization[1] to configure the supported network types as Gecko is not able to provide the capability of the devices (which is a limitation). After bug 923088 landed, we display 2G, 3G terms as before if we build with the configuration specifying that the devices only support GSM network types. By default all network types are displayed based on the comment[2]. As 2G and 3G are not sufficient to be used to distinguish between GSM and CDMA network types, we chose to show the network types directly based on [3].

I suggest that we should use the configuration that supports most of the cases as the default. Which is GSM/WCDMA only in our case.

[1]: https://wiki.mozilla.org/B2G/MarketCustomizations#network.json_.28not_in_customization_folder.29
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=903232#c22
[3]: http://android.stackexchange.com/questions/28553/change-wcdma-to-gsm-automatically

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It's a shame that we couldn't get the device capable from platform and determine the UI in runtime. That said, supporting a device capable of both CDMA/EVDO and GSM/WCDMA is still a valid use case. I accidentally switch to CDMA network type yesterday during triage and that breaks my dogfooding GSM/WCDMA phone (it reports no SIM card but with 3G connection \o/), so we must avoid this kind of confusion for out-of-box unconfigured phone too.

I suggest, to UX, we classify the phone into four classes
1) unconfigured (default)
2) gsm
3) cdma
4) gsm+cdma

This establish a distinction between (1) and (4). The UI labels for (2) and (3) and (4) shall remain unchanged, but for (1) we should make the labels more explicit, i.e. compare to (4):

WCDMA preferred -> GSM (2G)/WCDMA (3G), 3G preferred
GSM -> GSM (2G)
WCDMA -> WCDMA (3G)
GSM preferred -> GSM (2G)/WCDMA (3G), 2G preferred
EVDO preferred -> CDMA/EVDO, EVDO preferred
CDMA
EVDO
Automatic -> GSM/WCDMA/CDMA/EVDO

(I am not sure people would refer CDMA as CDMA (2G) and EVDO as EVDO (3G) too; I am not familiar CDMA/EVDO is marketed in their markets)

That should out-of-box builds works for everyone.

Comment 14

[Neo Hsieh [:neo]]

In O.S design concept, we have to provide whole options for OEM/ODMs.

Because we don't know how these OEM/ODMs will re-design it for their target market.
That's a good idea to change these technical wording from "CDMA/WCDMA/LTE.." to "2G/3G/4G". 
But It's only for one level of our users. For feature phone user, Maybe they even don't know what is 2G/3G/4G. 

So I don't think we need to make a choice for target users. It's OEM/ODMs' choice.
For power users who can flash their mobile phone, I think they already know what is CDMA/WCDMA/2G/3G...

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to ktucker from comment #0)
> Notes:
> Repro frequency: 100%
> Link to failed test: https://moztrap.mozilla.org/manage/case/3536/
> See attached: screenshot

BTW, who do we talk to update the test case of the unconfigured build? The fact that we rely on build customization to switch between gsm-only/cdma-only/both means that we will always fail this test case, based on the description (unless we want to turn CDMA config off by default).

Comment 16

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #15)
> (In reply to ktucker from comment #0)
> > Notes:
> > Repro frequency: 100%
> > Link to failed test: https://moztrap.mozilla.org/manage/case/3536/
> > See attached: screenshot
> 
> BTW, who do we talk to update the test case of the unconfigured build? The
> fact that we rely on build customization to switch between
> gsm-only/cdma-only/both means that we will always fail this test case, based
> on the description (unless we want to turn CDMA config off by default).

Try talking to Enpei & William about this. They can probably help update the test cases for this area.

Comment 17

[Jason Smith [:jsmith]]

So is this bug invalid then? And we just need to update the test cases?

Comment 18

[Neo Hsieh [:neo]]

Hi Tim, 
I totally agree with you to change wording to prevent user choose wrong type on unconfigured devices.
But the wording maybe too long to shows in one line. (Please help to try it)
As far as I know, CDMA user called their system CDMA/Evdo instead of 2G/3G. 

So maybe we can change the wording for unconfigured devices :

WCDMA preferred -> GSM(2G)/WCDMA(3G), 3G preferred
GSM -> GSM(2G) only
WCDMA -> WCDMA(3G) only
GSM preferred -> GSM(2G)/WCDMA(3G), 2G preferred
EVDO preferred -> CDMA/EVDO, EVDO preferred
CDMA -> CDMA only
EVDO -> EVDO only

About "Automatic", Because it's not really auto select in unconfigured device and we still need provide all options to OEM/ODM, I recommend we temp remove this option (UI) and keep provide related API support. 
What do you think ?

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yeah that looks fine. I will make a local patch for you and we could work on the wording and length.

(In reply to Neo Hsieh from comment #18)
> About "Automatic", Because it's not really auto select in unconfigured
> device and we still need provide all options to OEM/ODM, I recommend we temp
> remove this option (UI) and keep provide related API support. 
> What do you think ?

:anshul, will this work with our partner testing for unconfigured devices?

William, please see comment 15 and comment 16 -- we would need to update the moztrap desc. Thanks.

Comment 20

[Anshul]

Not sure what an unconfigured device is but Automatic mode is needed so modem can choose any available network supported.

Comment 21

[William Hsu [:whsu]]

I think Enpei know how to do that.

Needinfo: Enpei.
--------------------------------------------------

Hi, Enpei,

I would like to help on test case creation but I think you are the right person to do this.
Could I have your help to revise the test cases?
Thanks!

Comment 22

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: +'ing, need new UI label to reduce user confusion.

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Anshul from comment #20)
> Not sure what an unconfigured device is but Automatic mode is needed so
> modem can choose any available network supported.

Anshul, unconfigured simply means the build you tested on. I take your response as the fact that we shouldn't remove "Automatic".

Comment 24

[William Hsu [:whsu]]

Per I discussed this bug with Arthur and Enpei in person, we had following action items.

(1) Update the build script of PVT build
    I have submitted a bug to trace this request. (Bug 952036).
    The network type of settings page needs to display the device supported network types instead of displaying all network types.

(2) Modify the test cases.
    We don't know who changed the following test case but we need to revise it to avoid misunderstandings.
    https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=3536

Thanks!

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

OK.

I've just talked to Marco and Ken, and we agreed that supported network type should be available under MobileConnection API, and Gecko in turn will get the value from gonk. Every device will have appropriate list of supported network type in their gonk pref. 

With that we no longer need to change the menu item through market customization, and we don't need to blow our head off to come up with a default, explicit, wording.

There will be another bug filed for Gecko work.

(In reply to William Hsu [:whsu] from comment #24)
> (1) Update the build script of PVT build
>     I have submitted a bug to trace this request. (Bug 952036).
>     The network type of settings page needs to display the device supported
> network types instead of displaying all network types.

I don't know if that voids this work?

Comment 26

[William Hsu [:whsu]]

...Actually, I didn't involve the CDMA tests. I just helped relay the information. XD
Arthur may know the answer.
Thanks!

Comment 27

[Arthur Chen [:arthurcc][inactive after 6/30]]

I've closed bug 952036 per comment 25. Thanks for helping, William!

Comment 28

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hi George, 

Would you mind working on this 1.3+ bug for the team? Please talk to Edgar (see bug 952043) to find out the API changes.

Comment 30

[(Inactive after June) George Duan [:gduan] [:喬智]]

Todo:
1. only list |supportedNetworkTypes| 
2. new getting method from gecko will be updated in bug 952043

Waiting for bug 952043 closing.

Comment 31

[Anshul]

Ken, do we really need this change for 1.3?

Comment 32

[Ken Chang[:kenkai]]

(In reply to Anshul from comment #31)
> Ken, do we really need this change for 1.3?

Tim, your opinion?

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Not fixing this bug results confusing user experience for GSM-only or CDMA-only phones, unless vendors patch the code locally downstream. This does not inline with the experience we want achieve for the open source codebase.

Comment 34

[Anshul]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #33)
> Not fixing this bug results confusing user experience for GSM-only or
> CDMA-only phones, unless vendors patch the code locally downstream. This
> does not inline with the experience we want achieve for the open source
> codebase.
Tim, if this is just a matter of changing the network names displayed to the user, why does this even need support for bug 952043? 

My goal is to minimize any interfaces changes to 1.3 so close to achieving commercial quality.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Anshul from comment #34)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #33)
> > Not fixing this bug results confusing user experience for GSM-only or
> > CDMA-only phones, unless vendors patch the code locally downstream. This
> > does not inline with the experience we want achieve for the open source
> > codebase.
> Tim, if this is just a matter of changing the network names displayed to the
> user, why does this even need support for bug 952043? 
> 
> My goal is to minimize any interfaces changes to 1.3 so close to achieving
> commercial quality.

IMHO the change is manageable. Obviously I shouldn't have the final say on this but I don't know who should be making this decision either.

In the mean time I will still ask developer to fix this bug on master since at the end of the day this is still a valid bug.

Comment 36

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

waiting for travis.

Comment 37

[Michael Schwartz [:m4]]

Two cents: isn't this feature for power-users anyway?  Not sure that making the entries more "user-friendly" actually helps anyone.

Comment 38

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8361002 [details]
PR to master

Hi Arthur,
Please kindly check this patch.
thanks.

Comment 39

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8361002 [details]
PR to master

Thanks for the patch, George! As we are not using network.json anymore, could you help remove related logic from `build/applications-data.js`? And we also need to remove the related section from wiki (https://wiki.mozilla.org/B2G/MarketCustomizations).

Comment 40

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8361002 [details]
PR to master

Hi Arthur,
patch is updated. I will update wiki once it's merged. Thanks.

Comment 41

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8361002 [details]
PR to master

The patch looks good to me. However, I would like to do more test after bug 960906 lands. Cancel the review request for now.

Comment 42

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Is the code ready for review now?

Comment 43

[Arthur Chen [:arthurcc][inactive after 6/30]]

I've already reviewed the code and it looks good. The gecko and gaia parts are ready but we are waiting for the build with the system properties. Please see bug 960906 and https://bugzilla.mozilla.org/show_bug.cgi?id=952043#c63.

Comment 44

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8361002 [details]
PR to master

r=me. Thanks for the patch, George. Please land the patch with green travis.

Comment 45

[Arthur Chen [:arthurcc][inactive after 6/30]]

Note that we should verify the bug using the build with correct system properties. Please refer to bug 960906 for details.

Comment 46

[(Inactive after June) George Duan [:gduan] [:喬智]]

Thanks Arthur,
master: https://github.com/mozilla-b2g/gaia/commit/cd9efa22c7f29acf0e5440a5e5081027d37338b7

Comment 47

[(Inactive after June) George Duan [:gduan] [:喬智]]

Backout this commit due to bug 963009,
https://github.com/mozilla-b2g/gaia/commit/d75a06d9524f00d76e1abc1939290d7911f7cc84

Comment 48

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

Hi Arthur,
previous patch has caused some error due to mozMobileConnections has no method of 'forEach', so I update the loop method in this patch.
Please kindly check again. Thanks.

Comment 49

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8366440 [details] [review]
PR to master

r=me. Thanks for finding the issue.

Comment 50

[(Inactive after June) George Duan [:gduan] [:喬智]]

Thanks Arthur,
https://github.com/mozilla-b2g/gaia/commit/b24e02dff66886f5950a17a9d2cac0dcd26c49a6

Comment 52

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted b24e02dff66886f5950a17a9d2cac0dcd26c49a6 to:
v1.3: c78bf8e35b9791770962379414dab5dfbde1bc8b