Integrating the developer tools debugger

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Integrating the developer tools debugger

Philipp Kewisch-2
Hey Folks,

as you may know, I am working on integrating the Developer Tools
Debugger into Thunderbird, so we can once again use a real debugger for
development. The debugger server is packaged by Mozilla's Toolkit, so as
long as its packaged, it will be possible to make use of it. The only
thing missing is UI and a few actors to make sure a Firefox client can
connect. More details on the initial implementation is here:
http://kewisch.wordpress.com/2013/06/13/the-thunderbird-remote-debugger-is-alive/

One important thing to decide on is how to actually package the
debugger. While the initial patches went into comm-central before the
last merge, there are more (possibly better) options to consider to make
sure that the debugger is available for all products. I'd love to hear
some feedback from at least one person from each product.

*Option A: package extension as an extension within the app*
  - Here we would have a single directory in the build system that
packages the debugger server glue as an extension
  - The extension would be installed and distributed with Thunderbird,
similar to how Seamonkey packages Chatzilla et al.
  - The extension can be extracted from Thunderbird for uploading to AMO.
  -Downside: Thunderbird usually doesn't package extensions, TestPilot
is going away too
- Upside: High visibility for developers, easier for others to
contribute to the debugger if they are contributing to comm-central too.
*
**Option B: package files directly in app, extra extension directory *
- The extension files get installed into dist/bin, not in the extensions
dir
- This way the extension is installed natively, without an addon-manager
entry
- An extra directory exists in the build system to generate the same
code as an extension, for uploading to AMO
- Upside: No extra entry in the addons manager
- Downside: No way to update the debugger glue without a full product update

*Option C1: package as an extension only*
  - The code would be removed from comm-central altogether, instead
added to a repository on my github account
  - AMO uploads can be made periodically by zipping the source code as
an xpi
  - Upside: No extra work for packaging, no maintenence in comm-*
repositories
  - Upside: Not installed for anyone that doesn't use the debugger
  - Downside: Localization needs to be managed externally
  - Downside: Visibility is not very high. Would need to do some PR to
make sure its known to developers
  - Downside: Yet another external repository for apps wanting to
include the extension by default
*
**Option C2: package as an extension, download in client.py*
  - Like option C1, but instead host on github/mozilla-comm
  - Make client.py automatically check out the extension into
mozilla/extensions
  - Add build system magic to allow building with the mozilla build system
  - Upside: More visibility than C1
  - Downside: Adds build system maintenance, also another external
repository


Just an extra note, the overhead for the js debugger glue is very small,
especially with the default of the debugger being off. I'm not going to
say my preference now to get a most unbiased opinion, but I may chime in
later on.

Looking forward to your feedback!
Philipp

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Neil-4
Philipp Kewisch wrote:

> Just an extra note, the overhead for the js debugger glue is very small

So small in fact that the code to turn it on is probably less than the
overhead of an extension...

--
Warning: May contain traces of nuts.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Joshua Cranmer 🐧
In reply to this post by Philipp Kewisch-2
On 7/8/2013 8:11 AM, Philipp Kewisch wrote:

> Hey Folks,
>
> as you may know, I am working on integrating the Developer Tools
> Debugger into Thunderbird, so we can once again use a real debugger
> for development. The debugger server is packaged by Mozilla's Toolkit,
> so as long as its packaged, it will be possible to make use of it. The
> only thing missing is UI and a few actors to make sure a Firefox
> client can connect. More details on the initial implementation is
> here:
> http://kewisch.wordpress.com/2013/06/13/the-thunderbird-remote-debugger-is-alive/
>
> One important thing to decide on is how to actually package the
> debugger. While the initial patches went into comm-central before the
> last merge, there are more (possibly better) options to consider to
> make sure that the debugger is available for all products. I'd love to
> hear some feedback from at least one person from each product.
>
> *Option A: package extension as an extension within the app*
>  - Here we would have a single directory in the build system that
> packages the debugger server glue as an extension
>  - The extension would be installed and distributed with Thunderbird,
> similar to how Seamonkey packages Chatzilla et al.
>  - The extension can be extracted from Thunderbird for uploading to AMO.
>  -Downside: Thunderbird usually doesn't package extensions, TestPilot
> is going away too
> - Upside: High visibility for developers, easier for others to
> contribute to the debugger if they are contributing to comm-central too.
> *
> **Option B: package files directly in app, extra extension directory *
> - The extension files get installed into dist/bin, not in the
> extensions dir
> - This way the extension is installed natively, without an
> addon-manager entry
> - An extra directory exists in the build system to generate the same
> code as an extension, for uploading to AMO
> - Upside: No extra entry in the addons manager
> - Downside: No way to update the debugger glue without a full product
> update

