Intent to implement: Moving DevTools to top level /devtools directory

[J. Ryan Stinnett]

The DevTools team is planning to move our code out of
/browser/devtools and /toolkit/devtools and into a new top level
/devtools directory.

The main goals of this are to reduce confusion for new DevTools
contributors and help us better organize our work in the future. It
will also aid future users of the code in understanding what pieces
they need to include.

There should be no impact to DevTools features shipped in different
products: Firefox desktop will continue to be the only product that
ships the DevTools front end, and all others will ship the DevTools
server only.

It is my understanding that the DevTools team received approval for a
new top level directory from Brendan several years ago.

Bug: https://bugzil.la/912121

(Replies to dev-platform.)

- Ryan

[Kevin Brosnan]

[tangentially related] Are there plans ot move DevTools to a product in
Bugzilla to match this code layout?

Kevin

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Joe Walker]

Yes, it's something that we'd like to do, but it's not trivial. Sure
creating a new product is easy, and moving bugs is fairly simple, but
educating people is a thing, and fixing everyone's workflows and scripts is
getting annoying, and it probably all adds up to something hard.
So while I'd like to do it, it's behind other more important things (e.g.
moving to /devtools) right now.

Joe.

[Paul Rouget]

Does that include getting rid of /browser/ dependencies?
Ideally, we'd like to be able to compile non-Firefox builds with our devtools.

On Tue, Jul 21, 2015 at 11:54 PM, J. Ryan Stinnett <jry...@gmail.com> wrote:
> The DevTools team is planning to move our code out of
> /browser/devtools and /toolkit/devtools and into a new top level
> /devtools directory.
>
> The main goals of this are to reduce confusion for new DevTools
> contributors and help us better organize our work in the future. It
> will also aid future users of the code in understanding what pieces
> they need to include.
>
> There should be no impact to DevTools features shipped in different
> products: Firefox desktop will continue to be the only product that
> ships the DevTools front end, and all others will ship the DevTools
> server only.
>
> It is my understanding that the DevTools team received approval for a
> new top level directory from Brendan several years ago.
>
> Bug: https://bugzil.la/912121
>
> (Replies to dev-platform.)
>
> - Ryan
> _______________________________________________

> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools



--
Paul

[Panos Astithas]

If you are thinking about shipping them as part of browser.html, we still
have XUL dependencies that we need to get rid of first and that work is
independent from moving the code to a top-level devtools/ directory.

[Paul Rouget]

On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas <pa...@mozilla.com> wrote:
> If you are thinking about shipping them as part of browser.html, we still
> have XUL dependencies that we need to get rid of first and that work is
> independent from moving the code to a top-level devtools/ directory.

We don't use XUL, but we can still open XUL windows.
Would it be possible to use the devtools without chrome://browser/
being accessible?

--
Paul

[Philip Chee]

On 22/07/2015 05:54, J. Ryan Stinnett wrote:
> The DevTools team is planning to move our code out of
> /browser/devtools and /toolkit/devtools and into a new top level
> /devtools directory.
>
> The main goals of this are to reduce confusion for new DevTools
> contributors and help us better organize our work in the future. It
> will also aid future users of the code in understanding what pieces
> they need to include.
>
> There should be no impact to DevTools features shipped in different
> products: Firefox desktop will continue to be the only product that
> ships the DevTools front end, and all others will ship the DevTools
> server only.

What is the utility of shipping the back end without the front end?

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Mike Hommey]

On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote:
> On 22/07/2015 05:54, J. Ryan Stinnett wrote:
> > The DevTools team is planning to move our code out of
> > /browser/devtools and /toolkit/devtools and into a new top level
> > /devtools directory.
> >
> > The main goals of this are to reduce confusion for new DevTools
> > contributors and help us better organize our work in the future. It
> > will also aid future users of the code in understanding what pieces
> > they need to include.
> >
> > There should be no impact to DevTools features shipped in different
> > products: Firefox desktop will continue to be the only product that
> > ships the DevTools front end, and all others will ship the DevTools
> > server only.
>
> What is the utility of shipping the back end without the front end?

Remote-debugging Thunderbird with the devtools in Firefox.

Mike

[Panos Astithas]

