Provide an activity for "enable full devtools mode"

RESOLVED FIXED in Firefox OS master

Status

P1
normal
RESOLVED FIXED
3 years ago
a year ago

People

(Reporter: drs, Assigned: arthurcc)

Tracking

unspecified
2.2 S14 (12june)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.5+, b2g-master fixed)

Details

(Whiteboard: [spark])

User Story

We need a nice activity and dialog from within the Settings app. It will need to explain the benefits and risks of enabling developer mode, and then present the user with the option to enable it.

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
See bug 1160235, particularly bug 1160235 comment 11.
(Reporter)

Comment 1

3 years ago
Here is the content that I think we have to cover:

Good:
* Apps can go wild and do crazy things.
* Web components are enabled for all content. I don't think this is worth mentioning.

Bad:
* Developer mode basically knocks down all security.
* The user's device will be factory reset, and lose all data.
* Once this mode is set, the user can't go back.
** This isn't exactly true, but it's not possible to revert this change without desktop support.

Thus, here's my suggestion about what we can do:

* When the Settings app receives the activity, it handles it with "disposition": "window". This window presents a dialog, which says:

  "Would you like to enable developer mode?

  Developer mode unlocks all permissions on your device, and allows apps to do anything with it. You can use this if you'd like to experiment with developer tools and customizing your device.

  THIS WILL DISABLE ALL SECURITY MEASURES ON YOUR DEVICE.

  THIS WILL DELETE ALL YOUR DATA AND FACTORY RESET YOUR DEVICE.

  YOU CANNOT DISABLE THIS MODE AFTER ENABLING IT.

  (Cancel) (Enable)"

Tapping "Cancel" will close the activity window and return to wherever it was triggered from. "Enable" will display a second dialog, with the following text:

  "Are you sure you want to enable developer mode?

  Tap 'Enable' X more times to continue.

  (Cancel) (Enable)"

X will start as 10 and be decremented by 1 every time the user taps on "Enable". When it reaches 0, we will follow the same process as when the user taps "enable full devtools" in the current developer menu.

Fabrice, Paul, do you think I'm missing anything here? Jacqueline, do you have any thoughts on how to present this?
Flags: needinfo?(ptheriault)
Flags: needinfo?(jsavory)
Flags: needinfo?(fabrice)
(Reporter)

Comment 2

3 years ago
Arthur, can you take this? This is really important for making Spark user-friendly, and without it, our new apps will be very hard to enable and use. Thanks!
Flags: needinfo?(arthur.chen)
I can help on this. A few comments below:

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #1) 
> Thus, here's my suggestion about what we can do:
> 
> * When the Settings app receives the activity, it handles it with
> "disposition": "window". This window presents a dialog, which says:
Any particular reason of using window disposition? All activities handled in settings app were inline disposition so the running instance of settings app won't be affected.

And will there be an entry point in settings app to enable this? Maybe in the developer panel?
Flags: needinfo?(arthur.chen) → needinfo?(drs)
Looks ok to me since this just re-uses the factory reset mechanism.
(Reporter)

Comment 5

