Closed Bug 1020580 Opened 8 years ago Closed 8 years ago

Erase fails when a call to getDeviceStorage returns null


(Firefox OS Graveyard :: FindMyDevice, defect)

Not set


(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

2.0 S4 (20june)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed


(Reporter: ggp, Assigned: kglazko)



(1 file)

Erase crashes when a call to getDeviceStorage() returns null for some of the storages [1]. Note that we should probably also guard against _all_ calls returning null, even though that sounds like an unlikely corner case.

Kate found the bug and is interested in working on it, so I'm assigning it to her for now. It should be an easy fix, and I'll be mentoring. I can fix it myself if she doesn't find the time to do it.

Attachment #8434513 - Flags: review?(21)
Comment on attachment 8434513 [details] [review]
Proposed Fix for 'Erase' feature in FMD

Looks good!

Please rebase the patch on top of current gaia and push -f to re-run the tests, since your last run ended up red. It's probably not your fault and the rebase should give you a green run.

After that, please add 'checkin-needed' to the Keywords in the bug so a sheriff can land it for you. Then you'll be done :)
Attachment #8434513 - Flags: review?(ggoncalves) → review+
Keywords: checkin-needed
Closed: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
blocking-b2g: --- → 2.0?
Resolution: FIXED → ---
Apparently this was never uplifted?
Comment on attachment 8434513 [details] [review]
Proposed Fix for 'Erase' feature in FMD

This is a blocker that slipped by us, apologies.

NOTE: Please see to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 1020580
[User impact] if declined: Erase feature will not work properly.
[Testing completed]: Travis and automated.
[Risk to taking this patch] (and alternatives if risky): None.
[String changes made]: None.
Attachment #8434513 - Flags: approval-gaia-v2.0?(bbajaj)
blocking-b2g: 2.0? → 2.0+
Attachment #8434513 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Whiteboard: upliftneeded
Please don't reopen bugs for uplifts. Bug resolution tracks landing on trunk/master, not release branches. Status flags are for tracking uplifts.

Also, I'm not sure who tracks the "upliftneeded" whiteboard flag, but I'm guessing the people actually doing the uplifts (namely, myself) aren't. I rely on bug queries (which conveniently rely on things like bug resolution being properly set). Please don't reinvent new solutions to things without discussing them with relevant stakeholders first. If you have any questions or concerns about the process, I'm available on IRC pretty much all day during US working hours.
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Whiteboard: upliftneeded
Target Milestone: --- → 2.0 S4 (20june)
Sorry about the whiteboard flag, Ryan! There were a few that were lost in the shuffle (not due to releng) I needed a sanity check on. I will follow up with QA on not re-opening.
Hi Guilherme,

Could you please provide the detailed reproduce steps or video for me to verify this bug?
Thank you very much!
Flags: needinfo?(ggoncalves)
I'm not sure this needs to be verified anymore. All of the relevant code was removed in bug 1040747.
Flags: needinfo?(ggoncalves)
You need to log in before you can comment on or make changes to this bug.