
Introducing the Firefox debugger.html - clarkbw
https://hacks.mozilla.org/2016/09/introducing-debugger-html/
======
ars
I don't know if anyone from the team is reading this, but I'll tell you want I
want from a Javascript debugger:

I want to be able to modify/add code, try it out, then rewind, and try
something else. Then save my changes once they work perfectly.

Simply setting breakpoints and watching variables is nice, but I can do
basically the same thing by echoing/console.log'ing things. If you are going
to go to the effort of making a debugger, then make it do something I can't do
another way.

~~~
paulirish
Firefox has done awesome work here, so I apologize for stepping in as a
"competitor", but Chrome DevTools can do what you're asking for with the
combingation JavaScript LiveEdit and Workspaces for persistence:

[https://www.youtube.com/watch?v=WQZio5DlSXM](https://www.youtube.com/watch?v=WQZio5DlSXM)
[https://developers.google.com/web/tools/chrome-
devtools/debu...](https://developers.google.com/web/tools/chrome-
devtools/debug/breakpoints/step-code?hl=en)
[https://developers.google.com/web/tools/setup/setup-
workflow...](https://developers.google.com/web/tools/setup/setup-
workflow?hl=en)

~~~
ars
> can do what you're asking for

That's quite nice, but it's only part of what I was asking for - it doesn't
let you rewind. You have to reload the page each time if your edit was wrong.

It's not necessary to save state by each instruction, it's enough that it
would be able to restart the current function.

Ideally it could walk back up the stack and restart other functions, but even
if it was limited to just the function with the breakpoint that would be huge.

~~~
sillysaurus3
_You have to reload the page each time if your edit was wrong._

You'd have to do that anyway. If code is wrong, it corrupts state. Unless
you're saying you want it to keep track of diffs of the heap, which might be
interesting. But how would it handle, say, a socketIO connection that a bad
edit terminates? There'd be no way to rewind that.

Maybe it doesn't matter for most work, since most work doesn't interact with
persistent objects (sockets, file handles...)

~~~
ars
> Unless you're saying you want it to keep track of diffs of the heap

Yup, that's exactly what I'm saying. Keep track of (store) the full browser
state before entering a function, and when you rewind restore that exactly.

Local I/O is no problem, remote I/O will simply be restarted. Or it will
error. It doesn't have to be perfect to be useful.

Mozilla actually is working on such a tool: [http://rr-
project.org/](http://rr-project.org/) (for gdb i.e native) and
[https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/We...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/WebReplay) (for browser).

It would be awesome if they fully integrated those tools into the built in
debugger.

------
lol768
Is this expected to be faster than the XUL based stuff? Currently "React" to
me makes me think poor performance, simply due to bad experiences I've had
with web applications and 'native applications' (read: web browser wrappers).

Surely there's going to be overhead using the remote debug protocol, it looks
like it's built on JSON so every response is going to need to be deserialised?
I can understand that it's nice to have the official tools using the same APIs
that external tools would use, though (and supporting multiple targets is a
nice benefit).

Further (and this is perhaps less on-topic), why do all UIs need to be written
in HTML/CSS these days to be considered "modern"? More broadly speaking, is a
GTK or Qt interface going to be less performant than something using a browser
engine? The motivation I've seen at a lot of companies seems to be that they
already have web designers who can design web pages, and so these people are
put to work designing desktop applications too. That's all well and good, but
it seems to often result in a poor user experience and be visually different
from the rest of the OS.

~~~
Etzos
I don't think the plan is for it to be faster necessarily, but rather to move
the existing tools off of a technology they are (slowly) moving away from.
While there will be some overhead due to the use of React I doubt it will be
anything noticeable. In fact, I just checked it out in the Nightly version of
Firefox and it doesn't feel any slower than the previous version of the
debugger.

As for the remote debugging protocol, I don't think that will really cost much
of anything. The debugger itself is using Javascript so the deserialization
cost of JSON is pretty much nonexistent on that end.

As for everything needing to be written in HTML/CSS, this seems like an odd
place to bring that up as this is quite literally a tool found inside of a web
browser. As a whole though, I think HTML/CSS "apps" are cropping up largely
because there are so many people familiar and comfortable with the technology,
not because it's seen as more performant. And now that things like Electron
and NW.js exist, it's trivial to leverage that knowledge to make a UI which
uses it verses having to learn a new language/framework.

------
iyn
Talk about the refactoring from React Rally:
[https://www.youtube.com/watch?v=Fk--
XUEorvc&t=8542s](https://www.youtube.com/watch?v=Fk--XUEorvc&t=8542s) (starts
at 2:22:22)

~~~
clarkbw
That's James Long, lead engineer for the project. He gives a great demo of the
debugger.html integration with Emacs. :)

------
clarkbw
The debugger landed in Nightly today, its not quite ready for prime time yet
but on by default and getting updated regularly.
[https://nightly.mozilla.org/](https://nightly.mozilla.org/)

------
daenney
Am I the only one that finds it amusing that a JS debugger is called
debugger.html?

debugger.DOM, sure, .JS even, but .html?

~~~
mintplant
There's another Mozilla project called "browser.html" which is a browser UI
built with web technologies. "debugger.html" is a similar idea.

[https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml)

~~~
sangnoir
I think gp meant that one would expect the project to be called debugger. _js_
instead.

~~~
mintplant
But the current debugger is already built with JS, using the XUL renderer.
debugger.html uses the HTML renderer.

------
zimbatm
Pretty impressive for a project that started end of March! (first commit
timestamp)

~~~
mbrock
To me that's consistent with the productivity boost I've experienced from
React-like web programming (YMMV).

~~~
iamcreasy
I've seen the word 'React' showing up lot after Facebook released their React
Javascript library. Is the that library is somehow related to what you are
referring to?

I don't do any web programming, so can you explain simple what it means by
'react' or 'react like'? What is Reactive programming?

------
mikegirouard
I'm sure it's been considered already, but I'm immediately concerned about the
security implications of running a node server when debugging. Perhaps that is
only the case when debugging in a stand-alone setup?

Think if you RDP to Firefox or Chrome and forget that the server is running.
Does that mean that if I browse to
[http://your.machine:8000](http://your.machine:8000) that I can control your
browser?

~~~
clarkbw
This is only for development of the debugger itself and shouldn't be used for
a production release. Within Firefox there is no node process it is run purely
as a web application.

~~~
mikegirouard
That makes sense. I figured that there was most likely two different run modes
(in browser vs stand-alone). Thanks for clarifying.

------
partizanos
Another feature I was trying to find was a way to see the history log of
changes of a variable and the lines where it happened, between two program
states.

~~~
jasonlaster11
I like that idea. I think we can do several things when it comes down to
tracking changes:

* make it easier to pause when a reference is set/get * make conditional breakpoints more of an every-day experience * better symbol search so that it is easier to see the different variable references and add the right breakpoints

~~~
partizanos
Of course it's trackable with the use of traditional breakpoints but in big
applications with a lot of dependencies step by step approach (through
different scopes where the variable changes names) could take long time. But
yes the good practises you mention make it easier.it's just something I Would
like to see automated.

------
XCSme
So, is it better than the Chrome built-in debugger? :D

------
sunilkumarc
'.html' in the name makes it sound like a not so important product from
Firefox. I think they could've chosen a better name.

~~~
millerm
I think it's a naming convention for their new product offerings, based on
their new technology stack. Servo's UI is named
"browser.html"([https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml))

------
dman
Any chances of using this as a frontend to lldb/gdb for c/c++ debugging?

------
garaetjjte
Oh no. Why there is a trend to write browser components in HTML and JS?

~~~
mintplant
Much of the Firefox UI is and has been written in JS for a long, long time.
What's happening now is that Mozilla is moving some components away from the
XUL renderer -- an old, crusty piece of tech that is only still maintained
because Firefox depends on it -- to the HTML renderer. Having more things on
one stack means development resources can be spent more effectively.

------
rattray
How do people currently debug node code? Is this a major or minor advance in
that world?

~~~
mikewhy
Node has a built-in debugger that works with Chrome Dev Tools. There's also
Node Inspector that does the same. Another option is some IDEs.

------
edibleEnergy
Very cool, looking forward to getting a deeper look at the source code. Nice
work!

------
mathiasrw
Any good reason they have not published via npm?

------
aikah
I'd say just look at Chrome dev tools and copy them at this point. Debugging
in Firefox is a mediocre experience IMHO. As for the name .html is
unnecessary.

~~~
clarkbw
To be honest, it feels like you didn't actually look at the link.

~~~
aikah
I actually did. And I saw nothing that made me think it would make my
debugging experience better.

~~~
SwellJoe
So, what does Chrome dev tools provide that current Firefox does not? I use
Firefox because it's what I've always used (and I prefer the browser) and what
I'm familiar with. What are the good reasons for me to learn the Chrome dev
tools?

~~~
mschuster91
1) Speed. Chrome is blinking fast, Firefox, especially when fiddling with
margins on CSS classes that are heavily used, is dog slow.

2) Compatibility with Webkit-based mobile browsers for debugging. I'm so not
having two browsers with hundreds of MB of RAM usage open.

Firefox' advantage is, though, the mouse inspector - it shows rulers for the
selected element at it's borders. Invaluable when trying to align text across
columns or rows!

~~~
SwellJoe
1\. I haven't found Firefox to be "dog slow". I may not be doing things that
stress it, but overall, speed is not something I have had complaints about.

2\. Ummm...don't you have to test against non-WebKit browsers, anyway? Or, do
you really expect all of your users to only use WebKit based browsers? That
seems problematic.

~~~
mschuster91
> 2\. Ummm...don't you have to test against non-WebKit browsers, anyway?

Testing in Chrome on OS X takes care about Chrome, Windows, Safari, Android,
iOS (even though the iOS Webkit has some quirks) and Firefox. Compatibility
between browsers in rendering is not an issue these days any more, the only
notorious exception being Internet Explorer, but even there the margin is
getting smaller and smaller.

I usually develop and full-test in Chrome first, and do a quick "does
everything look and behave correctly in other browsers" at the end, so far I
have not encountered any major differences between the platforms.

~~~
Sylos
Then what's different about this to only developing in Firefox and afterwards
testing in the other browser?

~~~
mschuster91
Because Firefox is dog slow (I hope that at least the frequent UI lockups due
to synchronous scripts in the site are soon history), and cannot speak with
anything webkit.

