If you did not, read the initial blog post announcing the challenge
It’s a polish bug. I love polishing. I think that it is really what make a product shine ( got it 😀 ? ) and enjoyable. The way time graduation was displayed in the animation timeline was not ideal. It was even but did not really made sense on some cases ( 9.6s for an animation of 10s for example ).
During Week #2, I played with a test case using the following pen :
My idea was to always display the last animation tick, and then compute how much intervals we could put between the start and the end, while having only rounded numbers displayed.
I submitted a first patch for feedback on Friday evening and headed to my Skiing vacations.
Initially, I planned to work a little the evenings during the holidays, but I was so exhausted after snowboarding all day that I did not even open my laptop for the whole week ( Week #3 ). I knew that it would make 2 weeks unsuccessful for my challenge, but decided that truly disconnect and enjoy some quality family time was worth it !
While in holidays, I received the feedback I asked for, and was shown numerous ways my algorithm would not be great. The mentor ( Patrick Brosset ) explained me what he thinks we could do better and provided a jsbin to demonstrate his thoughts.
The main idea was to stick with multiples of 1, 2.5 and 5, and allow the last interval to be shorter than the others. The jsbin was very helpful and I edited my algorithm to match it, and asked for feedback again before editing the tests that needed it.
After a feedback+, I ran the whole test suite, and spotted 2 tests which failed. It was quite logical because they were calls to the main function I edited, the one that compute the optimal time intervals for the timeline. I edited them and submitted a patch for review.
On Friday, Bug 1227477 was resolved, making Week #4 a success !
While I was waiting for the review, I searched for a bug I could work on for the following week. I decided to go with Bug 1219611, to continue working on the animation inspector for a while.
I experienced this bug while working on Bug 1227477 : at the end of an animation, the time label was not equal to the animation duration, and the scrub line was not perfectly aligned with the animation block. If often got 9.995s for a 10s animation for example. The bug was easier that I thought though. The animation scrub line was moved via a requestAnimationFrame, which is great. But it also means that we would not stop exactly at 100% of the animation duration. All I had to do was to test if the percentage was greater to 100, and if it was, reassign it to 100. Doing this, the scrubber would be always aligned with the animation block.
I submitted a patch, was r+ by the mentor, and I was ready to push my patch to the TRY server. As I understand it, the TRY server allow to test a patch in multiples environments ( Linux, Mac, Windows, 32 and 64 bits, …) in order to avoid regressions you can’t see in your dev environment. I took a look at the appropriate Mozilla Wiki, which told me that I should have a commit with a particular syntax, that the TRY server could understand to execute the appropriate tests suite. The problem was that I did not know how to have this commit without modifying more files. So, again, I went on IRC, asked how to do it and was answered quickly that I could do :
hg commit --close-branch -m "try: -b do -p linux,linux64,macosx64,win32 -u xpcshell,mochitests"
Which worked great ! I was then able to push to TRY and notified it on the bugzilla page. I’m now waiting for the mentor to check if I did everything right as It was m first push to TRY :)
So I can say, Weeks #2 & #3 were failures for my challenge. It did not take long ! I set up a pen in order to track my progress. It’s still in progress but for now it give me the basic informations I need.
Next week, I hope that Bug 1227477 will be resolved, and I’ll be working on Bug 1218089.
See you next Sunday !