Bug 1429421 (gcli-removal)

[META] Remove gcli/developer toolbar

RESOLVED FIXED in Firefox 64

Status

enhancement
P2
normal
RESOLVED FIXED
2 years ago
Last month

People

(Reporter: ochameau, Assigned: yulia)

Tracking

(Depends on 1 bug, Blocks 2 bugs, {dev-doc-needed, meta})

unspecified
Firefox 64
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(1 attachment)

46 bytes, text/x-phabricator-request
ochameau
: review+
julienw
: review+
jdescottes
: review+
Details | Review
Unfortunately GCLI is unmaintained for quite a while now.
Many commands are broken, especially on e10s and various tests are disabled.
As a result, GCLI is rarely used by users.

Here is a doc listing the usage of each command:
https://docs.google.com/spreadsheets/d/1Zrdm-V9WAQ11I5oxfqCt_M0VvF24NEWnT93VrzPRglU/edit#gid=578856175

We may want to ensure converting some of the commands that are still used.
But differently, outside of GCLI.

This bug aims at tracking which are the mandatory work to be done before removing it completely.
(In reply to Alexandre Poirot [:ochameau] from comment #0)
> Many commands are broken, especially on e10s and various tests are disabled.

About tests, while working on bug 1387330, I discovered that cookie and appcache commands were broken on e10s,
which is enabled by default and very hard to disable. Related tests are disabled on e10s.
Here's what I think we should do before removing GCLI:

- provide an alternative for the error count that is displayed in the developer toolbar (which, btw, doesn't work: bug 1228034)
- provide an alternative to the few commands that seem to be the most used and that do not yet have an alternative:
  - restart
  - folder openprofile
  - media emulate (which might be something we do in RDM, or in the inspector, or an add-on)
  - listen/unlisten (which might be something we do in about:debugging)
- make sure the toolbox toolbar buttons we have now work without gcli dependencies
- remove the whole source/test code for gcli and the developer toolbar altogether.

Having said this, there's a few commands I'm unsure about:
- inject: it's almost unused, but had received quite a lot of positive feedback when we added it
- pref set/reset/show: seems useful too, but maybe about:config is more than enough
- security referrer: no idea
I think we would like to get product point of view for this. Do you agree with comment 2 plan?
Flags: needinfo?(hkirschner)
I don't see any blockers to remove this. Even the top features are rarely used and usage quickly drops off sharply after them.

>   - listen/unlisten (which might be something we do in about:debugging)

That is the bigger one for me. about:debugging is where it naturally fits in the current design.

>  - restart
>  - folder openprofile

Both of these are available on about:profiles.

> - provide an alternative for the error count that is displayed in the developer toolbar (which, btw, doesn't work: bug 1228034)

Could the Devtools toolbar icon take on that counter (behind a pref)?

> - inject: it's almost unused, but had received quite a lot of positive feedback when we added it

Could this be a magic command in Console?

> Having said this, there's a few commands I'm unsure about:
> - inject: it's almost unused, but had received quite a lot of positive feedback when we added it
> - pref set/reset/show: seems useful too, but maybe about:config is more than enough
> - security referrer: no idea

No concerns here to leave them without replacement.
Flags: needinfo?(hkirschner)
Has Regression Range: --- → irrelevant
Has STR: --- → irrelevant
Priority: -- → P2
See Also: → 1416233
I believe the main issue why the GCLI is used that rarely besides many commands being broken is that it is hard to find.

So, what about merging the GCLI commands into the Web Console's command line, as Firebug did it (see also bug 1164157)? I darkly remember that we already talked about this earlier and I think we even already had a bug filed for that, though I can't find it.

This, of course, doesn't hinder tightening up the list of commands.

(I added some notes to the Google doc.)

Sebastian
Patrick, could you double-check my thoughts from https://bugzilla.mozilla.org/show_bug.cgi?id=1429421#c4 , so we can get a stop closer to a conclusion.
Flags: needinfo?(pbrosset)
(In reply to :Harald Kirschner :digitarald from comment #6)
> Patrick, could you double-check my thoughts from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429421#c4

And please also my comment 3 and the comments I added to the spreadsheet. Thanks!

Sebastian
(In reply to :Harald Kirschner :digitarald from comment #4)
> I don't see any blockers to remove this. Even the top features are rarely
> used and usage quickly drops off sharply after them.
> 
> >   - listen/unlisten (which might be something we do in about:debugging)
> 
> That is the bigger one for me. about:debugging is where it naturally fits in
> the current design.
Agreed

> >  - restart
> 
> Both of these are available on about:profiles.
I was surprised that restart was the most used command. :sebo brought some interesting insights as to why people would often need to restart Firefox: tighten up memory, to fix a UI glitch, to tighten up the list of add-ons after removing one of them, etc.
Now, why would the command be used to do this? There's the about:profile page, or simply closing and reopening the app via the menu/shortcut/taskbar/etc.
It's understandable that people who often used the keyboard might find gcli really cool for doing this, because it's much faster.
These people might not be DevTools users, so moving this to the console doesn't make a lot of sense.
Could it be a web extension instead?
Does DevTools really needs to be supporting this workflow?
I don't know the answers to these questions. But I'm tempted to say that if, for technical reasons, we want to get rid of gcli, I wouldn't block it on providing an alternative to the restart command.

> > - provide an alternative for the error count that is displayed in the developer toolbar (which, btw, doesn't work: bug 1228034)
> 
> Could the Devtools toolbar icon take on that counter (behind a pref)?
Yeah, that seems like the best option

> > - inject: it's almost unused, but had received quite a lot of positive feedback when we added it
> 
> Could this be a magic command in Console?
Sure, why not. This is also what :sebo was suggesting in comment 5, that some of the useful commands be available from the console (just like we have cd() right not).

> > Having said this, there's a few commands I'm unsure about:
> > - inject: it's almost unused, but had received quite a lot of positive feedback when we added it
> > - pref set/reset/show: seems useful too, but maybe about:config is more than enough
> > - security referrer: no idea
> 
> No concerns here to leave them without replacement.
I'm good with this.

About screenshots: I think we should add an option to the settings panel, to toggle the fullpage mode.
Flags: needinfo?(pbrosset)
On the engineering side, why would we want to remove the developer toolbar? I can think of a few reasons:

- This part of the code isn't currently actively maintained. Mike Ratcliffe is the current owner, but hasn't been actively working on this part of the code for several years, and no one else has. Originally, this came from Joe Walker who wrote GCLI, but Joe doesn't work on the DevTools team anymore. As a result of people moving and GCLI not being actively maintained for several years, we have lost a bit of knowledge here that makes it harder and harder to maintain if there ever is a need to do so.

- Cost while working on other things: any DevTools-wide refactoring will have to take this part of the code into account. We have already paid this price when working on e10s, various promise refactoring, event emitter refactoring, etc.

- Cost of running and maintaining tests: there are many integration tests for the developer toolbar that run with every CI build. Getting rid of them would make try build faster. Also, these tests sometimes fail intermittently and require maintenance.

- Cost of having the code: it's just more code to take into account when navigating the source tree, searching for things. Knowing that it's something no engineer on the team works on, it's a pity that we have to even see it there. It's also more code to build and package in Firefox, for a very low usage. And it's also code that ages and eventually needs to be rewritten whenever we adopt a new syntax, framework, code style.

- Unneeded complexity of toolbar buttons: the buttons we have in the DevTools toolbar now are actually based on GCLI commands behind the scenes. Knowing that for most of the buttons, they actually get used only as buttons, and never as GCLI commands, this is extra complexity that doesn't serve any purpose.

- Performance cost: we may be better now, but a year ago, we spent a long time in bug 1320149 making the developer toolbar not impact Firefox and DevTools' startup performance.

So, as said previously in this bug, removing the toolbar is ultimately a product strategy decision. But I also wanted to make a case from an engineering stand point.
Summary: [META] Remove gcli → [META] Remove gcli/developer toolbar
(In reply to Patrick Brosset <:pbro> from comment #8)
> (In reply to :Harald Kirschner :digitarald from comment #4)
> > I don't see any blockers to remove this. Even the top features are rarely
> > used and usage quickly drops off sharply after them.
> > 
> > >   - listen/unlisten (which might be something we do in about:debugging)
> > 
> > That is the bigger one for me. about:debugging is where it naturally fits in
> > the current design.
> Agreed
> 
> > >  - restart
> > 
> > Both of these are available on about:profiles.
> I was surprised that restart was the most used command. :sebo brought some
> interesting insights as to why people would often need to restart Firefox:
> tighten up memory, to fix a UI glitch, to tighten up the list of add-ons
> after removing one of them, etc.
> Now, why would the command be used to do this? There's the about:profile
> page, or simply closing and reopening the app via the
> menu/shortcut/taskbar/etc.
> It's understandable that people who often used the keyboard might find gcli
> really cool for doing this, because it's much faster.
> These people might not be DevTools users, so moving this to the console
> doesn't make a lot of sense.
> Could it be a web extension instead?

This was previously rejected. See bug 1344786. Though maybe this could be discussed again. At least personally I'd be fine with a WebExtension for that.

(In reply to Patrick Brosset <:pbro> from comment #9)
> On the engineering side, why would we want to remove the developer toolbar?
> I can think of a few reasons

I find it sad, because I think it is/was a great tool and has good potential to be the go-to place for many things, though I can understand the reasons why it's discontinued. So, thank you for providing detailed reasons why to remove the Developer Toolbar!

Sebastian
(In reply to Patrick Brosset <:pbro> from comment #9)
> - Cost while working on other things: any DevTools-wide refactoring will
> have to take this part of the code into account. We have already paid this
> price when working on e10s, various promise refactoring, event emitter
> refactoring, etc.
To illustrate this point, minutes ago, bug 1444394 was filed to remove some unsafe HTML insertions, and it is blocked on GCLI bug 1444395. This just adds to the maintenance cost for a tool that's virtually not used.
Hey, sorry, I just discovered this bug after filing the bugs for cleaning up the unsafe innerHTML usage mentioned in comment 11. I'm slowly realizing how all of GCLI is written using innerHTML, which means that we're indeed blocked on either removing GCLI or entirely rewriting GCLI UI for this high priority task. setUnsafeInnerHTML was added as a compromise with the clear goal of removing it within a few iterations, and I would of course love to avoid rewriting GCLI UI if it's not necessary.

From a security engineering standpoint I'd like to add that exposing GCLI in release builds without hiding it behind a setting in devtools seems a bit problematic as well, especially considering the way its UI works.

I'm not the right person to judge the functionality of GCLI, but it seemed oddly non-functional to me and I'm happy to provide help in resolving the tasks that are necessary to unship.
(In reply to Patrick Brosset <:pbro> from comment #2)
> - provide an alternative to the few commands that seem to be the most used
> and that do not yet have an alternative:
>   - restart
I was talking just now to a user of this command. Here's a summary:

They use it because it's the keyboard friendliest way of restarting the browser
When testing security-related stuff that requires to restart the browser, it's easier to do Shift+F2 & restart than CTRL+T, about:profiles, and then _click_ a button.

Another alternative they mentioned was to find a terminal that started the browser and do CTR+C, Up Arrow, Enter (in case it was started with mach for instance), but that's a context switch.

Several alternatives we discussed:
- add a hotkey in about:profiles that avoids having to click the button to restart,
- add a new hotkey to firefox that restarts (similar to cmd+Q on Mac which quits, this could be shift+cmd+Q or something),

I think this would just be much better than having a ton of code just to restart the browser.

Also, in light of comment 12, I think we just have to remove gcli.
(In reply to Patrick Brosset <:pbro> from comment #8)
> > >  - restart
> > Both of these are available on about:profiles.
I filed bug 1444916 to add a keyboard shortcut in this page.
Harald, can you help us moving this forward?
Patrick last suggestions start at comment 8.
Flags: needinfo?(hkirschner)
Depends on: 1447487
Depends on: 1447490
Depends on: 1447491
Depends on: 1447494
I started filling bugs to convert features *outside* of gcli that would break if we start removing gcli completely.
Most of the work will be into converting all the gcli-related toolbars buttons to use actor methods instead of gcli commands.

But I'm wondering if we could already start phasing out gcli?
* Why not starting with a message saying it is about to be removed?
* Hidding it?
* We may be able to strip a bunch of code and the toolbar itself without breaking gcli commands.
(In reply to Alexandre Poirot [:ochameau] from comment #16)
> I started filling bugs to convert features *outside* of gcli that would
> break if we start removing gcli completely.
Thanks Alex!

> * Hidding it?
Yes, we should do this. I discussed wiht freddyb about this and this would be a big help for them. This way it's essentially gone, but the system still works behind the scenes for as long as we need to convert the toolbox buttons.
(In reply to Alexandre Poirot [:ochameau] from comment #16)
> * We may be able to strip a bunch of code and the toolbar itself without
> breaking gcli commands.

I experimented this approach and it looks like we can do that:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6edccf1d7a58a4d0004dd1e5694d638adbcb5d52&selectedJob=169632967

We could remove all the UI code of gcli, especially code in:
  devtools/client/commandline.js (tests and html+css of gcli)
  devtools/client/shared/developer-toolbar.js (all but CommandsUtils)
  leftovers of gcli in browser/ (mostly css)
  all tests in devtools/ trying to display gcli
  gcli webdeveloper menu and shortcuts

While we keep:
  devtools/server/actors/gcli.js (its actor)
  devtools/shared/gcli/ (all gcli framework, which allows to keep gcli commands to work)
  devtools/client/shared/developer-toolbar.js (only for CommandsUtils, required for commands)

We probably can iterate on that and strip some more stuff within devtools/shared/gcli/, like unused commands.
My two concerns are:
* we are completely removing gcli feature without much notice, nor any alternative for features that we used a bit,
* we probably reduce test coverage of features using gcli commands (but I verified manually, they still work).

The advantages are:
* a lot of code is removed and we no longer have to maintain it: convert to DOM Promise, async/await, event emitter, ...
* a lot of tests removed: less intermittents, were there tests using cpow?
* we completely remove the code involving unsafe innerHTML

Do we want to hide it but still allow some users to re-enable it?
If we want to fully disable it without any option to enable it, I think we should rather strip it like this.
(In reply to Alexandre Poirot [:ochameau] from comment #18)
> The advantages are:
> * we completely remove the code involving unsafe innerHTML

Sorry, I was confused about this part, I only removed gcli/util/util.js import from DeveloperToolbar:
  https://searchfox.org/mozilla-central/source/devtools/client/shared/developer-toolbar.js#
It thought it was the main callsite, but it is not, it isn't even used in this module.

But I think that by getting rid of gcli UI we end up dropping all usages of this setContents helper [1].
I don't think any of the gcli commands we still use in bug 1447487, bug 1447490, bug 1447491, bug 1447494 end up using this.
So the code is still here, as a bunch of callsites, but none should lead to an ultimate callsite that is still used.
We would need to drop things within devtools/shared/gcli to get rid of it, but to do that, we have to remove gcli UI first.

[1] https://searchfox.org/mozilla-central/source/devtools/shared/gcli/source/lib/gcli/util/util.js#494-503
Depends on: 1448107
To clarify our requirement: We want to unimplement UnsafeSetInnerHTML. Using whichever road is fastest ;)
(In reply to Alexandre Poirot [:ochameau] from comment #18)
> My two concerns are:
> * we are completely removing gcli feature without much notice, nor any
> alternative for features that we used a bit,
There are alternatives in other places for the most used commands: restart (sure, maybe not as power-user-friendly) and screenshot (there are so many ways to capture screenshots now, sure maybe not full-page yet). Harald and I agree that there's no hard blockers to removing gcli now.
Harald is still needinfo'd here and I'd like him to comment on the product side of things. In particular regarding the messages needed for this, if any.
On the engineering side, I'll send an intent to unship email.

> Do we want to hide it but still allow some users to re-enable it?
> If we want to fully disable it without any option to enable it, I think we
> should rather strip it like this.
I do want to remove it entirely. It's unmaintained, unsecured, and mostly unused.
The arguments concerning security, maintenance, migration paths for functionality and usage (especially comment 8 and comment 9) give ample reason to unship GCLI.

To provide flexibility to react to unforeseen dependencies and communication, the plan is to disable the feature in 60 (assuming we are allowed uplift, otherwise 61) and remove the code in 61 (or 62 without aforementioned uplift).
Flags: needinfo?(hkirschner)
When the Developer Toolbar is removed it should at least be mentioned in the developer release notes and on https://developer.mozilla.org/en-US/docs/Tools/GCLI.

Sebastian
Keywords: dev-doc-needed
Depends on: 1461970
I opened bug 1461970 with patch from comment 18.
It looks like we won't disable gcli (bug 1448107) and instead, start by removing its UI (bug 1461970).
Depends on: 1462398
Depends on: 1462399
(In reply to Patrick Brosset <:pbro> from comment #8)
> > >  - restart
> > 
> > Both of these are available on about:profiles.
> I was surprised that restart was the most used command. :sebo brought some
> interesting insights as to why people would often need to restart Firefox:
> tighten up memory, to fix a UI glitch, to tighten up the list of add-ons
> after removing one of them, etc.
> Now, why would the command be used to do this? There's the about:profile
> page, or simply closing and reopening the app via the
> menu/shortcut/taskbar/etc.
> It's understandable that people who often used the keyboard might find gcli
> really cool for doing this, because it's much faster.

If you have multiple windows open you can't reopen app via "menu/shortcut/taskbar/etc." because you will be restoring only one window and other will be lost. So right now a way to trigger the restart is through about:profiles page, which is too much user input for such simple command as reset. Other way is to open browser console and hit ctrl+alt+r, browser console might scare some people :>. Both are not user friendly. Same goes for screenshots which were also frequently used, it was really accessible interface to snap a page. Of course there is Firefox Screenshots which is good enough, but again it require a lot more user input to get actual image file. (and it is currently broken, because full page snaps doesn't work)

That said I personal found that really handy to have those command quickly accessible. Of course I wasn't restating browser every 15 minutes and taking screenshots of every page I visit, hence the usage is not that high. Now that it is gone I will have to get used it I guess. 

And one more thing, I don't think that opening a toolbar (shift+f2) and typing ex. restart is a power-user thing like it is presented in this bug. I mean typing website address is not a power-user thing either.
No longer depends on: 1463129
I just found out about this when I couldn’t get the GCLI to open in FF Nightly and went to find out if I needed to file a bug.  I’m sad to see the GCLI go away, particularly for the loss of the very useful `screenshot` command.  I wrote a blog post singing its praises back in 2015 (https://meyerweb.com/eric/thoughts/2015/10/22/firefoxs-screenshot-command/), and I’ve continued using it to this day.  Well, not this exact day, because it’s gone now.  But you get what I mean.

The point-and-click UIs available for taking screenshots really aren’t sufficient for what I and many of my colleagues do.  The blog post details some of my usage patterns, which included things like… 

`screenshot --fullpage --dpr 0.5 cnn-no-css` to grab a low-resolution copy of a very long page.

`screenshot --selector '#d0_u1_m' --dpr 3 modal-dialog` to capture a high-resolution example of a piece of a web page.

And often, I do just `screenshot --fullpage` in a 1080p-size responsive-layout window to capture a rendering for a slide deck.

Seriously, about 95% of the almost 800 figures in the fourth edition of “CSS: The Definitive Guide” are literally `screenshot` outputs.  I’d create files (see http://meyerweb.github.io/csstdg4figs/ for the collection) for the figures in a chapter, load up the first, fire off `screenshot --dpr 5 --selector 'body' css_1401`, load up the next example, hit up-arrow, hit delete once and then type `2`, hit return, load up the third example, etc.  I’ve used similar patterns for slides in talks, figures in articles, posts in forums, and so on.

I’m not asking to restore the GCLI solely to restore `screenshot`, but I really hope the full range of `screenshot`’s capability can be migrated to another command line somewhere in Firefox, so I came here to make that case.
Thank you Eric, this is super useful.

Out of all the commands we want to bring back we're prioritising screenshot first, so hopefully there will be something back for you soon.
A fairly straightforward / existing way implement individual commands would be to add a new WebConsoleCommand similar to 'copy' or 'inspect': functions that are only defined in the console execution scope. The trade offs compared with GCLI would be:

1) You'd need to open devtools, so the command line isn't persistent across tabs
2) You'd lose argument autocomplete

The workflow would be:
- open devtools on the page you want the screenshot in
- enter `screenshot();`

I could see copying the command args across as keys in an object, so something like:

`screenshot --fullpage --dpr 0.5 cnn-no-css` would become: `screenshot({ fullpage: true, dpr: 0.5, name: 'cnn-no-css' });`
`screenshot --selector '#d0_u1_m' --dpr 3 modal-dialog` would become `screenshot({ selector: "#d0_u1_m", dpr: 0.5, name: 'modal-dialog' });`
`screenshot --fullpage` would become `screenshot({ fullpage: true })`
Product: Firefox → DevTools
Depends on: 1469832
(In reply to Patrick Brosset <:pbro> from comment #21)
> (In reply to Alexandre Poirot [:ochameau] from comment #18)
> > My two concerns are:
> > * we are completely removing gcli feature without much notice, nor any
> > alternative for features that we used a bit,
> There are alternatives in other places for the most used commands: restart
> (sure, maybe not as power-user-friendly) and screenshot (there are so many
> ways to capture screenshots now, sure maybe not full-page yet). Harald and I
> agree that there's no hard blockers to removing gcli now.

Looks like you forgot about the error counter. The UI is removed now and people already start complaining. See bug 1228034.
Would be good if this was added back before the removal moves to stable to avoid bad UX. I've filed bug 1469832 to add it to the toolbar button.

Sebastian
Without getting into a debate about the pertinence of the removal, I this find quite sad, especially for the screenshot as comment 27 highlighted.

However contrary to comment 24 there is no reference to this change either in the general releases notes (https://www.mozilla.org/en-US/firefox/62.0beta/releasenotes/), nor the developer ones (https://developer.mozilla.org/fr/Firefox/Releases/62). The only notice is on the page relative to GCLI (https://developer.mozilla.org/en-US/docs/Tools/GCLI), without any link to this bug, only referenced by external sites...

I hope someone can change the release notes, and that tools equivalent to GLCI become available elsewhere in the browser.
(In reply to fl0 from comment #31)
> Without getting into a debate about the pertinence of the removal, I this
> find quite sad, especially for the screenshot as comment 27 highlighted.

The screenshot feature is being re-added into the console in Bug 1464461. It didn't end up getting linked here so updating that now.

Other GCLI command replacements (mostly things that were surfaced in the original 'intent to unship' thread at https://groups.google.com/d/msg/firefox-dev/YIh34EW-UoA/B90OVC5NCQAJ) are tracked by bugs in the "Depends On" list to this one.
Depends on: 1464461
(In reply to Patrick Brosset <:pbro> (on parental leave August 1st to September 17th) from comment #2)
> Having said this, there's a few commands I'm unsure about:
> - inject: it's almost unused, but had received quite a lot of positive
> feedback when we added it
> - pref set/reset/show: seems useful too, but maybe about:config is more than
> enough
> - security referrer: no idea

As a developer, I found 'pref set' quite useful. Especially if you're trying to compare the results of two different page loads. I was a little surprised to suddenly see the toolbar removed. The GCLi wasn't exactly user-friendly (e.g. inadequate history and aliases), but it did the job.

The most common setting I used was 'permissions.default.image' which disabled loading of images. The developer tools have a 'disable javascript', but not a 'disable images'. They're about as equally breaking, but there are occasions when they have to be tested. Twiddling in about:config isn't exactly fun, perhaps I'll have to find an extension (although that also seems a bit heavy-handed and doesn't solve the overall problem with generic about:config settings).
Garmin, thanks for the thoughtful feedback.

This might be also a command we could expose via Console, filed as an enhancement bug 1480263.

We are generally thinking about how to allow quick-testing of more browser setups (beyond responsive aspects) and network failure points, like ad-blocking, JS blocking, image blocking, reduced motion, etc in DevTools. This use case will help to shape this feature up.
Depends on: 1483491
No longer depends on: 1447267
No longer depends on: 1469832
No longer depends on: 1480263
No longer depends on: 1483491
Alias: gcli-removal
Remove remaining GCLI code
The patch that I posted removes what the child bugs of this bug do not remove. Once those are merged in, this can be rebased and then everything should be gone.
No longer depends on: 1447487
Comment on attachment 9002002 [details]
Bug 1429421 - remove gcli code; r=ochameau

Alexandre Poirot [:ochameau] has approved the revision.
Attachment #9002002 - Flags: review+
Comment on attachment 9002002 [details]
Bug 1429421 - remove gcli code; r=ochameau

Julien Wajsberg [:julienw] has approved the revision.
Attachment #9002002 - Flags: review+
Comment on attachment 9002002 [details]
Bug 1429421 - remove gcli code; r=ochameau

Julian Descottes [:jdescottes][:julian] has approved the revision.
Attachment #9002002 - Flags: review+
Pushed by ystartsev@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5e21be5fdf9d
remove gcli code; r=jdescottes,julienw,ochameau
should be resolved, it looks like I missed something

try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c5d898ad006437e0d46ea71fcdda8e94aa6bfa4
Flags: needinfo?(ystartsev)
Pushed by ystartsev@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/61970ba39450
remove gcli code; r=jdescottes,julienw,ochameau
https://hg.mozilla.org/mozilla-central/rev/61970ba39450
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Duplicate of this bug: 1483352
Product: DevTools → DevTools Graveyard
Assignee: nobody → ystartsev
You need to log in before you can comment on or make changes to this bug.