Closed Bug 991628 Opened 11 years ago Closed 11 years ago

[Settings][OMA CP] Not possible to select an APN received via OMA CP message if there is already one with the same name

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
1.4 S6 (25apr)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: isabelrios, Assigned: jaoo)

Details

(Whiteboard: [cert])

Attachments

(4 files, 4 obsolete files)

1.3 04/03 buri build: Gecko-1bbed3c Gaia-c5cd3a1 STEPS Receive an OMA CP message with data APN Accept it and store the APN Receive the same OMA CP message again Accept it again and store the APN Go to Settings -> Cellular and Data -> Data settings and try to select the second APN received and stored EXPECTED It should be possible to select any of the APN stored and listed in Data Settings ACTUAL When there are two APNs with the same name, it is not possible to select the second one of the list
Summary: [Settings][OMA CP] Not possible to select an APN received via OMA CP message and there is already one with the same name → [Settings][OMA CP] Not possible to select an APN received via OMA CP message if there is already one with the same name
Go for it. I'll fix this bug asap. Thanks.
Assignee: nobody → josea.olivera
Thanks Jose Antonio. Bug reported as certification blocker, nominating to 1.3.
blocking-b2g: --- → 1.3?
blocking-b2g: 1.3? → 1.3+
Attached patch WIP (obsolete) (deleted) — Splinter Review
WIP patch.
Attached patch v1 (obsolete) (deleted) — Splinter Review
v1 patch. It still needs tests.
Attached patch v2 (obsolete) (deleted) — Splinter Review
Arthur, let me share some background about what is going on here. If a couple or more APNs have the same name (same value for carrier property) there was an issue while switching between those APNs. This patch fixes that issue by using a hash code for the value property for the input element. Could you take a look a it please? I added a test case for the issue, hope it helps.
Attachment #8402572 - Attachment is obsolete: true
Attachment #8403158 - Flags: review?(arthur.chen)
Whiteboard: cert
Whiteboard: cert → [cert]
Attached patch v3 (obsolete) (deleted) — Splinter Review
Arthur, just addressed the comment you left in the PR. Thanks. Could you take a look a it again please? Thanks. PS. PR updated. Feel free to review the patch through it.
Attachment #8403158 - Attachment is obsolete: true
Attachment #8403158 - Flags: review?(arthur.chen)
Attachment #8403839 - Flags: review?(arthur.chen)
Comment on attachment 8403839 [details] [diff] [review] v3 Review of attachment 8403839 [details] [diff] [review]: ----------------------------------------------------------------- The patch looks good to me. The only one concern is that is it possible to use a more sophisticated hash algorithm? The chance of collision may be small but I think it is always good using a more robust method.
Attachment #8403839 - Flags: review?(arthur.chen)
Attached patch v4 (deleted) — Splinter Review
Function changed. Could you take a look a it again please? Thanks.
Attachment #8403839 - Attachment is obsolete: true
Attachment #8403933 - Flags: review?(arthur.chen)
Comment on attachment 8403933 [details] [diff] [review] v4 r=me, thank you! Please also create a pull request against v1.3 branch for running travis.
Attachment #8403933 - Flags: review?(arthur.chen) → review+
Travis passes for both master and v1.3 branches. I tested both patches on peak device and everything seems to work correctly. Gaia master branch patch landed at https://github.com/mozilla-b2g/gaia/commit/5c56b25486e2b9ac438ef9c3a7825ed4445d5b34. Thanks Arthur!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S5 (11apr)
Please request approval-gaia-v1.3 when this is ready for uplift.
Flags: needinfo?(josea.olivera)
Target Milestone: 1.4 S5 (11apr) → 1.4 S6 (25apr)
Just checked the current behavior on 1.4 today's buri build: Gecko-3f64d65 Gaia-961f7d4 Now it is possible to select any of the apns with the same name, that is great. But, another issue happens. If there are for example three apns with the same name, and the third of them is selected, if data settings menu is closed and open again, then the first one is selected automatically. Please see video file attached. Instead of re-opening this bug if you agree I will open a follow up one.
Attached video first apn selected automatically (deleted) —
Follow up bug 998914 already open
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #14) > Still waiting on the v1.3 approval request.
Comment on attachment 8404676 [details] [v1.3] Pointer to Github PR https://github.com/mozilla-b2g/gaia/pull/18172 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): DSDS stuff / bug 962453 [User impact] if declined: If there are some APNs with the same carrier name the user is not able to switch between them. [Testing completed]: Yes, unit test added too. [Risk to taking this patch] (and alternatives if risky): Low, in fact this is a corner case. I mean all the APN in the apn.json data base have different names. Only APNs set through OMA client provisioning (CP) could have the same carrier name for all of them and the carrier rarely sends this APNs to the device. [String changes made]: No changes.
Attachment #8404676 - Flags: approval-gaia-v1.3?(fabrice)
Flags: needinfo?(josea.olivera)
Attachment #8404676 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: