Closed Bug 997584 Opened 10 years ago Closed 10 years ago

[B2G] [RIL] mobileConnection::setCallingLineIdRestriction() doesn't work well on DSDS. SIM_1 is affected if set on SIM_2.

Categories

(Firefox OS Graveyard :: RIL, defect)

x86_64
Linux
defect
Not set
normal

Tracking

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

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: hsinyi, Assigned: hsinyi)

References

Details

(Whiteboard: [p=2])

Attachments

(7 files, 6 obsolete files)

9.72 KB, patch
Details | Diff | Splinter Review
9.45 KB, patch
Details | Diff | Splinter Review
9.97 KB, patch
Details | Diff | Splinter Review
4.58 KB, patch
vicamo
: review+
Details | Diff | Splinter Review
922.77 KB, text/plain
Details
9.82 KB, patch
Details | Diff | Splinter Review
4.63 KB, patch
Details | Diff | Splinter Review
Root cause is that we save a preference ril.clir on RadioInterfaceLayer, but the pref isn't DSDS-conscious.

Not sure why we need the pref. If we don't need that, the fix is simply dropped that pref. If we need that, changing the pref format should solve the issue.
Blocks: 995458
Assignee: nobody → htsai
The 'ril.clir' pref is requested from [1]. Not sure if it's safe to remove that from gecko. Has Gaia already handled the setting cross reboot?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=897869
No, gaia does not handle it. I think we should re-evaluate if it is needed to maintain 'ril.clir'.
(In reply to Arthur Chen [:arthurcc] from comment #2)
> No, gaia does not handle it. I think we should re-evaluate if it is needed
> to maintain 'ril.clir'.

Just did experiments. If we don't set a user preference to carrier at boot time, the the clir mode we get is 'Network default' not what we set last time.
No longer blocks: 997601
Depends on: 997601
Per discussion with Arthur, we decided to let gaia take care of storing user preference and set a value at bootup, as what gaia has done for other network settings.

So, this bug will remove "preference kPrefClirModePreference" and not setCLIR() at bootup. Basically, almost bug 897869 will be cleared.
Whiteboard: [p=2]
Target Milestone: --- → 1.4 S6 (25apr)
blocking-b2g: --- → 1.3T?
Attached patch part 1 (obsolete) — Splinter Review
Comment on attachment 8408130 [details] [diff] [review]
part 1

Remove preference "ril.clirMode"
Attachment #8408130 - Attachment description: WIP → part 1
We can't really test setClir/getClir because emulator hasn't supported it yet. This is just for checking the error case.
Attachment #8408130 - Flags: review?(vyang)
Attachment #8408859 - Flags: review?(vyang)
Comment on attachment 8408130 [details] [diff] [review]
part 1

Review of attachment 8408130 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, thank you.
Attachment #8408130 - Flags: review?(vyang) → review+
Comment on attachment 8408859 [details] [diff] [review]
part 2 - test - clir on radio off

Review of attachment 8408859 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/mobileconnection/tests/marionette/head.js
@@ +69,3 @@
>    });
> +  aRequest.addEventListener("error", function() {
> +    deferred.reject(aRequest.error);

Unfortunately this utility function is also referenced in multiple places other than the addition changes here.  The resolve/reject parameter types must be DomEvent.

@@ +445,5 @@
> + */
> +function setRadioEnabled(aEnabled, aServiceId) {
> +  let mobileConn = mobileConnection;
> +  if (aServiceId !== undefined) {
> +    mobileConn = navigator.mozMobileConnections[aServiceId];

You must get mozMobileConnections from workingFrame.  And, this has been appeared in several place, please add a utility function for this, for example, getMozMobileConnectionsByServiceId().

@@ +450,5 @@
> +  }
> +  let request = mobileConn.setRadioEnabled(aEnabled);
> +  return wrapDomRequestAsPromise(request)
> +    .then(function onsuccess() {
> +      log("setRadioEnabled " + aEnabled + " success.");

nit: please use |ok(true, ...)| for debug messages.  |ok(true, ...)| will only appear in logcat, while |log(...)| messages show on console.

@@ +453,5 @@
> +    .then(function onsuccess() {
> +      log("setRadioEnabled " + aEnabled + " success.");
> +    }, function onerror() {
> +      log("setRadioEnabled " + aEnabled + " error.");
> +      ok(false, request.error);

nit: you can well merge them into one |ok(false, ...)| call.

@@ +514,5 @@
> + *
> + * @return A deferred promise.
> + */
> +function setClir(aMode, aServiceId)
> +  log("Set CLIR to " + aMode);

nit: ok(true, "setClir(" + aMode + ", " + aServiceId + ")");

@@ +538,5 @@
> + *
> + * @return A deferred promise.
> + */
> +function getClir(aServiceId) {
> +  log("Get CLIR mode.");

nit: ok(true, "getClir(" + aServiceId + ")");
Attachment #8408859 - Flags: review?(vyang)
Add a utility function getMozMobileConnectionByServiceId()
Attachment #8408859 - Attachment is obsolete: true
Comment on attachment 8409531 [details] [diff] [review]
part 2a- test - getMozMobileConnectionByServiceId

Review of attachment 8409531 [details] [diff] [review]:
-----------------------------------------------------------------

Hi Vicamo,

Comment 9 has been addressed. Please take a look again, thanks!

::: dom/mobileconnection/tests/marionette/head.js
@@ +270,5 @@
> + *
> + * @param aServiceId [optional]
> + *        A numeric DSDS service id. Default: the one indicated in
> + *        start*TestCommon() or 0 if not indicated.
> + * 

nit: ws. I'll remove it in the next version.
Attachment #8409531 - Flags: review?(vyang)
Comment on attachment 8409533 [details] [diff] [review]
part 2b - test - clir on radio off

Review of attachment 8409533 [details] [diff] [review]:
-----------------------------------------------------------------

Hi Vicamo,

Comment 9 has been addressed. Please take a look again, thanks!
Attachment #8409533 - Flags: review?(vyang)
triage: blocks a 1.3T+, 1.3T+ for this bug
blocking-b2g: 1.3T? → 1.3T+
Attachment #8409531 - Flags: review?(vyang) → review+
Comment on attachment 8409533 [details] [diff] [review]
part 2b - test - clir on radio off

Review of attachment 8409533 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/mobileconnection/tests/marionette/head.js
@@ +460,5 @@
> +    .then(function onsuccess() {
> +      ok(true, "setRadioEnabled " + aEnabled + " on " + aServiceId + " success.");
> +    }, function onerror() {
> +      ok(false, "setRadioEnabled " + aEnabled + " on " + aServiceId + " " +
> +         request.error.name);

Since |ok(false, ...)| doesn't throw, the rejected promise will become a resolved one with an undefined resolved value.  So this follows that |setRadioEnabledAndWait| will never reject.  Please either update the comments above, or use |throw request.error.name;| here.
Attachment #8409533 - Flags: review?(vyang) → review+
Sorry I am too eager to land the patches. I should wait for the gaia blocker to not cause any regression.

Backed out the patches:
https://hg.mozilla.org/integration/b2g-inbound/rev/f752e0359a8d
https://hg.mozilla.org/integration/b2g-inbound/rev/8f3bf5e0be90
Let me jump into the discussion guys. We filed and fixed bug 897869 because the permanent CLIR user preference is not saved by the carrier when the user sets it to something different as 'network default' so It resets to default once the device reboots. We can remove safely the work added on bug 897869 but on that bug we also took care of saving the permanent CLIR preference set via MMI code so we should either i) to keep the logic for saving the permanent CLIR preference set via MMI in gecko or ii) to take care of it on Gaia side as well. The second option seems the best one.
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #19)
> Let me jump into the discussion guys. We filed and fixed bug 897869 because
> the permanent CLIR user preference is not saved by the carrier when the user
> sets it to something different as 'network default' so It resets to default
> once the device reboots. We can remove safely the work added on bug 897869
> but on that bug we also took care of saving the permanent CLIR preference
> set via MMI code so we should either i) to keep the logic for saving the
> permanent CLIR preference set via MMI in gecko or ii) to take care of it on
> Gaia side as well. The second option seems the best one.

Hey :jaoo,

Thanks for the reminding. Yes, option II looks good, and Arthur is working on that, see bug 997601.
Should wait for two blockers first, set ETA: 4/29 for now.
Whiteboard: [p=2] → [p=2][ETA: 4/29]
Target Milestone: 1.4 S6 (25apr) → 2.0 S1 (9may)
Comment on attachment 8408130 [details] [diff] [review]
part 1

Need to rebase on bug 1000670.
Attachment #8408130 - Attachment is obsolete: true
The patch is ready. I'll ask for review again once bug 1000670 is review granted.
Comment on attachment 8412408 [details] [diff] [review]
part 1 - fix (v2),  rebased on bug 1000670

Review of attachment 8412408 [details] [diff] [review]:
-----------------------------------------------------------------

Hi Vicamo,

This revision is rebased on bug 1000670. Please take a look again, thanks.
Attachment #8412408 - Flags: review?(vyang)
Comment on attachment 8412408 [details] [diff] [review]
part 1 - fix (v2),  rebased on bug 1000670

Review of attachment 8412408 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.
Attachment #8412408 - Flags: review?(vyang) → review+
Attachment #8409531 - Attachment is obsolete: true
Attachment #8409533 - Attachment is obsolete: true
Attachment #8412408 - Attachment is obsolete: true
Comment on attachment 8415063 [details] [diff] [review]
part 2 - test. r=vicamo, a=1.3t [for v1.3T]

Review of attachment 8415063 [details] [diff] [review]:
-----------------------------------------------------------------

Hi Vicamo,

Since 1.3t code base differs from m-c a lot, this test case is almost rewritten according to what we've done on 1.3t. Could you please take a look? Thanks.
Attachment #8415063 - Flags: review?(vyang)
Comment on attachment 8415063 [details] [diff] [review]
part 2 - test. r=vicamo, a=1.3t [for v1.3T]

Review of attachment 8415063 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. Thank you.
Attachment #8415063 - Flags: review?(vyang) → review+
Patches are ready. Waiting for blockers being landed first.
Whiteboard: [p=2][ETA: 4/29] → [p=2][ETA: 5/5]
Whiteboard: [p=2][ETA: 5/5] → [p=2][ETA: 5/9]
https://hg.mozilla.org/mozilla-central/rev/44dc37d9d982
https://hg.mozilla.org/mozilla-central/rev/4a4030a3d9be
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
snippet:

=== Bootup: CLIR more for both Sims are "hide number (1)" ===
05-12 11:47:32.359 D/RILC    (   97): [0089]> GET_CLIR 
05-12 11:47:32.359 D/RIL     (   97): onRequest: GET_CLIR sState=4
05-12 11:47:34.339 D/RILC    (   97): [0089]< GET_CLIR {1,4}
05-12 11:47:34.339 I/Gecko   (   83): RIL Worker: [0] Handling parcel as REQUEST_GET_CLIR

05-12 11:47:53.839 D/RILC    (  106): [0097]> GET_CLIR 
05-12 11:47:53.839 D/RIL     (  106): onRequest: GET_CLIR sState=4
05-12 11:47:55.799 D/RILC    (  106): [0097]< GET_CLIR {1,4}
05-12 11:47:55.799 I/Gecko   (   83): RIL Worker: [1] Handling parcel as REQUEST_GET_CLIR

=== Set CLIR mode of SIM_0 to "show number (2)" ===

05-12 11:48:11.629 D/RILC    (   97): [0094]> SET_CLIR (2)
05-12 11:48:11.629 D/RIL     (   97): onRequest: SET_CLIR sState=4
05-12 11:48:11.629 D/RILC    (   97): [0094]< SET_CLIR
05-12 11:48:11.629 I/Gecko   (   83): RIL Worker: [0] Handling parcel as REQUEST_SET_CLIR
05-12 11:48:14.939 D/RILC    (   97): [0096]> GET_CLIR 
05-12 11:48:14.939 D/RIL     (   97): onRequest: GET_CLIR sState=4
05-12 11:48:17.399 D/RILC    (   97): [0096]< GET_CLIR {2,4}
05-12 11:48:17.399 I/Gecko   (   83): RIL Worker: [0] Handling parcel as REQUEST_GET_CLIR

=== Then check SIM_1. SIM_1's mode is changed as well ===
05-12 11:48:23.219 D/RILC    (  106): [0119]> GET_CLIR 
05-12 11:48:23.219 D/RIL     (  106): onRequest: GET_CLIR sState=4
05-12 11:48:25.059 D/RILC    (  106): [0119]< GET_CLIR {2,4}
05-12 11:48:25.059 I/Gecko   (   83): RIL Worker: [1] Handling parcel as REQUEST_GET_CLIR
Attachment #8420749 - Attachment mime type: text/x-vhdl → text/plain
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #36)
> Created attachment 8420749 [details]
> log - two sim cards are interactive
> 
> snippet:
> 
> === Bootup: CLIR more for both Sims are "hide number (1)" ===
> 05-12 11:47:32.359 D/RILC    (   97): [0089]> GET_CLIR 
> 05-12 11:47:32.359 D/RIL     (   97): onRequest: GET_CLIR sState=4
> 05-12 11:47:34.339 D/RILC    (   97): [0089]< GET_CLIR {1,4}
> 05-12 11:47:34.339 I/Gecko   (   83): RIL Worker: [0] Handling parcel as
> REQUEST_GET_CLIR
> 
> 05-12 11:47:53.839 D/RILC    (  106): [0097]> GET_CLIR 
> 05-12 11:47:53.839 D/RIL     (  106): onRequest: GET_CLIR sState=4
> 05-12 11:47:55.799 D/RILC    (  106): [0097]< GET_CLIR {1,4}
> 05-12 11:47:55.799 I/Gecko   (   83): RIL Worker: [1] Handling parcel as
> REQUEST_GET_CLIR
> 
> === Set CLIR mode of SIM_0 to "show number (2)" ===
> 
> 05-12 11:48:11.629 D/RILC    (   97): [0094]> SET_CLIR (2)
> 05-12 11:48:11.629 D/RIL     (   97): onRequest: SET_CLIR sState=4
> 05-12 11:48:11.629 D/RILC    (   97): [0094]< SET_CLIR
> 05-12 11:48:11.629 I/Gecko   (   83): RIL Worker: [0] Handling parcel as
> REQUEST_SET_CLIR
> 05-12 11:48:14.939 D/RILC    (   97): [0096]> GET_CLIR 
> 05-12 11:48:14.939 D/RIL     (   97): onRequest: GET_CLIR sState=4
> 05-12 11:48:17.399 D/RILC    (   97): [0096]< GET_CLIR {2,4}
> 05-12 11:48:17.399 I/Gecko   (   83): RIL Worker: [0] Handling parcel as
> REQUEST_GET_CLIR
> 
> === Then check SIM_1. SIM_1's mode is changed as well ===
> 05-12 11:48:23.219 D/RILC    (  106): [0119]> GET_CLIR 
> 05-12 11:48:23.219 D/RIL     (  106): onRequest: GET_CLIR sState=4
> 05-12 11:48:25.059 D/RILC    (  106): [0119]< GET_CLIR {2,4}
> 05-12 11:48:25.059 I/Gecko   (   83): RIL Worker: [1] Handling parcel as
> REQUEST_GET_CLIR

Hi Sam,

According to the log, we only set CLIR to 2 (show number) for SIM_0. However, when we query CLIR mode for SIM_1, we noticed that SIM_1's mode is somehow changed. Would you please check if something goes wrong in rild/modem? Thank you.
Flags: needinfo?(sam.hua)
Hi Hsin,
please check it. u actived the CLIR for SIM1
05-12 11:46:50.040 D/RILC    (  106): [0092]> SET_CLIR (1)
05-12 11:46:50.040 D/RIL     (  106): onRequest: SET_CLIR sState=4
05-12 11:46:50.040 D/RILC    (  106): [0092]< SET_CLIR
05-12 11:46:50.070 I/Gecko   (   83): RIL Worker: [1] Handling parcel as REQUEST_SET_CLIR
and get info should return:
05-12 11:46:50.099 D/AT      (  106): Channel4: AT> AT+CLIR?
05-12 11:46:52.229 D/AT      (  106): Channel4: AT< +CLIR: 1,4
05-12 11:46:52.229 D/AT      (  106): Channel4: AT< OK
05-12 11:46:52.229 D/RILC    (  106): [0093]< GET_CLIR {1,4}


but i don't know why it changed to :
05-12 11:48:23.219 D/AT      (  106): Channel4: AT> AT+CLIR?
05-12 11:48:25.059 D/AT      (  106): Channel4: AT< +CLIR: 2,4
05-12 11:48:25.059 D/AT      (  106): Channel4: AT< OK
05-12 11:48:25.059 D/RILC    (  106): [0119]< GET_CLIR {2,4}
Flags: needinfo?(sam.hua)
could it be reproduced on Tarako?

I think we need to catch modem log.
Flags: needinfo?(htsai)
Call Waiting

05-12 11:47:55.859 D/AT      (  106): Channel4: AT> AT+CCWA=1,2
05-12 11:47:58.639 D/AT      (  106): Channel4: AT< +CCWA: 0,7
05-12 11:47:58.639 D/AT      (  106): Channel4: AT< OK

Call Forward.
05-12 11:47:58.659 D/AT      (  106): Channel4: AT> AT+CCFC=0,2,"",129
05-12 11:48:01.159 D/AT      (  106): Channel4: AT< +CCFC: 0,7
05-12 11:48:01.159 D/AT      (  106): Channel4: AT< OK
05-12 11:48:01.169 D/AT      (  106): Channel4: AT> AT+CCFC=1,2,"",129
05-12 11:48:05.489 D/AT      (  106): Channel4: AT< +CCFC: 1,1,
(In reply to sam.hua from comment #38)
> Hi Hsin,
> please check it. u actived the CLIR for SIM1
> 05-12 11:46:50.040 D/RILC    (  106): [0092]> SET_CLIR (1)
> 05-12 11:46:50.040 D/RIL     (  106): onRequest: SET_CLIR sState=4
> 05-12 11:46:50.040 D/RILC    (  106): [0092]< SET_CLIR
> 05-12 11:46:50.070 I/Gecko   (   83): RIL Worker: [1] Handling parcel as
> REQUEST_SET_CLIR
> and get info should return:
> 05-12 11:46:50.099 D/AT      (  106): Channel4: AT> AT+CLIR?
> 05-12 11:46:52.229 D/AT      (  106): Channel4: AT< +CLIR: 1,4
> 05-12 11:46:52.229 D/AT      (  106): Channel4: AT< OK
> 05-12 11:46:52.229 D/RILC    (  106): [0093]< GET_CLIR {1,4}
> 

Yes, we set CLIR to "1" for both SIMs at boot-up, but we only set CLIR to 2 for SIM_1. So, why we eventually get CLIR mode 2 for SIM_1?

>

This is also my question... So, wondering if modem/rild triggered something surprising...


> but i don't know why it changed to :
> 05-12 11:48:23.219 D/AT      (  106): Channel4: AT> AT+CLIR?
> 05-12 11:48:25.059 D/AT      (  106): Channel4: AT< +CLIR: 2,4
> 05-12 11:48:25.059 D/AT      (  106): Channel4: AT< OK
> 05-12 11:48:25.059 D/RILC    (  106): [0119]< GET_CLIR {2,4}

(In reply to sam.hua from comment #39)
> could it be reproduced on Tarako?
> 

I'll check.

> I think we need to catch modem log.

How could I get modem log?
Flags: needinfo?(htsai)
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #41)
> (In reply to sam.hua from comment #38)
> > Hi Hsin,
> > please check it. u actived the CLIR for SIM1
> > 05-12 11:46:50.040 D/RILC    (  106): [0092]> SET_CLIR (1)
> > 05-12 11:46:50.040 D/RIL     (  106): onRequest: SET_CLIR sState=4
> > 05-12 11:46:50.040 D/RILC    (  106): [0092]< SET_CLIR
> > 05-12 11:46:50.070 I/Gecko   (   83): RIL Worker: [1] Handling parcel as
> > REQUEST_SET_CLIR
> > and get info should return:
> > 05-12 11:46:50.099 D/AT      (  106): Channel4: AT> AT+CLIR?
> > 05-12 11:46:52.229 D/AT      (  106): Channel4: AT< +CLIR: 1,4
> > 05-12 11:46:52.229 D/AT      (  106): Channel4: AT< OK
> > 05-12 11:46:52.229 D/RILC    (  106): [0093]< GET_CLIR {1,4}
> > 
> 
> Yes, we set CLIR to "1" for both SIMs at boot-up, but we only set CLIR to 2
> for SIM_1. 

Sorry, typo. Should be we only set CLIR to 2 for *SIM_0*.

> So, why we eventually get CLIR mode 2 for SIM_1?
> 
> >
>
Sam,

I flashed v1.3t gecko and gaia on Fugu. Fugu seems work fine! CLIR mode for each SIM is not interactive.
Flags: needinfo?(sam.hua)
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #43)
> Sam,
> 
> I flashed v1.3t gecko and gaia on Fugu. Fugu seems work fine! CLIR mode for
> each SIM is not interactive.

This issue is reproducible on tarako, no fugu.
Attachment #8420749 - Attachment description: log - two sim cards are interactive → log - [tarako] two sim cards are interactive
Hi Hsin,

Open dialer, input *#*#83781#*#*, it will open engineer app for tarako.
1 Enter slog, general ,select : Record Modem log
2 Reboot
 the modem log will be catch into T card,in slog/XXXXXXX(datetime)/modem/modem.log

if u can't lunch it, please download our pac file
Flags: needinfo?(sam.hua)
Hi Hsin,
CMCC/CUCC don't support CLIR changed by user, so could u help get modem log?
Thanks!
(In reply to sam.hua from comment #46)
> Hi Hsin,
> CMCC/CUCC don't support CLIR changed by user, so could u help get modem log?
> Thanks!

Sam, I filed bug 1008853. Let's move discussion there. I'll upload modem log there once I get it. Thanks!
See Also: → 1008853
Whiteboard: [p=2][ETA: 5/9] → [p=2][ETA: 5/9][1.4-approval-needed]
ni? owner to prepare v1.4 patch. I will ask for v1.4 uplift approval once the patch is available.
Flags: needinfo?(htsai)
Attached patch [v1.4] part 1Splinter Review
Flags: needinfo?(htsai)
Attached patch [v1.4] part 2 (obsolete) — Splinter Review
Ivan,

Patches for v1.4 are attached. Please refer to attachments, [v1.4] part 1 and [v1.4] part 2.

As v1.4 and m-c differ obviously, it's safe to land after try is green, https://tbpl.mozilla.org/?tree=Try&rev=34908401f6e2
Flags: needinfo?(itsay)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #51)
> Ivan,
> 
> Patches for v1.4 are attached. Please refer to attachments, [v1.4] part 1
> and [v1.4] part 2.
> 
> As v1.4 and m-c differ obviously, it's safe to land after try is green,
> https://tbpl.mozilla.org/?tree=Try&rev=34908401f6e2

Try is orange. I am debugging...
Comment on attachment 8439123 [details] [diff] [review]
[v1.4] part 1

NOTE: This flag is now for security issues only. 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 feature in v1.4
User impact if declined: please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=997601#c39
Testing completed: yes in bug 995458 to verify the complete fix
Risk to taking this patch (and alternatives if risky): Low. 
String or UUID changes made by this patch: no change
Attachment #8439123 - Flags: approval-mozilla-b2g30?
Flags: needinfo?(itsay)
Comment on attachment 8439124 [details] [diff] [review]
[v1.4] part 2

NOTE: This flag is now for security issues only. 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 feature in v1.4
User impact if declined: please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=997601#c39
Testing completed: yes in bug 995458 to verify the complete fix
Risk to taking this patch (and alternatives if risky): Low. 
String or UUID changes made by this patch: no change
Attachment #8439124 - Flags: approval-mozilla-b2g30?
v2 - fix marionette failure

NOTE: This flag is now for security issues only. 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 feature in v1.4
User impact if declined: please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=997601#c39
Testing completed: yes in bug 995458 to verify the complete fix
Risk to taking this patch (and alternatives if risky): Low. 
String or UUID changes made by this patch: no change
Attachment #8439124 - Attachment is obsolete: true
Attachment #8439124 - Flags: approval-mozilla-b2g30?
Attachment #8439728 - Flags: approval-mozilla-b2g30?
https://tbpl.mozilla.org/?tree=Try&rev=12bb763fedb0 try with latest v1.4 patches GREEN.
Comment on attachment 8439123 [details] [diff] [review]
[v1.4] part 1

Review of attachment 8439123 [details] [diff] [review]:
-----------------------------------------------------------------

Can this be cherry picked from Master? Nervous about taking in 1.4
Attachment #8439123 - Flags: approval-mozilla-b2g30?
Comment on attachment 8439728 [details] [diff] [review]
[v1.4] part 2 - v2

Needs to land on dolphin branch
Attachment #8439728 - Flags: approval-mozilla-b2g30?
Whiteboard: [p=2][ETA: 5/9][1.4-approval-needed] → [p=2][ETA: 5/9][1.4-approval-needed][dolphin_land]
Comment on attachment 8439123 [details] [diff] [review]
[v1.4] part 1

NOTE: This flag is now for security issues only. 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 feature in v1.4
User impact if declined: please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=997601#c39
Testing completed: yes in bug 995458 to verify the complete fix
Risk to taking this patch (and alternatives if risky): Low. 
String or UUID changes made by this patch: no change
Attachment #8439123 - Flags: approval-mozilla-b2g30?
Comment on attachment 8439728 [details] [diff] [review]
[v1.4] part 2 - v2

NOTE: This flag is now for security issues only. 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 feature in v1.4
User impact if declined: please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=997601#c39
Testing completed: yes in bug 995458 to verify the complete fix
Risk to taking this patch (and alternatives if risky): Low. 
String or UUID changes made by this patch: no change
Attachment #8439728 - Flags: approval-mozilla-b2g30?
Comment on attachment 8439123 [details] [diff] [review]
[v1.4] part 1

Approved for 1.4.
Attachment #8439123 - Flags: approval-mozilla-b2g30? → approval-mozilla-b2g30+
Comment on attachment 8439728 [details] [diff] [review]
[v1.4] part 2 - v2

Approved for 1.4.
Attachment #8439728 - Flags: approval-mozilla-b2g30? → approval-mozilla-b2g30+
You need to log in before you can comment on or make changes to this bug.