1003097 - (dbg-worker) [meta] Worker debugging

Status: NEW

(DevTools :: Debugger, task, P3)

Description

[Eddy Bruel [:ejpbruel]]

The implementation plan for this is roughly as follows:
- Implement a Worker Debugger API (bug 757133)
- Implement a Worker Loader (bug 1003095)
- Get the debugger server to run in a worker
- Refactor the main server so it can talk to a worker server
- Create a UI for worker debugging

Comment 1

[Eddy Bruel [:ejpbruel]]

I've added two new dependencies to this task:

- We can't use Promise.jsm inside a worker, partly because we can't load jsms inside a worker, but also
  because Promise.jsm itself depends on chrome APIs that are not available inside a worker. We need to
  either refactor Promise.jsm into an SDK module that works even when the Services object is not
  available, or get rid of this dependency all together and refactor the debugger server to use native
  promises, which is what bug 1016301 is about.
- We need a transport that can talk to the server over a MessagePort interface. This is what bug 1016304
  is about.

Comment 2

[Eddy Bruel [:ejpbruel]]

I've been lax in reporting my progress on this bug, but not for lack of any!

It turns out that creating a worker transport was rather trivial, and getting the debugger server to run in a worker was not as hard as I had feared, so I moved forward and finished the integration of the main server with the worker server, all in one go. As a result, I've closed bug 1016301 and opened up a new one (bug 1035206), that combines the following tasks:

- Implement a worker transport
- Get the debugger server to run in a worker
- Refactor the main server so it can talk to a worker server

Comment 4

[Eddy Bruel [:ejpbruel]]

We finally landed the platform API for the worker debugger, so expect to see some progress happening here in the next few weeks!

Bug 1035206 was horribly outdated, so I decided to close it. I will open several new bugs to land the server, client, and UI parts of worker debugging.

Comment 5

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

Just so you get some sense of priority, this is something that developers ask me for all the time--specially since you can do this with Chrome already! And also because for responsiveness reasons we are going to be moving so much code to background threads with all the new Worker types (Service Workers, Audio Workers etc etc)... we cannot debug by postMessaging ;-)

Marking it as DevAdvocacy.

Comment 6

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

So you get some sense of urgency / feedback from developers: this is something that I'm asked for *all the time*.

Specially with the new "put as much as possible in a worker" move with ServiceWorkers, Audio Workers etc... we cannot debug by postMessaging, it's just not efficient. Also it makes Firefox look like the poor relative, because Chrome does have this already.

I'm marking this as DevAdvocacy to reflect this feedback, but it would be nice to hear about estimates on implementation so at least I can give people some sort of vague promise on when this would be a thing they can start using.

Comment 7

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

I don't know how to use Bugzilla it seems x)

Comment 8

[Eddy Bruel [:ejpbruel]]

(In reply to Soledad Penades [:sole] [:spenades] from comment #6)
> So you get some sense of urgency / feedback from developers: this is
> something that I'm asked for *all the time*.
> 
> Specially with the new "put as much as possible in a worker" move with
> ServiceWorkers, Audio Workers etc... we cannot debug by postMessaging, it's
> just not efficient. Also it makes Firefox look like the poor relative,
> because Chrome does have this already.
> 
> I'm marking this as DevAdvocacy to reflect this feedback, but it would be
> nice to hear about estimates on implementation so at least I can give people
> some sort of vague promise on when this would be a thing they can start
> using.

I'm currently in the process of rebasing the prototype I showed during the London workweek last year. The reason this all took so long is because it proved very hard to get reviews for the platform API patches. The good news is that those have all landed, so we should be able to move forward quickly. I expect to be able to land the rest of the prototype within a couple of weeks.

This week I'll still focus on fixing small bugs for devedition 40. After that, worker debugging will be my top priority. If you want to stay on top of things, bug 1160199 is the one I'm currently working on. Once that bug is fixed I'll add subsequent bugs to the meta bug here.

Note that I'm deliberately calling this a prototype because I assume we'll have to fix many papercuts before it becomes useful as a production tool. I can't realistically give you an estimate how long that will take until people start using it (it will initially be hidden behind a pref).

Moreover, the prototype I showed in London only supported dedicated top-level workers, so no child workers, shared workers or service workers. Having said that, adding support for those should not be terribly difficult once we get the base case stable.

Comment 9

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

(In reply to Eddy Bruel [:ejpbruel] from comment #8)
> Moreover, the prototype I showed in London only supported dedicated
> top-level workers, so no child workers, shared workers or service workers.
> Having said that, adding support for those should not be terribly difficult
> once we get the base case stable.

Considering that ServiceWorkers are top-level workers, but don't necessarily have an associated window, how easy would it be to add support for them? Any way I can help?

Comment 10

[Eddy Bruel [:ejpbruel]]

I will still be working on this. I just don't think it makes sense to assign a meta bug to one person ;-)

Comment 11

[Jordan Santell [:jsantell] [@jsantell]]

Jukka, which bugs here are most important for game debugging?

Comment 12

[Jukka Jylänki]

Being able to debug and profile into workers is the biggest priority. This looks like bugs 1227639, 1192896 and 1119490. Right now the new SharedArrayBuffer specification is not yet being used much since the spec is expected to land in H1 2016 (implementation already does exist in Nightly and Emscripten supports it), but after it does land, it's expected that the need for bug 1152856 will explode dramatically, and will probably be the single most important one. Also bug 1047663 looks rather grim that it could cause a lot of unexpected behavior.

Btw, do we have a bug number for extending the profiler to workers? That feature has been asked several times by partner companies.

Comment 13

[Jordan Santell [:jsantell] [@jsantell]]

Worker profiling bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1132525

Comment 14

[Jason Laster [:jlast]]

Harald, could you refresh this meta? Several bugs seem out of date and could probably be closed...