On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget <pa...@mozilla.com> wrote:

> On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas <pa...@mozilla.com> wrote:
> > If you are thinking about shipping them as part of browser.html, we still
> > have XUL dependencies that we need to get rid of first and that work is
> > independent from moving the code to a top-level devtools/ directory.
>
> We don't use XUL, but we can still open XUL windows.
> Would it be possible to use the devtools without chrome://browser/
> being accessible?

I doubt it, although, to be honest, I am not entirely sure. We already use
paths like chrome://browser/content/devtools/debugger.xul in the code, so
they would have to be changed first. Would using resource: URLs work better
for browser.html?

[Paul Rouget]

I guess by moving things to /devtools/, you also want to update the
URLs to chrome://devtools/content.
So then, we can compile and open the devtools with non-firefox builds
(thunderbird, b2g, seamonkey, ...).
But if the devtools include browser code, this won't work. For
example, we import
chrome://browser/content/utilityOverlay.js, which is Firefox only.

--
Paul

[J. Ryan Stinnett]

On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget <pa...@mozilla.com> wrote:
> I guess by moving things to /devtools/, you also want to update the
> URLs to chrome://devtools/content.
> So then, we can compile and open the devtools with non-firefox builds
> (thunderbird, b2g, seamonkey, ...).
> But if the devtools include browser code, this won't work. For
> example, we import
> chrome://browser/content/utilityOverlay.js, which is Firefox only.

The main goal of this work is around making the DevTools codebase more
approachable for contributors.

We're not explicitly setting out to make reusing the front end easier
from non-Firefox, but certainly moving out of /browser is one nudge in
the right direction down that path.

I'm guessing we'll still have some browser dependencies for the
moment, but I'll take a look at this as I work on the file moves.

- Ryan

[Jeff Griffiths]

That's correct. The use case is, again:

* git clone devtools
* ./nightly
* point devtools source directory to the git clone
* hack on firefox devtools in Nightly, reloading the source as need be

Anything else can wait until later as Ryan suggested.

Paul: are there things you want for graphene?

[Philip Chee]

Nice.

Does this make it easier for non-firefox applications to ship the front
end too? e.g. SeaMonkey.

Does this make it easier to package the front end as an add-on? e.g. as
a replacement for Venkman (DOA, RIP).

[Philip Chee]

I suggest chrome://devtools/content/debugger.xul if you are going to
refactor devtools. Use case: SeaMonkey

[Paul Rouget]

That would be nice, but not absolutely necessary.

We use WebIDE for now, so the process of connecting the devtools is
not as simple as just pressing F12. It's just that moving to a top
level directory, it's 90% of the work. The last 10% is to remove the
few dependencies to chrome://browser/ code.

So while we're at it … :)

--
Paul

[Mike Hommey]

On Fri, Jul 24, 2015 at 12:15:22PM +0800, Philip Chee wrote:
> On 23/07/2015 14:40, Mike Hommey wrote:
> > On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote:
> >> On 22/07/2015 05:54, J. Ryan Stinnett wrote:
> >>> The DevTools team is planning to move our code out of
> >>> /browser/devtools and /toolkit/devtools and into a new top level
> >>> /devtools directory.
> >>>
> >>> The main goals of this are to reduce confusion for new DevTools
> >>> contributors and help us better organize our work in the future.
> >>> It will also aid future users of the code in understanding what
> >>> pieces they need to include.
> >>>
> >>> There should be no impact to DevTools features shipped in
> >>> different products: Firefox desktop will continue to be the only
> >>> product that ships the DevTools front end, and all others will
> >>> ship the DevTools server only.
> >>
> >> What is the utility of shipping the back end without the front end?
> >
> > Remote-debugging Thunderbird with the devtools in Firefox.
>
> Nice.

Note that's not new. The backend has been in toolkit forever.

> Does this make it easier for non-firefox applications to ship the
> front end too? e.g. SeaMonkey.

As a matter of fact, the move to a different directory may help with
that, since it's going to be easier to add that directory to the build
system of non-Firefox apps without having to deal with the browser/
directory. That said, the code is not chrome://browser/ independent, so
while this will make it easier, it's barely a small step.

Mike