One big blocker that we ran into was dragging and dropping new trackevents from the tray to the timeline. It’s funny because we actually almost decided to run without the ability to create new ones for the presentation but decided to implement a hack to create a new one on click at the last minute. This meant that you didn’t have to drag and drop to create the event, but could just click on its title and it would create an event at the videos currentTime with sane defaults. This wasn’t a future proof solution but it at least made the app some what feature complete.
At about 11pm we had saving, exporting, and logging working and rounded off all of the sharp edges that we created in the process ( its FULL of bugs ). We made a bookmark to the iPads homescreen so it felt more like a native app and removed some of the browsers UI which was nice. In the end I am really proud of what Rob and I did in <24 hours, we worked great as a team as we each brought our own set of skills to the table and worked in parallel most of the day and a half. I remember hearing a while ago that a good group/team member is someone you agree with about 70% of the time and Rob seems to fall into that category. It’s great to have someone there to tell you “Man that looks crappy” and be able to take what I’ve been working on and add some CSS polish to it. I think Rob and I make a great team and I’m looking forward to seeing what we can create.
Our presentation went pretty well and I think everyone liked seeing Popcorn Maker run on mobile devices, it’s something that we’ve wanted for a while. After the presentation Rob and I did a bit more work and made trackevent resizing and dragging REALLY smooth by adding gpu acceleration ( Rob blogged about this ). We also added gpu acceleration to track movement as well, so dragging a trackevent outside of the current viewing area doesn’t cause the screen to tear anymore.
Moving forward, Rob and I now have to go ahead and file some bugs about everything that we’ve noticed and get some feedback on ideas we have about how to restructure the UI. In the end I think this was a great experience and was a great break from the rush to get Popcorn Maker 0.5.1 and 0.5.2 out the door and ready for Mozilla’s story camp.
Bug #519 was about making sure that trackevent handles ( used to resize a trackevent ) made the trackevent gain focus. Currently, clicking on a trackevent would give it focus, but clicking on the handles ( which are a child element of the trackevent ) would not. After digging into the code a bit nothing jumped out a me that was glaringly wrong, so I figured it was an event bubbling issue. I remember that the third arguement of addEventListener ( the one everyone forgets about ) had something to do with event bubbling so I went and looked it up on MDN. The third arguement, also called userCapture, basically specifies if you want events to bubble as they normally do, from a child element up to it’s parent ( which means it would have a value of false, which I’m sure everyone is used to seeing ) or create what is called an event reflow ( I think ) and change the way an event gets triggered. By setting userCapture to true I noticed that events now fire from the parent element first and then to each of it’s children ( pending they have an event listener for the given event ). This seemed to do the trick and the trackevent handles were now recognizing a click event and everything was being handled as it should. The fix that I just explained worked because the event must have been getting captured and thrown away somewhere before it bubbled up to the parent element. Doing what I did allows us to make sure that the event gives priority to it’s parent first ensuring that it get’s fired there and then fires the event on each of it’s children. It was pretty cool playing around with how userCapture works and the difference it makes on events that get fired. I don’t see setting userCapture to true to be something I will use very often, as an event that bubbles from a child up is typically what you want, but knowing how to change the flow and use it accordingly is definitely a powerful tool to remember we have in our arsenal as coders.
var beautifiedObject = JSON.stringify( obj, null, 2 );
This week in general has been great for getting back into the swing of things again and refreshing myself with Popcorn Maker again, it’s crazy how fast the project is moving now a days. You don’t realize the crazy amount of bug mail you get until you take a week off and let it pile up. Also with a project moving as fast as Popcorn Maker it’s also hard to stay up to date after taking that much time off, the code is changing so much everyday it’s crazy. I’m looking forward to next week and getting ready to release 0.5 of Popcorn Maker!
I think the funniest moment over the past few days has been when Rob wanted me to explain something from the book he was reading. There was an example about closures that had the following piece of code ( might not be exact but close enough ):
var i = 20;
console.log( i.toString( 16 ) );
At first Rob asked me what the arguments were that toString took. Without even thinking I’m pretty sure I blurted out “none” and didn’t think anything of it. “But it’s in the book, look”, I didn’t believe him at first, so I had to see for myself. I ended up looking at it dumbfounded for a while trying to figure out what was going on. My response was “Well, let’s see what it does” which I don’t know if I looked dumb for not knowing that toString took an aruguement or not, but regardless this was an opportunity for both of us to learn something together. I busted open my console and began playing with it and we soon realized that if a number was passed into toString it would convert the value to a base-X value. This meant passing in 16 for our value of 20 returned 14, and passing in 2 gave us 10100. It just goes to show that there is always an opportunity to learn something new and I think teaching is a perfect example of this.
Being forced to explain your ideas in more depth than normal can be really difficult and truly is an art. I did my best over the past week to help Rob and I hope some of what I was saying was useful. Teaching someone is really hard and we should appreciate the teachers that we’ve had that we’re good at explaining concepts and helping us ( everything always seems easy until you try and do it ). This was a great experience for me and I learned a lot about how do communicate more effectively and realized I’ve got some brushing up to do myself. Even tho I use most of these concepts daily, it was hard for me to explain things at times and teaching really forces you to know your content inside and out, as you will always get questions that you weren’t expecting. Being able to teach is an art that we all tend to take for granted and until you try and do it, never fully appreciate how hard, draining, and complicated it can be.
For the last 4 months I have been working on various Firefox bugs. A few of them have gotten landed, I’m still working on others and some were too hard to finish, so it’s been an interesting ride. The tickets that I’ve worked on have been the following:
- Bug 702161 – videocontrols.xml has anonymous function event listeners that are added but never removed
- Bug 680321 – Media preload state should reset in resource selection algorithm
- Bug 708814 – Should fade out videocontrols even if there’s no mouse movement
- Bug 686370 – Implement video playback statistics proposed in WHATWG
- Bug 722788 – JSON number parsing is slower than it needs to be
- Boot to Gecko working on my phone
Since I began working on open source projects over a year ago in OSD600 one of the biggest barriers to entry for me has been IRC. It always sounds simple to just go into IRC and ask for help but a lot of the time it can be a pretty nerve racking experience. It can be scary to just throw yourself into the middle of a chatroom full of sometimes hundreds of developers better than you and ask what is probably a trivial question. When I first began doing this I ended up being afraid almost every time, thinking I would be labeled as an idiot for asking such an easy question and from that point on that no one would take me seriously. In reality my experience has been quite the opposite, in that everyone is friendly and willing to help out a newcomer. I don’t know why this is, but I attribute it to the pay it forward mentality, someone helped you in the past so you are likely to do the same for a newcomer that comes to the channel looking for help. I’ve actually taken this to heart and try to do it when I can, whether it be in Popcorn.js/Butter.js or Firefox bugs, I try to help people/newcomers whenever I can because I know I was once in the exact same position. I’m sure it’s just as hard to them to come into channel and ask a question as it was for me and I want to do whatever I can to make that experience more pleasant.
I have learned quite a bit this semester, from being more humble and stepping aside from my ego, to gaining confidence in both my coding and public speaking. It’s taught me some interesting lessons when it comes to coding. Until this semester I have always tried to rush through things, brute forcing my way through code in fast trial and error type approach. I would figure out what the problem was and then begin frantically removing, altering, and adding code as I went along. Most of the time when I figured out what was wrong I was left with a warpath of broken and ugly code in my wake, something I’m sure my reviewers in Popcorn.js/Butter.js can attest to as I’m notrious for leaving things like console.log( “ASDASDASDASDASDFAS” ); in my code. I learnt this lesson the hard way in one of the more recent bugs I was working on, 708814, which needed to be fixed up as it bit rotted for almost a month. I took a quick glance over my code and from what I could see it looked fine, I mean I also got an r+ on it, so it can’t be wrong, right? I went on what was a 20+ hour journey in the wrong direction, looking for a bug that didn’t exist. It was a stressful experience to say the least, one where you just want to grab your computer, shake it violently, and yell “WHY AREN’T YOU WORKING”. I asked for help in channel and no one else was able to see a bug either. At this point I was spinning in circles in my chair and looking at the same 8 lines of code over and over again not understanding what could be wrong. Sort of jokingly I switched my listener from “mozfullscreenchange” to “mouseover” and changed the if condition to check if the video was fullscreen or not. This was basically the same approach as I was doing, just in a different fashion. To my surprise it worked, as it looked like a fullscreenchange event was being fired before a mouseover event, and this was why it wasn’t working. In the end it boiled down to me having 0 patience and rushing into the code. I didn’t even take a second look at my code and began smashing my face into other code and assumed to problem was there. If I took 10 minutes to go over my code and think about it again I probably wouldn’t have done this. The only real reason I figured this problem out was because I am stubborn and didn’t give up, but if I learned to be patient before hand I probably could have saved a day worth of work. In order to work on code as large as Firefox you are going to need to be able to persevere and be stubborn, the code is going to beat you down over and over again and you need to show it who’s boss. I’ve been pretty good at not giving up this semester, but I didn’t really learn how important it can be to take a step back and be patient with my approach until I saw how far off I went in the wrong direction with 708814 ( and it was really far ).
In general the semester was great, I got to write in a language that I am far from comfortable with, engage with an unfamiliar community, and land fixes in Firefox. I continually tried to challenge myself with the bugs I undertook and I learned a lot because of it. I’m working on getting the video statistics ticket up for review by thursday and then working on review failures from then on. I think being able to say “I wrote feature X for Firefox” is a pretty awesome and is definitely another notch on my programming belt, so that’s what I’m striving for.
I had a great semester with everyone from class and I can’t thank everyone enough for the great feedback during class presentations and the help on irc. It was also great to witness everyone else step it up a notch and see what they got done, it definitely motivated me throughout the course to keep going and not give up. I wish everyone who graduated this semester ( I think everyone except me haha ) the best of luck with whatever you have planned for post graduation and hopefully we can all stay in touch via the seneca irc channel. To those who I’ll be working with over the summer at CDOT and Mozilla, I can’t wait to see what we make, it’s gonna be awesome!
Over the last few days I have been working on attempting to finish Firefox Bug 708814. The bug is that when the video goes fullscreen the controls are not hidden when there is no mouse movement. I had a patch to fix this just over a month ago but I let it sit for too long before coming back to it and it no longer works. Currently I’m trying to figure out why it is failing, which is proving to be quite difficult.
One of the new issues that is popping up is that Util’s is not defined from the following block of code. I briefly asked Jaws about it but he didn’t seem to know why this was happening either, so I am still investigating as to why this is happening. I also tried using |this| instead of Utils as they seemed to be the same thing, but I think the context of |this| was being miscontrued as well seeing as it was coming from inside a setTimeout. After compiling and testing this again it wasn’t complaining about Utils not existing coming from my listener, but rather from when it was called inside onMouseMove. I did the same thing I did as before and wrapped the function reference in an anonymous function and called |self._hideControlsFn( self )| ( obviously gross code, but for testing purposes it was fine ). Finally I was seeing some progress! At this point the controls were hiding after a mousemove over the video, but not if there wasn’t one. This was good because I was now back to a state where everything was working the way it should be before my patch got applied, so I knew I was headed in the right direction.
The only thing that I figured could be the cause here was if for some reason the scubber was being dragged, as that was the only check being done inside of _hideControlsFn, so I figured I would make sure that we were getting inside there, which it turns out wasn’t the issue. Back to the drawing board. I decided to look deeper into what was going on, as the issue obviously wasn’t present in _hideControlsFn, so I went looking in the startFade function itself. After reading through the startFade function a bit it was pretty obvious where I needed to monitor, which was this block of code. I throw some console.logs in there to check out what the values were and if for some reason anything weird was going on and it turns out that still looked pretty normal. The only difference that I could spot was that whenever the controls succesfully hid it would enter the last block inside of the else. I did some more logging before that block executed and got some interesting values. It turns out that the controls were not the only one calling startFade, but also an element called clickToPlay ( maybe the start button? ) so I decided to allow clickToPlay or controls to be the element for the condition to pass, but didn’t seem to make a difference. Looked like there was no option, I had to go deeper.
After playing around with some stuff for about an hour and realized that I missed something super obvious from the get go, that the listener for fullscreen had a check in it for hover, which always came up false initially, which really wasn’t what we wanted. I made it so the listener was for mouseover and checked to see if the video was in fullscreen or not, and what do you know it worked! After looking at my fix a bit more this made sense ( I think ). I’m happy that I finally figured this bug out, as it was a super subtle and tricky one to figure out, I got led off track quite a bit and went down a ton of deadends. As we speak I’m creating a new patch and making sure that it works fine, so fingers crossed!