1448107 - Disable gcli

Status: RESOLVED WONTFIX

(DevTools Graveyard :: Graphic Commandline and Toolbar, enhancement, P2)

Description

[Alexandre Poirot [:ochameau]]

Per bug 1429421, we should start phasing out gcli by disabling it first.

We can do that by setting devtools.toolbar.enabled to false here:
https://searchfox.org/mozilla-central/source/devtools/client/preferences/devtools.js#17

If you toggle this pref manually in about:config and restart firefox, gcli will work around. Having the pref set to false doesn't break anything relying on gcli (from what I can see).

Note that this will disable gcli, even for people that used it on next Firefox update. I don't know if we have any data (I don't see any pref) that would allow detecting if user already opened it once.

Here is a try run with the pref flipped, I imagine it will break all tests relying on gcli. It may require manually setting the pref to true in them:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=937be5a9beb724fe214f5dd432a1545858d76bf7

Comment 1

[Alexandre Poirot [:ochameau]]

Assuming I can provide a patch with a green try.

Should we do that? In FF61? Uplift to 60?
Should we coordinate with mailing list/blog/twitter/whatever post?
Should we put in-product warning message somehow/somewhere?

Comment 2

[Alexandre Poirot [:ochameau]]

(In reply to Alexandre Poirot [:ochameau] from comment #0)
> Here is a try run with the pref flipped, I imagine it will break all tests
> relying on gcli. It may require manually setting the pref to true in them:
>  
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=937be5a9beb724fe214f5dd432a1545858d76bf7

It looks like tests are magically still green even with the pref off. APIs used to open the toolbar must bypass this pref...

Comment 3

[Patrick Brosset <:pbro>]

(In reply to Alexandre Poirot [:ochameau] from comment #1)
> Assuming I can provide a patch with a green try.
> 
> Should we do that? In FF61? Uplift to 60?
I don't think there's a need for uplift here, is there?
> Should we coordinate with mailing list/blog/twitter/whatever post?
> Should we put in-product warning message somehow/somewhere?
See bug 1429421 comment 21. I'll send an email to communicate the intent to unship. I'll let Harald decide if some product messaging about this is necessary.

Also adding dev-doc-needed so we remove that part of the docs when this bug is done.

Comment 4

[:Harald Kirschner :digitarald]

As commented in https://bugzilla.mozilla.org/show_bug.cgi?id=1429421#c22 this is a go.

> Should we do that? In FF61? Uplift to 60?

Try to uplift to 60.

> Should we coordinate with mailing list/blog/twitter/whatever post?

Patrick is working on the mailing list intent email.

> Should we put in-product warning message somehow/somewhere?

So far mentioning in the release notes should be enough, but the intent email will tell for sure.

Comment 5

[Patrick Brosset <:pbro>]

Intent to unship email sent: https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/0WoBr_HFLAA

Comment 6

[Julien Cristau [:jcristau]]

What's the reason for doing this in 60 rather than 61, when 60 is already on beta for several weeks?

Comment 7

[:Harald Kirschner :digitarald]

(In reply to Julien Cristau [:jcristau] from comment #6)
> What's the reason for doing this in 60 rather than 61, when 60 is already on
> beta for several weeks?

- Getting a headstart to disable the rarely used feature, so we can get user feedback on anything we missed in our analysis.
- Give users one release headstart to change their development flows if needed.
- Code removal is blocking other projects, so we still want to remove by 61 but with the phased rollout.

Do you have other recommendations than disabling as uplift? Should we consider SHIELD?

Comment 8

[:Harald Kirschner :digitarald]

Forgot to add that many commands are broken with e10s, which also raises the urgency to clean this feature up.

Comment 9

[Patrick Brosset <:pbro>]

About the dev-doc-needed flag here:
We shouldn't only update the doc by removing mentions of gcli, we should also make sure alternatives to commands that already exist in devtools are documented in other places.
For instance, the cookie command can be replaced by simply using the Storage panel, so we should make sure that panel is documented. Etc.

Comment 10

[Soledad Penades [:sole] [:spenades]]

I'm going to close this one as we've started by removing the UI first, in bug 1461970