I think this is the best option, personally.

>
> *Option C1: package as an extension only*
>  - The code would be removed from comm-central altogether, instead
> added to a repository on my github account
>  - AMO uploads can be made periodically by zipping the source code as
> an xpi
>  - Upside: No extra work for packaging, no maintenence in comm-*
> repositories
>  - Upside: Not installed for anyone that doesn't use the debugger
>  - Downside: Localization needs to be managed externally
>  - Downside: Visibility is not very high. Would need to do some PR to
> make sure its known to developers
>  - Downside: Yet another external repository for apps wanting to
> include the extension by default
> *
> **Option C2: package as an extension, download in client.py*
>  - Like option C1, but instead host on github/mozilla-comm
>  - Make client.py automatically check out the extension into
> mozilla/extensions
>  - Add build system magic to allow building with the mozilla build system
>  - Upside: More visibility than C1
>  - Downside: Adds build system maintenance, also another external
> repository
No more extra repositories. With Mozilla's build system under flux right
now, it means one more repository to continuously query for updates
needed to the build system and overall much more painful to maintain.

>
>
> Just an extra note, the overhead for the js debugger glue is very
> small, especially with the default of the debugger being off. I'm not
> going to say my preference now to get a most unbiased opinion, but I
> may chime in later on.
>
> Looking forward to your feedback!
> Philipp
>


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Mark Banner-4
In reply to this post by Neil-4
On 08/07/2013 15:54, Neil wrote:
> Philipp Kewisch wrote:
>
>> Just an extra note, the overhead for the js debugger glue is very small
>
> So small in fact that the code to turn it on is probably less than the
> overhead of an extension...

Yes, I think we should just integrate it into TB and ship with it
built-in, as this removes all of the extension issues that we can hit.

Ideally, we'd share any common strings with FF via toolkit, so there may
be a bit of work required there.

Mark.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

gNeandr-7
In reply to this post by Philipp Kewisch-2
Great move!

As an extension developer for TB/FX/SM I'm applauding for this move,
also because that helps not only for Lightning but generally.

Some notes for the different options:
 > *Option A: package extension as an extension within the app*
-- downside: running a TB with the debugger in situation not doing dev
needs a separate instance

 > **Option B: package files directly in app, extra extension directory *
-- very negative I think

 > *Option C1: package as an extension only*
++ also the PR etc is 'negative' for the developer's pov the best solution

 > **Option C2: package as an extension, download in client.py*
?? can't comment

Thanks to Philipp
Günter
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Philipp Kewisch-2
In reply to this post by Mark Banner-4
On 7/8/13 7:52 PM, Mark Banner wrote:

> On 08/07/2013 15:54, Neil wrote:
>> Philipp Kewisch wrote:
>>
>>> Just an extra note, the overhead for the js debugger glue is very small
>>
>> So small in fact that the code to turn it on is probably less than the
>> overhead of an extension...
>
> Yes, I think we should just integrate it into TB and ship with it
> built-in, as this removes all of the extension issues that we can hit.
>
> Ideally, we'd share any common strings with FF via toolkit, so there may
> be a bit of work required there.

Right now the only strings we would have if bundled directly is an item
like "Allow Remote Debugging" in the tools menu. This is probably
already translated by a few locales since it was part of the initial
commit, which is now on aurora.

Philipp


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Philipp Kewisch-2
In reply to this post by Joshua Cranmer 🐧
On 7/8/13 6:14 PM, Joshua Cranmer 🐧 wrote:
> On 7/8/2013 8:11 AM, Philipp Kewisch wrote:

>> **Option B: package files directly in app, extra extension directory *
>
> I think this is the best option, personally.

If we go with this option, where should we actually put the debugger
glue? If it stays where it is now, Seamonkey will have to call into a
mail/ directory to package the debugger. Maybe mailnews/ makes more sense?

Also, how do we make sure that the extra extension directory doesn't
break since not everyone uses it? Maybe it would be possible to upload
the extension with the builds like Lightning does it?


>> **Option C2: package as an extension, download in client.py*
> No more extra repositories. With Mozilla's build system under flux right
> now, it means one more repository to continuously query for updates
> needed to the build system and overall much more painful to maintain.

I suspected as much. Fine with me.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Mark Banner-4
In reply to this post by Philipp Kewisch-2
On 08/07/2013 14:11, Philipp Kewisch wrote:
> One important thing to decide on is how to actually package the
> debugger. While the initial patches went into comm-central before the
> last merge, there are more (possibly better) options to consider to make
> sure that the debugger is available for all products. I'd love to hear
> some feedback from at least one person from each product.

Can you clarify what exactly you mean by "debugger" and where existing
version(s) of it are?

What I thought you meant: The remote debugger UI that you currently can
only initiate from Firefox Via Tools -> Web Developer (with the pref
toggled).

What I think you now mean: Some glue that isn't the actual backend
debugger but something that interfaces to it (as referenced in
http://mxr.mozilla.org/comm-central/source/mail/components/debugger/)

If the latter is the case, then I think you should investigate moving
any parts of it that are common with other apps to toolkit so they can
be shared, and just package the files within the app as normal.

Mark.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Philipp Kewisch-2
On 7/8/13 10:07 PM, Mark Banner wrote:

> What I think you now mean: Some glue that isn't the actual backend
> debugger but something that interfaces to it (as referenced in
> http://mxr.mozilla.org/comm-central/source/mail/components/debugger/)
>
> If the latter is the case, then I think you should investigate moving
> any parts of it that are common with other apps to toolkit so they can
> be shared, and just package the files within the app as normal.
>
> Mark.
>

Yes, the latter is the case, sorry for being unclear. The important code
is the content/dbg-mail-actors file in your mxr link. The code is
somewhat general, as any window of any app could be checked for
<browser> elements, but some bits are and will be specific to
Thunderbird. Currently its just the windowtype of the windows checked
for browser elements, but for example there is a bug open to add a way
to open a tab through the debugging protocol, which will have to use
Thunderbird's tabmail implementation instead of the Firefox method, and
so on.

While I am sure I can find reasoning that some of the parts make sense
for toolkit, I don't think everything will fit in.

Philipp
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Philipp Kewisch-2
In reply to this post by Philipp Kewisch-2
So here are the current votes and arguments. Please excuse and correct
if I misrepresented anyone.

A (package extension as an extension within the app):
- Günter: running a TB with the debugger in situation not doing
   dev needs a separate instance
- Markus: More integration work since TB does not package extensions
B (package files directly in app, extra extension directory):
+ Joshua: Best option
+ Mark, Neil: Likely less overhead than the extra overhead for
   an extension
- Günter: Very negative
- Markus: This kills the possibility for out-of-cycle releases
C1 (package as an extension only):
? Günter: also the PR etc is 'negative' for the developer's pov
   the best solution (sorry, don't know exactly what you mean.
   Positive or negative?)
- Markus: Lacks the visibility needed for this kind of extension
C2 (package as an extension, download in client.py):
- Joshua: No more extra repositories, very painful
+ Markus: You can have the extension always up to date in your builds
without having to think about it after configuring it once.

Mark, Neil and Joshua are in team In-App, while Günter and Markus are in
team Extension.

I personally prefer option B and therefore am also in team In-App. This
way we have the debugger available for any Thunderbird release, but with
the extra extension directory I can also make an extension out of it and
upload it to AMO, which can be used for xulrunner apps.

For out of cycle releases, we can just upload a version to AMO. This
won't have the same visibility, but I think its still ok. If its just a
new feature, we can advertise this to developers and not having the
feature isn't really bad. If its a major bug that needs fixing, I bet
its something we can put into a 24.0.x release.

What we will have to figure out is how to do the packaging for
Seamonkey, or rather: Should we keep the debugger in mail/components? We
could move it to mailnews, as thats shared between both apps.
Alternatively, we could keep it in mail/components and if Seamonkey
wants to package it as an extension (like option A), then they can just
add a DIRS directive to the Makefile that builds
mail/components/debugger/extension, which will install the extension
into dist/bin.

Given there are more votes for the in-app variant, unless there are
strong objections, I will work out the needed build system foo to allow
building the debugger as an extension with that extra directory.

Nevertheless, I am open to more discussion, especially on where the
files should live.

Thanks,
Philipp


On 7/8/13 3:11 PM, Philipp Kewisch wrote:

> Hey Folks,
>
> as you may know, I am working on integrating the Developer Tools
> Debugger into Thunderbird, so we can once again use a real debugger for
> development. The debugger server is packaged by Mozilla's Toolkit, so as
> long as its packaged, it will be possible to make use of it. The only
> thing missing is UI and a few actors to make sure a Firefox client can
> connect. More details on the initial implementation is here:
> http://kewisch.wordpress.com/2013/06/13/the-thunderbird-remote-debugger-is-alive/
>
>
> One important thing to decide on is how to actually package the
> debugger. While the initial patches went into comm-central before the
> last merge, there are more (possibly better) options to consider to make
> sure that the debugger is available for all products. I'd love to hear
> some feedback from at least one person from each product.
>
> *Option A:
>   - Here we would have a single directory in the build system that
> packages the debugger server glue as an extension
>   - The extension would be installed and distributed with Thunderbird,
> similar to how Seamonkey packages Chatzilla et al.
>   - The extension can be extracted from Thunderbird for uploading to AMO.
>   -Downside: Thunderbird usually doesn't package extensions, TestPilot
> is going away too
> - Upside: High visibility for developers, easier for others to
> contribute to the debugger if they are contributing to comm-central too.
> *
> **Option B: package files directly in app, extra extension directory *
> - The extension files get installed into dist/bin, not in the extensions
> dir
> - This way the extension is installed natively, without an addon-manager
> entry
> - An extra directory exists in the build system to generate the same
> code as an extension, for uploading to AMO
> - Upside: No extra entry in the addons manager
> - Downside: No way to update the debugger glue without a full product
> update
>
> *Option C1: package as an extension only*
>   - The code would be removed from comm-central altogether, instead
> added to a repository on my github account
>   - AMO uploads can be made periodically by zipping the source code as
> an xpi
>   - Upside: No extra work for packaging, no maintenence in comm-*
> repositories
>   - Upside: Not installed for anyone that doesn't use the debugger
>   - Downside: Localization needs to be managed externally
>   - Downside: Visibility is not very high. Would need to do some PR to
> make sure its known to developers
>   - Downside: Yet another external repository for apps wanting to
> include the extension by default
> *
> **Option C2: package as an extension, download in client.py*
>   - Like option C1, but instead host on github/mozilla-comm
>   - Make client.py automatically check out the extension into
> mozilla/extensions
>   - Add build system magic to allow building with the mozilla build system
>   - Upside: More visibility than C1
>   - Downside: Adds build system maintenance, also another external
> repository
>
>
> Just an extra note, the overhead for the js debugger glue is very small,
> especially with the default of the debugger being off. I'm not going to
> say my preference now to get a most unbiased opinion, but I may chime in
> later on.
>
> Looking forward to your feedback!
> Philipp
>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

gNeandr-7
Thanks for the summary!

Additional notes to my previous ..

On 14.07.2013 16:30, Philipp Kewisch wrote:

> B (package files directly in app, extra extension directory):
> + Joshua: Best option
> + Mark, Neil: Likely less overhead than the extra overhead for
>    an extension
> - Günter: Very negative
> - Markus: This kills the possibility for out-of-cycle releases
> C1 (package as an extension only):
> ? Günter: also the PR etc is 'negative' for the developer's pov
>    the best solution (sorry, don't know exactly what you mean.
>    Positive or negative?)

I learned from the other posting solution B isn't that bad, let me believe.

The point for me was overhead, that seems not the case .. good.
If the debugger is integrated into the product (TB) will it be possible
to update it with out generating a whole new TB version.
That was my main concern here. If it's possible to ship/install a
revised xpi when necessary, then I don't see any concern to go with B.

C1 would not be necessary, but I would prefer C1 over other solutions if
B isn't as described above.

Günter


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Mark Banner-4
In reply to this post by Philipp Kewisch-2
On 14/07/2013 16:30, Philipp Kewisch wrote:
> Mark, Neil and Joshua are in team In-App, while Günter and Markus are in
> team Extension.
>
> I personally prefer option B and therefore am also in team In-App. This
> way we have the debugger available for any Thunderbird release, but with
> the extra extension directory I can also make an extension out of it and
> upload it to AMO, which can be used for xulrunner apps.

Whilst option B is right, the extra add-on sounds wrong. If there is
core functionality here that applies to all applications, then it should
be supplied in toolkit, and not via each app implementing its own. The
only app specific parts should be the menu options.

From what you've said, some of it can be moved to toolkit, but some of
it is still app-specific. If that is how browser/windows are handled, I
don't see how that can be made into a generic add-on.

> For out of cycle releases, we can just upload a version to AMO. This
> won't have the same visibility, but I think its still ok. If its just a
> new feature, we can advertise this to developers and not having the
> feature isn't really bad. If its a major bug that needs fixing, I bet
> its something we can put into a 24.0.x release.

I don't agree that this is some code that's going to need out-of-cycle
releases. If Firefox is shipping this code built-in, there's no reason
to assume we're going to need any different support.

> Given there are more votes for the in-app variant, unless there are
> strong objections, I will work out the needed build system foo to allow
> building the debugger as an extension with that extra directory.

I would prefer not to land the extension parts in comm-central. This
would confuse the code for Thunderbird, and likely make maintenance more
difficult than necessary - especially when the extension isn't for
Thunderbird.

Mark.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

Philip Chee
In reply to this post by gNeandr-7
On 15/07/2013 00:14, gNeandr wrote:

> Thanks for the summary!
>
> Additional notes to my previous ..
>
> On 14.07.2013 16:30, Philipp Kewisch wrote:
>> B (package files directly in app, extra extension directory):
>> + Joshua: Best option
>> + Mark, Neil: Likely less overhead than the extra overhead for
>>    an extension
>> - Günter: Very negative
>> - Markus: This kills the possibility for out-of-cycle releases
>> C1 (package as an extension only):
>> ? Günter: also the PR etc is 'negative' for the developer's pov
>>    the best solution (sorry, don't know exactly what you mean.
>>    Positive or negative?)
>
> I learned from the other posting solution B isn't that bad, let me believe.
>
> The point for me was overhead, that seems not the case .. good.
> If the debugger is integrated into the product (TB) will it be possible
> to update it with out generating a whole new TB version.
> That was my main concern here. If it's possible to ship/install a
> revised xpi when necessary, then I don't see any concern to go with B.
>
> C1 would not be necessary, but I would prefer C1 over other solutions if
> B isn't as described above.

Let me see if I have this correctly. The devtools debugger is a client
server process. The application to be debugged runs the debugger server.
This bit lives in /toolkit/ all you need is to surface some UI to turn
it on and off. I see that Thunderbird Daily appears to have:
Tools -> Allow Remote Debugging.

Currently the webconsole/debugger is mostly in Firefox, so to debug
Thunderbird (or SeaMonkey) you need to use Firefox:
Tools -> Web Developer -> Connect...

Once connected you get a pretty web console UI running as a remote
process wrt Thunderbird.

I presume that it is the webconsole and debugger client that you want to
package in one way or another for Thunderbird and SeaMonkey.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Integrating the developer tools debugger

gNeandr-7
In reply to this post by Philipp Kewisch-2
Philipp made another big step:

https://kewisch.wordpress.com/2013/07/24/thunderbird-styleeditor-console-netmonitor-profiler/

.. and it works here great with
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0a2
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0

Hope the next steps aren't too far away!

Thanks
Günter
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird