Self Guided Work

This week as lead to a mostly self guided work flow. With Lukas and Kronda doing one on one talks with each member of the project. We ascenders have been left to our own devices. Generally whether I thrive off of self guided work or not is entirely based on how I feel that day.

Luckily for me this kind of work has kept my interest for me to keep going. My bug, 1066148,

has proven to be a challenging beast. Since we had set-up a Firefox Dev Environment earlier to build Firefox, I could jump right in.

Ofcourse, however, I had no idea where to start. After indexing Gecko-Dev in Atom I searched for any file that had ‘newtab’ somewhere in the name. It turned up a few results that actually had nothing to do with the bug. So I hit my first road block.

Since Keywords weren’t helpful, I ended up in a one off conversation with Lukas that pointed me towards mozregression. This tool is incredibly useful when looking for a starting point. It works like this,

Find the release date for a build of firefox that doesn’t have the bug. This build will be marked as ‘good.’ since this latest release is bugged it will be marked as ‘bad.’ The mozregression tool will then start bi-secting builds in the middle. It will then install the build of Firefox that was released on that middle date and run it. Once it’s running you can test to see if your bug is there. If your bug is there, you can mark it ‘bad,’ if not you mark it ‘good.’ You and mozregression will then continue this process until it finds the exact build that created your bug.

After doing all of this I had the push log of all the changes made and after a little keyword searching found this page which told me exactly where the code was and what had changed. Dope, now all I have to do is translate of of this javascript stuff into a discernable language and it’ll easy right? Wrong.

So I decided the best way to translate this code is to break it down by essentially breaking the code. I would take out entire functions and build Firefox over and over again to see what stopped working. This gives me an idea of what the code does and I can map it on a piece of paper. What I was hoping to find would be a function that already places the cell back into the open gap, which while it does exist, is a combination of multiple functions. They dont track where the cell is being draged, they track where the cell is in relation to the other cells in order to move those cells in accordance.

Meaning the functions can’t possibly track the cell if it’s dragged outside the window. If it’s released outside the chrome of the browser, the cell will return to the last drop target rather than the updated drop target. Since the the other cells have moved in relation to the draged cell, they cover the draged cell’s last drop target. Which is the bug.

However what I’m thinking could be a possible solution is instead of tracking the draged cell. You force the cells to move to their original postion at the start of the drag. It’s a hard reset to the drag and drop operation which can probably be done very easily.

Im probably gonna fix this bug before I even get it assigned to me. :B