Closed Bug 1184806 Opened 9 years ago Closed 9 years ago

Factory Reset and Enable Full Devtools after flashing gives the reset phone dialog instead of the devmode dialog

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nhirata, Assigned: yzen)

References

Details

Attachments

(1 file)

1. flash the device 2. go to settings -> Developer -> Factory Reset and Enable Full DevTools Expected : DevMode version of the reset Actual: regular phone reset warning Note: Build ID 20150716195500 Gaia Revision 77bc0d940bde2a5d2d4dfadfcccc6d8d77456d36 Gaia Date 2015-07-16 16:25:03 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/8d262d1d0ae5 Gecko Version 42.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150716.193931 Firmware Date Thu Jul 16 19:39:39 UTC 2015 Bootloader s1
Yura, can you look at this please?
Flags: needinfo?(yzenevich)
Flags: needinfo?(yzenevich)
Attachment #8640002 - Flags: review?(gasolin)
Assignee: nobody → yzenevich
If `YOU CANNOT DISABLE THIS MODE AFTER ENABLING IT`, I'd suggest set the switch button as disabled when the value is true. Or the user will be able to tap the switch and see the warning dialog with incorrect messages.
The patch looks fine but the UX flow looks strange to me. 1 (unrestrict = false, can't use add on). go to developer panel, tap `Factory Reset and Enable Full DevTools` After reset, it will enable full dev tools 2 (unrestrict = true, can use add on). go to developer panel, tap `Factory Reset and Enable Full DevTools` will pop ordinary `factory reset` message After reset, it will be in normal mode without full dev tools. User will not know what should be happen at 2. since we have warned `YOU CANNOT DISABLE THIS MODE AFTER ENABLING IT` at 1. The issue is this item mix the responsibility of Full devtools mode and the Factory Reset. I think a proper UX flow might be separate them to 2 items: * Full Devtools <switch on/off> * Factory Reset <link looks like `Launch FTU`> * Full Devtools default state -> when switch is on (when seeing the 'devtools.unrestricted' value is on), disable user interaction. When toggle Full Devtools on -> show full-developer-mode-warning, reset when procedure complete. When toggle Full Devtools off -> since switch is disabled, this is not possible * Factory Reset -> normal factory reset dialog and functionality, but should respect Full Devtools' state (root/normal). @harly, @yura how do you think?
Flags: needinfo?(yzenevich)
Flags: needinfo?(hhsu)
(In reply to Fred Lin [:gasolin] from comment #4) > The patch looks fine but the UX flow looks strange to me. > > 1 (unrestrict = false, can't use add on). go to developer panel, tap > `Factory Reset and Enable Full DevTools` > After reset, it will enable full dev tools > > 2 (unrestrict = true, can use add on). go to developer panel, tap `Factory > Reset and Enable Full DevTools` will pop ordinary `factory reset` message > After reset, it will be in normal mode without full dev tools. > > User will not know what should be happen at 2. since we have warned `YOU > CANNOT DISABLE THIS MODE AFTER ENABLING IT` at 1. > > The issue is this item mix the responsibility of Full devtools mode and the > Factory Reset. > > I think a proper UX flow might be separate them to 2 items: > > * Full Devtools <switch on/off> > * Factory Reset <link looks like `Launch FTU`> > > > * Full Devtools default state -> when switch is on (when seeing the > 'devtools.unrestricted' value is on), disable user interaction. > When toggle Full Devtools on -> show full-developer-mode-warning, reset when > procedure complete. > When toggle Full Devtools off -> since switch is disabled, this is not > possible > * Factory Reset -> normal factory reset dialog and functionality, but should > respect Full Devtools' state (root/normal). > > > @harly, @yura how do you think? Hi Fred, so your suggestion makes total sense. I looked into how dev mode is coupled with factory reset. It looks like with the current model we are not able to separate the two. Since we have no other means ATM to set b2g prefs from the Settings (or anywhere on device for that matter). One thing that can get better though, is the wording of the dialog. Irreversible part is actually related to factory reset from what I know, not the dev mode being enabled. So we can make it more clear. This means that the dev mode toggle can actually be turned off. Both operations however trigger factory reset. Paul, do you have any suggestions or perhaps you know about the future plans for dev mode and its necessity.
Flags: needinfo?(yzenevich) → needinfo?(ptheriault)
Ideally we do not want to factory reset at all to enable/disable dev mode.
Bug 1177002 is relevant here too. Ideally we would not want to erase user data here.
Note that we're retiring the Spark features, so we won't need DM for them anymore. The only things blocking us from removing DM are 1) figuring out a way to grandfather out foxfooders who are currently using it and/or have the Spark features installed, 2) allowing developers access to certified API's, which I understand the new security model should deal with.
Comment on attachment 8640002 [details] [gaia] yzen:bug-1184806 > mozilla-b2g:master I realize that user can still use `Device Information > Reset Phone` to factory reset their device. So it's fine to have the switch in developer panel here. Harly may like to suggest a better wording for the item title though.
Attachment #8640002 - Flags: review?(gasolin) → review+
For the wording, I suggest that we use "Full DevTools" instead of "Factory Reset and Enable Full Devtools". When user enable it, system will display the dialog and explain to the user that this will require factory reset.
Flags: needinfo?(hhsu)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I filed this bug ages ago, but nothing has come of it: https://bugzilla.mozilla.org/show_bug.cgi?id=1176003 Basically on a rooted device, there is no need to wipe/factory reset before enabling developer mode, since you can manually enable developer mode by manually changing preferences. (which is what webide does AFAIK). But if we are going to remove developer mode anyways as per comment 8 (which I would be in favor of) then I guess there is no sense improving it. In terms of the new security model dealing with certified permissions - that _may_ be the case, we certainly want to be more flexible. But I assume you mean to find a way to grant certified permissions to add-ons like those used in spark, and I'm not aware of any proposals of how to secure that.
Flags: needinfo?(ptheriault)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: