Google Groups

Re: Firefox front-end features, time-to-market, and coordination.

Joel Stover Aug 10, 2011 10:49 AM
Posted in group:
>   "non-leaking" -- What about this one? What kind of leaks--is it things
> that get held on to for way too long, or something else? Can tools help
> here? What about education?
Finding Mozilla leaks is confusing and hard, at least for me. Especially in
contrast to a Chrome tool that came up during the last memshrink meeting:

The two nice things there:
1) seeing a graph over time about the amount of memory used by a website (in
this case, our chrome code)
2) being able to snapshot and compare

With this tool, it was easy to see any DOM nodes that were still around but
no longer in the DOM.

>  "production-quality and readable" -- Is this basically non-bugginess, UX,
> polish, that sort of thing? There is a lot of detail work there no matter
> what. But I would have to think there are differences between XUL and HTML:
> one or the other has got to have more control over appearance or less
> semantic corner cases. Which one is really better?
It's less about the technology, more about writing tests. My personal,
uncomfortably honest anecdote ahead.

I've been bitten too many times trying to land some major refactoring like
e10s, replacing canvas tiles with cross-process async scrolling, and sidebar
panning for Fennec. Inevitably there would be months of fixing regressions
and a general gut-wrenching feeling that the code is becoming ungainly with
all the workarounds that get glued on top as an afterthought. Fixing some
regressions would cause new regressions. I quickly learned a bad lesson:
stop trying to rewrite code by making it better, faster, smaller. Just fix
the problem with as little change as possible. There are better things to
spend my time on, and they'll make me feel a lot happier.

This is because we have poor test coverage. Our "net" that tells us what has
changed is full of giant holes, so we step lightly and try not to touch
anything we don't understand. And so comes the nugget of wisdom: we need
more test coverage!

What I've learned is that we can tell ourselves to write more tests until
we're blue in the face. That doesn't mean we will.

I find writing frontend tests to be an exercise in frustration. I feel that
the test infrastructure is 1) unreliable (land something, random orange,
backout) 2) takes a long time to write and run tests (could be days and days
of sending to try because there's some leak on Windows) 3) no proper line
between functional and unit tests and 4) just plain no fun.

The salt in the wound is that I've done it the right way with websites
before working on browsers, and I know what I'm missing. Things like pymock,
inline tests, nose, proper fixtures, and twill made it fun and fast to
refactor code. If there was a regression, I wrote a functional test and they
could always detect failure, even if I completely gutted the code and
started over (mochitests most of the time need lots of API calls or access
of implementation-specific JS objects). While I was writing new code, I did
mostly unit tests. Test driven development was amazing. I'd write a few
lines, run a test suite in less than a second using paver, and know whether
I messed up (I *recompile* my Javascript before I think about test suite
incantations now). I had a functional product almost all the time. I *loved*
refactoring code then, and I didn't stress writing perfect code. I could
hone it as I went along.

I'm an imperfect being and I know I should write much more tests than I do.
I will continue fighting the urge to just ignore tests and keep telling
myself why they are so crucial. I'm trying to be part of the solution, and
I've committed a few mochitest patches along the way. What Mozilla could do
to help me significantly is to give me great tools, and I highly recommend
they ask some of our web developers about their favorite frameworks.

FWIW, I think Jetpack is on the path to salvation. I wish I could use it for
browser work.