820119 - Problem switching between default and custom APN settings

Status: RESOLVED INVALID

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

Description

[Greg Grisco]

1. Go to Cellular & Data, select Data settings

Cingular410 is default setting. It was APN of "wap.cingular" and Identifier of "[e-mail]".

2. Change APN to be some other tag like "test", press Ok.
3. restart the phone
4. Go back to Cellular & Data, select Data settings

(custom settings) is now the current selection. I can see the APN still set to "test"

5. Change selection back to "Cingular410"

APN is back to "wap.cingular"

6. Change selection back to (custom settings)

Expected to see "test" APN, but instead, APN still says "wap.cingular".

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

qawanted to understand how bad this issue is and if this issue is reproducible

Comment 2

[Joe Cheng [:jcheng] (please needinfo)]

BB+ bug is now for C3 milestone

Comment 3

[Steve Chung [:steveck]]

Attachment: Patch for cache the custom settings value temporary

Comment 4

[Fabien Cazenave [:kaze]]

Comment on attachment 692196 [details]
Patch for cache the custom settings value temporary

I think there’s a misunderstanding here: the description (comment #0) is precisely the expected behavior.

 • The APN list displays carrier names, see the “carrier” field in the APN database: /shared/resource/apn.json.

 • For each carrier there are several associated preferences: apn, user, password, proxy, port… and as soon as one of these preferences is changed manually, the APN selector is set to “(custom)”, in order to indicate that we’re *NOT* using a preset.

 • The “apn” setting is not the carrier name either. Sometimes it corresponds to the carrier name, but that’s not a rule at all.

The current UI works — Beatriz (TEF) has validated it. If you want to propose another UI, let’s get some UX input here please. And if you want to allow creating a new APN entry in the database, that’d be a much more complex task.

So unless I completely misunderstood something, I think we should close this bug as RESOLVED/INVALID.

Comment 5

[Greg Grisco]

Given your explanation, the behavior makes sense now.  It just wasn't obvious to me as a user why it was behaving the way it was.