3 years ago
(In reply to Arthur Chen [:arthurcc] from comment #3)
> I can help on this. A few comments below:

Great, thanks! Could we assign it to you then?

> Any particular reason of using window disposition? All activities handled in
> settings app were inline disposition so the running instance of settings app
> won't be affected.

That's fine, it just made sense to me since all we'd be doing is displaying a dialog. We could inline it instead.

> And will there be an entry point in settings app to enable this? Maybe in
> the developer panel?

Yeah, I think what we should do is make the "Reset and Enable Full DevTools" button display the dialog that I proposed, so that it's more clear what it's doing. The activity would be an alternate path to it.

Alternatively, we could just re-use the existing dialog. I don't think that it's detailed enough, though, and it should be a bit harder to activate.
Flags: needinfo?(drs)
Flags: needinfo?(fabrice)
Assignee: nobody → arthur.chen
So.... you want to allow ANY website to launch a prompt, where the user has a 50/50 chance to wipe all the data on the phone. I don't care what you say on that prompt, there will still be users who click this. 

Can we make this activity just do nothing if the user hasn't already enabled the developer menu? That would be enough I think. Its pretty crazy otherwise. I know that makes usability harder but this is pretty insane as it currently stands.

Also if you want to be able to turn this on, there needs to be a way to turn it off on the phone. Not having that is just lazy. This is why I was suggesting the second preference (allowed vs enabled). 

It would be great if someone could write up a complete description of this feature on the wiki though so the information isnt scattered all over many bugs.
Flags: needinfo?(ptheriault)
(Reporter)

Updated

3 years ago
Flags: needinfo?(drs)
Blocks: 1161157
(Reporter)

Comment 7

3 years ago
(In reply to Paul Theriault [:pauljt] from comment #6)
> Can we make this activity just do nothing if the user hasn't already enabled
> the developer menu? That would be enough I think. Its pretty crazy
> otherwise. I know that makes usability harder but this is pretty insane as
> it currently stands.

Unless there are any objections, we're going to go ahead with this. We're going to enable the developer menu by default in the Spark customization, though.

> Also if you want to be able to turn this on, there needs to be a way to turn
> it off on the phone. Not having that is just lazy. This is why I was
> suggesting the second preference (allowed vs enabled). 

That's a good point. I'll file a bug for this.

> It would be great if someone could write up a complete description of this
> feature on the wiki though so the information isnt scattered all over many
> bugs.

I'll add this to the Spark wiki page. [1] Leaving my needinfo set to remind me.

[1] https://wiki.mozilla.org/Firefox_OS/Spark
(Reporter)

Updated

3 years ago
See Also: → bug 1168516
(Reporter)

Updated

3 years ago
See Also: → bug 1168563
(Reporter)

Updated

3 years ago
Blocks: 1168567
No longer blocks: 1111748
Flags: needinfo?(drs)
(Reporter)

Comment 8

3 years ago
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #7)
> Unless there are any objections, we're going to go ahead with this. We're
> going to enable the developer menu by default in the Spark customization,
> though.

Filed bug 1168516.

> > Also if you want to be able to turn this on, there needs to be a way to turn
> > it off on the phone. Not having that is just lazy. This is why I was
> > suggesting the second preference (allowed vs enabled). 
> 
> That's a good point. I'll file a bug for this.

Filed bug 1168563.

> I'll add this to the Spark wiki page. [1] Leaving my needinfo set to remind
> me.
> 
> [1] https://wiki.mozilla.org/Firefox_OS/Spark

Information added here, though I'm going to be writing a lot more shortly: https://wiki.mozilla.org/Firefox_OS/Spark#Developer_Mode

I also created a meta bug for developer mode in Spark. This is bug 1168567, alias "spark-dev-mode".
(Reporter)

Comment 9

3 years ago
Arthur, please see comment 7. Since we can no longer expose the "reset and enable full dev tools" functionality from an activity if the developer menu is disabled, we have to come up with an alternative handling.

My suggestion is that, if the developer menu is disabled, but the Settings app is handling a "reset and enable full dev tools" activity, we display a read-only dialog with the following text:

"
Developer menu not enabled
---

Developer Mode can't be enabled without the developer menu first being enabled.

Please enable it from Settings > Device Information > More Information > Developer Menu.

[Close]
"

If the developer menu is already enabled, then we proceed as previously planned in comment 1.

Note that this shouldn't be an issue for the initial Spark release, since we're going to be enabling the developer menu pref by default (bug 1168516). But that isn't a good permanent solution.
Flags: needinfo?(arthur.chen)
Okay, I'll be working on this in these few days.
Flags: needinfo?(arthur.chen)
Status: NEW → ASSIGNED
Created attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master
Comment on attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master

EJ, could you help review this patch? Note that I make the panel display the content of the first dialog instead of using DialogService for faster response.

Doug, could you help check whether this implemented as what you have in mind?

You may trigger the activity by:

  new MozActivity({
    name: 'configure',
    data: {
      target: 'device',
      section: 'full_developer_mode'
    }
  })

Thanks!
Attachment #8612784 - Flags: review?(ejchen)
Attachment #8612784 - Flags: feedback?(drs)
(Reporter)

Comment 13

3 years ago
Comment on attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master

Justin, could you check this please?
Attachment #8612784 - Flags: feedback?(drs) → feedback?(jdarcangelo)
Comment on attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master

LGTM. The only thing I might consider changing is swapping enable-full-dev-mode-first-warning-msg-1 and enable-full-dev-mode-first-warning-msg-2. To me, at least, the "THIS WILL DELETE ALL YOUR DATA AND FACTORY RESET YOUR DEVICE." message is more drastic and would definitely cause me to think twice before continuing, so it makes sense for it to be the first prompt. Also, it would be nice to see a unit test or a comment block showing how to invoke the MozActivity.
Attachment #8612784 - Flags: feedback?(jdarcangelo) → feedback+
Comment on attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master

Thanks Arthur, left some comments for this patch on GitHub, please go check it when you got time ! Basically I think this PR is nice and there is only few things that we need to discuss first.

f+
Attachment #8612784 - Flags: review?(ejchen) → feedback+
(In reply to Arthur Chen [:arthurcc] from comment #12)
> You may trigger the activity by:
> 
>   new MozActivity({
>     name: 'configure',
>     data: {
>       target: 'device',
>       section: 'full_developer_mode'
                  ~~~~~~~~~~~~~~~~~~~  wrong name
>     }
>   })

This comment is misleading. For someone who wants to try this webActivity, please make sure you are under any app and open your Nightly to Console page and type this : 

  new MozActivity({
    name: 'configure',
    data: {
      target: 'device',
      section: 'full-developer-mode'
    }
  })

Then everything should work ! Thanks.
Blocks: 1170703
Comment on attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master

EJ, the patch was updated to the comments. Could you help take a look at it again? Note that I did not change the part of using break elements and closing an activity in a dialog. Reasons please refer to the PR, thanks!
Attachment #8612784 - Flags: review?(ejchen)
Comment on attachment 8612784 [details] [review]
[gaia] crh0716:1163889 > mozilla-b2g:master

Thanks Arthur, r+ with few nits !!
Attachment #8612784 - Flags: review?(ejchen) → review+
Nits addressed. Thanks, EJ!
Keywords: checkin-needed
Keywords: checkin-needed
All tests were passed: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=c46cbacb7b73e7eda4161a071651843f11072218

master: 0c7bc81137bedf948b1e0b01a739785241f2f2c5
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Reporter)

Updated

3 years ago
Blocks: 1173522
blocking-b2g: spark+ → 2.5+
status-b2g-v2.5: --- → fixed
status-b2g-master: --- → fixed
Target Milestone: --- → 2.2 S14 (12june)
status-b2g-v2.5: fixed → ---
Flags: needinfo?(jsavory)
You need to log in before you can comment on or make changes to this bug.