855642 - [Settings] Operator didn't change appropriately when selecting operator manually

Status: VERIFIED FIXED

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

Description

[Al Tsai [:atsai]]

STR:
1. Settings -> Cellular & Data -> Network Operator
2. Disable Automatic selection
3. Select operator A
4. Select operator B
5. Back -> Network Operator

Expected:
Step 3: original operator should turn to "Available", and operator A becomes "Connected" after connected.
Step 4: Operator A turns to "Available", and operator B becomes "Connected"
Step 5: Operator B should be "current"

Actual:
The status won't changes until reopen settings app

Comment 1

[Al Tsai [:atsai]]

It's kind of confusion about "Connected" and "Current". What should be the difference between them?

Add UX to help if need UX to refine status changing.

Comment 2

[David Palomino [:dpalomino]]

Hi, 

I think this could be quite confusing to the user when performing manual network selection... user will think that indeed manual network selection has failed when it's been successful. 

I'd suggest to nominate this for tef+. 

Thks!
David

Comment 3

[David Palomino [:dpalomino]]

Hi, 

Blocking issue reported during certification in Spain, adding dep, and marking as P1. 

Thanks!
David

Comment 5

[Evelyn Hung]

This is not a pure UI(gaia) issue. Performing available operator network scan costs 2 to 10 minutes every time. When the operator switch happens, it's not allowed to re-scan just for UI update (while we use this trick when Wifi connected). Therefore, we need Gecko support to notify Gaia there are network status changes. A possible Gaia workaround before getting Gecko status update support, we could record the original and current(switched to) networks in Gaia, and always display 'Available' for the original one (which may not be the real state, it may be out of range, forbidden or some states Gaia can't be aware).

cc hsinyi for Gecko part.

Comment 6

[Kai-Chih Hu [:khu]]

Triaged on April 9th: Ken will check this case first.

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Evelyn, RIL already notifies DOM when 'network status' changed via onvoicechanged and ondatachanged. But I guess what you were mentioning was 'networks' so that gaia doesn't need to actively query getNetworks() in carrier.js. Is my guessing right? If so, then unfortunately, per my very quick check, RIL (platform) isn't notified when networks change, either. If we want to get information of networks, we need to query.

Comment 8

[Evelyn Hung]

Hey Hsin-yi, yes I'm talking about a "networks" property or event hook for notifying its status changed. So per your explanation, Gecko has no means to receive network change except proactive query by itself. Are you (or Ken) think it's okay if we do the Gaia workaround like my comment 5 said? That's, "record the original and current(switched to) networks in Gaia, and always display 'Available' for the original one". is it a good idea? If so, feel free to re-assign this issue to me.

Comment 9

[Juan Perez-Bedmar [:juanpbf]]

Adding some colleagues in CC

Comment 10

[Ken Chang[:kenkai]]

Hi Evelyn, I have another solution for this bug. It is very similar with yours, but a little difference. Gaia keeps the currently registered network (PLMN). When displaying the available networks list, Gaia will set the "connected" only if the available network(PLMN) is same as the currently registered network(PLMN).
Because the modifications of these solutions are in Gaia, I assign this bug to you. Thanks. :)

Comment 11

[Evelyn Hung]

Attachment: point to https://github.com/mozilla-b2g/gaia/pull/9081

I did the proposed Gaia workaround as comment 8 said.

Comment 12

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

Comment on attachment 735650 [details]
point to https://github.com/mozilla-b2g/gaia/pull/9081

Good work. r+ with the comment addressed.

Comment 13

[Evelyn Hung]

merged into gaia-master
https://github.com/mozilla-b2g/gaia/commit/24deff896b0e4965a485ee8759ee0ca00a6ad69b

Comment 14

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

Uplifted commit 24deff896b0e4965a485ee8759ee0ca00a6ad69b as:
v1-train: d26cd19778034a1334ae2c026aa84bd75b0248fc
v1.0.1: 4340e965dc0c345642273ed842e386b9ef999793

Comment 15

[Carlos Martínez Toral [:carlosmartinez]]

Cannot be verified until AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.078 is used in inari builds.

Comment 16

[David Palomino [:dpalomino]]

Hi, 

Thanks Carlos. If possible, please check this with ikura. 

Thks!
David

Comment 17

[Al Tsai [:atsai]]

Assumed fixed, close it. Open a new one if it happens again.