2016 Challenge : Week #13 - Q1
If you did not, read the initial blog post announcing the challenge
You may remember that in March, I worked on a bug to display a swatch before angle values, and allow to cycle units with shift + click (Bug 1250835).
When my patch landed, Tim Nguyen reached me on IRC and told me that the new units did not persist in the rule view, and neither were changed in the Style Editor, which was confusing. Hence, I filed a bug and assigned it to myself right away (Bug 1259559).
The same problem already existed for colors swatches as well, so I had to work on both angle and color swatches. It turned out that the “persist” part of the patch was quite easy, there were already some functions that used to persist the value when the color tooltip is used, so I just had to call them and everything worked out of the box.
The downside of doing this was in the cycle part. As the value was persisted, it means that on each cycle the swatch was re-created, and we were losing tracks of the original value, which was used in the color unit cycling. I had to fix this, along with some test that were not working anymore ( mainly because it held a reference to the DOM element representing the swatch, whereas we now have to re-query the DOM to get the new swatch). It was reviewed on Tuesday and finally resolved on Friday. The process took a little more time than usual because the trees of the Mozilla’s repository was closed for a day, due to security issues.
This week, I also worked on two intermittent bugs. Intermittents are failures that occured in the test from time to time, because of race conditions, timeouts, unhandled failures, etc… There is an angoing effort through all Mozilla’s team to “kill” them (War on oranges).
The first one was in the animation panel (Bug 1260711), and I wasn’t able to reproduce it. On IRC Eddy Bruel told me about a special mode you can run Firefox in : Chaos Mode. If you don’t have time to read the article, here’s a little excerpt.
- Sometimes yield just before dispatching an XPCOM event. This gives another thread a chance to win an event-dispatch race.
- On Linux, give threads a random priority and pin some threads to CPU 0 so they contend for CPU.
- Insert sockets in random positions in the list of polled sockets, to effectively randomize the priority of sockets in poll results.
- Similarly, when putting HTTP transactions into the HTTP transaction queue, randomly order them among other transactions with the same specified priority.
- Start hashtable iteration at a random entry.
- Scale timer firing times by random amounts (but don't vary the order in which timers fire, since that would violate the API contract).
- Shuffle mochitests and reftests so they run in random order.
All this allow to simulate harsh conditions your code can be run in, and helps to reproduce intermittents failure.
I thus put a sometimes faulty test in Chaos Mode with SimpleTest.testInChaosMode() and was then able to reproduce the bug each time I ran the test.
It was triggered when the animation window were resized to a 0 width, which was causing an error when trying to create an image data with canvas.
var cvs = document.createElement("canvas");
var ctx = cvs.getContext("2d");
var imageData = ctx.createImageData(0, 1);
This was harder to reproduce than to fix, and the bug was resolved on Friday too.
The second intermitten I worked on was a test that timed out on Linux machines (Bug 1260714). These are the slowest machine the code is tested on in the TRY jobs, and this test sometimes took more times than the allowed amount (45 seconds).
The test was testing the clearing of the search filter in the computed properties panel. Julian Descottes helped me, pointing me to some lines that could be time consuming. For this one, the chaos mode didn’t help, and I couldn’t reproduce it on my laptop. So, I put some measurement and logs in the code ( with performance.now ), and pushed a patch to TRY, only for Linux machine, to see if Julian assumptions were good. When the TRY job was over, I was able to look at the log and see that indeed the suspected part was taking most of the time. As this part was tested in another test, I simply removed it and pushed this new patch to TRY again. This time, the test did not timed-out, and my measurement logs were showing good response times.
I cleaned my test and pushed it to review on Friday night. Julian granted the review within an hour, and the patch landed on fx-team ( the integration branch ) on Saturday. It did not had been merged to mozilla-central yet, but I expect it to be resolved on Monday of week #14 .
This week went great, again. I worked on multiple bugs at once and two of them landed.
This week marks the end of the first quarter of 2016, and I’m on the right tracks to succeed my challenge. I developed a kind of habit and I’m more involved in the devtools that I would have thought at the beginning of the year.