Tagged: track element

I have some great news. Bug 833382 and 833386, the last pieces needed to get initial support for WEBVTT into Gecko will be landing for sure next week. That being said, I hope I don’t have to eat my words. It’s looking really good though. Bug 833382 has gotten to the point where Boris (:bz) has conditionally r+’ed it and 833386 has reached the same point with Ralph (:rillian). Now all that’s left to do for 833382 is to spin up some try builds and if it’s all green, hopefully we’ll be good to go. 833386 still needs to go through review with Chris Pearce (:cpearce), but I don’t think that will take that long.

I’ve been pushing really hard on landing these two this last week and I’m ecstatic to see that we’ve gotten to the point where we will be landing them in the next few days. The WebVTTLoadListener in particular I’m very happy about as most of that code is mine and I’ve worked really hard at it. It’ll feel good to land that. In the case of 833386 most of that code is Jordan Raffoul’s (:jbraffoul) and Marcus Nsaad’s (:msaad) and the work I did on it was just to consolidate it and get it through the last couple rounds of review. Marcus had been on vacation for a while and we really wanted to get this landed ASAP as it is blocking quite a few things so I asked Marcus if I could step in and he didn’t have a problem with it (Yay Marcus!).

Tests, Tests

One of the biggest problems I was having with the tests for the HTMLTrackElement and TextTrack* DOM classes (833386) was that we wanted to test everything with the pref set to true and also with it set to false. The thinking here was that we could do it in the same file. The problem was that it wasn’t working… and we all thought that it should be possible to do so I spent about 2~3 days trying to get it to work. At first I suspected that it was due to closures in Javascript and that the ‘state’ or variables were being sustained somehow by this. There was no way to get out of being entangled in closures too as we need to use a particular function, SpecialPowers.pushPrefEnv, that takes a function argument and async calls it after the pref is set. So in order for us to test with true and then false we have to have one pushPrefEnv(true) and one pushPrefEnv(false) with the second embedded in the first so that they are called one after the other and in that way we have a definitive point where we can call SimpleTest.finish().

I finally figured out, when asking the right people (bz and Ms2ger, who woulda’ thunk?), that it’s actually impossible to test with two different prefs in one page as there is one prototype for each element on the page and the pref is only applied to it once, when the element is created for the first time. So once you’ve created an element underneath one pref on a page, that’s it, it will behave like it is preffed that way no matter what you do. After that it was pretty quick to get through the rest of the code needed. One of the really good things about this process too is that it allowed me to find a lot of points where our current implementation is not to spec. I’ve filed a fewbugs on those this week. I’ve also closed a few bugs that have been fixed with changes in the last while. I also spun off another bug for tests that we will need to implement when the WEBVTT pref finally gets removed.

Try Server Access

The other really awesome news is that I’ve finally got try server access! Earlier this week Daniel Holbert (:dholbert) suggessted that I should apply for it and that he would vouch for me. I probably should have applied for it sooner then this as I could have used it for sure. The process was fairly easy and I’m glad to say I now have Level 1 commit access. Woot! If your interested in applying as well check out this page that describes what you will need to do.

In accordance with this new awesomeness I also had to learn about the process of pushing to the try server. Check out this good page for more information on how to do that. You’ll also probably want to look at Mercurial Manage Queue extension as it helps with managing a bunch of patches that you can move in and out of your branches easily. This really works well with my workflow of working on git and then just applying patches on my hg repository and pushing to the try server.

A month back I found out that Caitlin and I were being invited to Mozilla’s Web Rendering Week in Taiwan. Needless to say I was shocked. Ralph Giles, who has been working with us closely on WEBVTT and was/is our main contact with Mozilla for WEBVTT, kindly invited us out — thanks Ralph!!

Therefore, a lot of this week has been spent getting ready for the trip — getting ready to travel and trying to push on some final bugs to get initial support for WEBVTT into Nightly before we leave.

Getting that initial support entailed a few things, all of which haven’t happened yet… Don’t worry though! If we don’t get it finished before Taiwan we will definitely get it finished while we’re in Taiwan. We need(ed) too:

Get the WEBVTT library to a state where we felt comfortable tagging 0.5 and landing it in Gecko.

Land the DOM implementation of HTMLTrackElement and the TextTrack objects.

Land the parser and Gecko integration bug.

Getting WEBVTT to 0.5 was pretty easy. The only extra thing we wanted to add before 0.5 was support for the new <lang> tag. We needed a new string list pop function for that as well. I implemented that this week, which also exposed a bug that we hadn’t found yet because we didn’t have a proper test for it. The bug happened when we had an <rt> tag that was not enclosed within a <ruby> tag. In these situations the <rt> tag should not be processed. We weren’t handling it correctly and it was crashing the parser. That got landed as well yesterday. We tagged 0.5 and Caitlin is working on the bug to land it in Gecko now. WEBVTT 0.5 contains a lot of good things like sec-critical bug fixes and library usability fixes.

Ralph is very close to landing the DOM implementation. That should be happening within the next few days. The parser integration is getting close as well. I’ve been working on changing the code that converts the C node tree to a DOM tree from a recursive algorithm to an iterative one. It’s been a little tricky as we need to keep track of where we are in the C tree as we iterate over it, as well as where we are in the tree of DOM nodes that we are creating. We also need to keep track of the ‘last branching parent’ so that we’re able to tell when we need to go back up the tree. I have a solution that I put together that will hopefully be able to get an r+. I’ll have it up for review tonight on the bug.

The other major thing I did this week was give a presentation to CDOT about WEBVTT. You can check out the presentation over on my GitHub page. It was recorded so maybe you all can see it at some point when it gets posted! I’ll link at that time.