I began my task with several key goals for the task:

1. The test runner should look & feel like QUnit (QUnit is the JS testing framework we use).
2. The test runner should provide results about each test ( Passed, Failed and Total Run ).
3. There should be a link to each individual test, so that the user can navigate to it in the event of a failure.
4. There should be a way to view more information about each test (I.E. expand each test result to view more detail.)

Look and Feel

Making the test runner look and feel like QUnit was simple to accomplish. I copied the core unit test file into a new one, and stripped out the cruft. figuring life would be easier, I just kept the default QUnit CSS file. I then added an iFrame to the page for loading the test pages. From that point on, I needed to make sure that I built the results properly in my JavaScript code, apply the correct classes, and append them to the page. If all went well it'd work perfectly.

Building the Test Runner

QUnit provides a mechanism to define methods, which, at certain points in the testing process, are called. An example of this is `testDone`. When a block of assertions completes, QUnit will call the `testDone` method. I took advantage of this by creating a script called `popcorn.inject.js`, which defines two methods: `testDone` and `done`. The latter of the two is called on the completion of all assertions and tests on a QUnit page. In each of these methods, you receive data about the tests that are passing and failing. Using `postMessage`, I can push the results to the iFrame's `parent window`. I made sure that this won't execute if there's no parent window, in the event the test is run individually.

The structure of the test runner is fairly straight forward and simple. I made an array of JavaScript objects that describe each test. Here's what it looks like:

var tests = [{
  // Name of the test
  name: "Attribution",
  
  // Path to test file
  path: "./attribution/popcorn.attribution.unit.html",
  
  /* Type of plugin 
   * unused as of right now, but I plan to distinguish the test
   * according to these, similar to modules in QUnit
  */
  type: "Plugin"

}];
									

On page load the runner attaches a `postMessage` handler to the iFrame. The runner will then iterate over the array of objects one at a time. It loads the first test into the iFrame, kick-starting the entire process. As the test in the iFrame executes, it posts messages back to the parent window. My `postMessage` handler will detect whether the message is a `testDone` or a `done` message type. If the message is `testDone`, it pushes the results from it onto an array. When it receives the `done` message, It will build the necessary elements based on the array of data collected from `testDone` events. It then appends them to an outer element, that contains totals about how many tests passed and failed, along with the time it took to ran the tests. These totals are added to global totals I created ( Not global as in attached to window, but global to the test runner ), which track passes, fails, totals and run time across all tests that the runner executes. Once it's finished building the result element, it appends it to the test page, and loads the next test in the array. When it has exhausted all of the defined tests, it will output the global results of all run tests, and the total time it took to complete everything.

Once all of this was completed and working, I decided to go one step further in my work. Not only did I create a plugin test runner, but I was able to create a test runner for every area of our code. That includes runners for Parsers, Players, and Modules. And for the first time ever, a test runner for all 1600+ tests in the project!

Below I've attached screenshots of the before and after transformation of the test runner (click to enlarge)

This is what the test runner used to look like

This is the new Test Runner

What Does This Mean?

The implications of the work I've done here are pretty significant. By implementing these test runners, the time spent manually testing for releases should drop dramatically. For example, I remember many releases where I had to navigate between the eight parser unit tests manually for at least 4 browsers, on multiple platforms. It was tedious work, for sure. But with the new parser test runner, you can automatically run all the parser tests in 4-8 seconds, and have the results reported back to you cleanly and efficiently.

I really hope the community loves the new test runners, I know I already do! Moving forward, I will focus my efforts on developing the integrated testing system for Popcorn.

Cheers!

It's called Pyspace and it's really easy to use. Already has made my life easier. hope it helps you too. Here's the source:

#!/usr/bin/env python

import sys, re

fileName = sys.argv[ 1 ]
pattern = '[t ]{1,}$'

if fileName:
  openFile = open( fileName, 'r' )
  trimmed = []
  line_no = 1
  found = False

  print "Checking " + fileName + " for end of line whitespace..."

  while 1:
    line = openFile.readline()
    if not line:
      break
    if re.search( pattern, line ) != None:
      print "trailing whitespace found on line " + str( line_no )
      found = True
    trimmed.append( re.sub( pattern, '', line ) )
    line_no += 1

  if not found:
    print "No end of line whitespace found."
  openFile.close()
  openFile = open( fileName, 'w+' )
  
  for i in range( 0, len( trimmed ) ):
    openFile.write( trimmed[ i ] )

  openFile.close()

									

Get the source on Github

It began on Saturday morning at the Mozilla Toronto office. Admittedly, I was a little under the weather from being there the night before for the Firefox teams' hack week party. Despite this, I stuck to my commitment to participate. After fueling up on healthy foods to help ease my discomfort,  I was feeling way better by the beginning of the opening circle. moving from person to person around the circle, we introduced ourselves, and stated what the last documentary we saw was or what the first computed that we'd ever had was (My first computer was a family computer, it was a Macintosh, which looked a lot like this ).  We then spoke briefly about the mission for the weekend and then broke off into our teams to begin work on our projects.

I was paired with two fine gentlemen who flew in from the States. Christopher Allen was the Filmmaker on our team. Christopher is the principal founder of UnionDocs, a US non-profit organization whose purpose is to create documentaries that cover a wide range of topics. James Burns was the developer that Christopher brought with him to the event. James is the Founder of Zeega, an HTML5 tool being developed that creates interactive web media experiences, much like Popcorn Maker.

The UnionDocs project is titled "Living Los Sures". Christopher discovered a documentary made in the 1980's about the Brooklyn neighborhood where UnionDocs is based. A group of many documentary artist in the "UnionDocs Collaborative Studio" is collecting footage of the community as it is now, and of people featured in the film as they are today.. This gave us a whole lot of content to use to create something really awesome. His vision was to take the footage from the past and present, and use web technologies to build a way of presenting content from both films at the same time. We decided on creating 3 separate "experiments".

To compliment these experiments, we needed to build 2 things. The first was a Zeega Popcorn plug-in. This plug-in would populate an area of a web page with a Zeega project, using the Zeega API that James built. We used my experience creating popcorn plug-ins and James' knowledge of the Zeega API to create a rudimentary and functional first version of the Zeega plug-in. Following that, we needed to create a tool that would be able to take two media elements on a web page, and modify their volumes based on the ratio of the distance of the mouse pointer between the centre of each element. I built the tool and with much help from James, figured out the formulas we needed (from scratch, because that's more fun) to calculate volume levels. I lovingly titled this little tool "Ratiator.js". You can find it on my Github account. One of the tools we required was based off of a previous demo that James had put together, and would require us to make several modifications to fit the experiment we needed it for.

While James and I built these tools, Christopher worked very hard putting together all the video and audio content we needed, whether it be cutting clips in Final Cut Pro to creating Zeega projects using clips he had available. At the end of the day on Saturday we parted ways knowing that we had all the tools we needed to bring Christopher's vision to reality.

I started out day two feeling like a million bucks. Christopher, James and I quickly got to work, making last minute modifications to the tools, and setting up the project's main structure. Christopher continued his work creating the visual and auditory content for the experiments. Normally you'd expect to hear about the first experiment first, but seeing as we worked on them completely out of order, it would make more sense to describe it chronologically.

We first started on the third experiment. This experiment would make use of Popcorn.js for a lot of the timing based events that we had. It would also incorporate the the new Zeega plug-in and the two UX elements we would use in the first two experiments, but at the same time. We spent a good portion of the day pair programming the experiment together. We did the first experiment next. It would be an interactive trailer, incorporating clips from the original film on the left and the new film on the right. The user would be encouraged to click and slide a "line" from left to right, revealing one video while hiding another. Christopher cut two trailers in a single day, having them displaying very similar content/clips at the same time. The fact that he was able to produce both of these videos in a matter of hours still boggles my mind. He is a Final Cut Pro wizard. My explanation of the experiment is a little vague, and is best experienced to be understood.

The second experiment was simple in concept but powerful to experience. Two videos were placed side by side. The left video showed a group of police officers from the neighbourhood who walked the beat at the time the original documentary was made. They were sitting around a laptop, watching a video, commenting on the things they were seeing. On the right side, we put the very same video that the police officers were watching. The two videos were synced, and using Ratiator.js, we created an experience where you could mouse over a video to hear itand mouse over the other to hear it, or hover in between to hear both, which turned out to be very powerful and worked very nicely.

We finished up all the experiments, tied them together into one experience, and tested. We finished everything and had it up on GitHub, ready to view with 5 minutes to spare before the deadline at 7 PM. I felt our presentation went very well, and was well received. There were a couple minor hiccups, but nothing very serious.

I thoroughly enjoyed viewing the creations of the other 5 teams, everyone created something very unique and really awesome.

I also would like to thank Christopher and James for being such great team members, it was an absolute pleasure working with them. I'd also like to thank Mozilla and the Hot Docs people for putting together the event and for hosting. Special thanks goes out to Brett Gaylor and Ben Moskowitz, and Mari Moreshead for working so hard to organize everything!

The demo we created has a few limitations to keep in mind, if you would like to view it. The first limitation being that due to time constraints we were only able to get media in a format supported by the Chrome browser. The second issue, is that there's a lot of data. to view the experience, make sure you have a lot of data allowance (100's of MB) and please allow some time to the presentation to load the media sources. If it fails to work the first time, try refreshing the browser, it can fix random failures that we experienced.

Here's the link to it: http://cadecairos.github.com/los-sures/

When I find the time I'll do a screen cast of it and update this post with a link.

In the mean time, I've got to settle into my new desk at CDOT and try not to feel overwhelmed by all the new responsibilities I'm taking on, now that I've become one of the veteran members of the team at CDOT.  I know I'll do just fine, because I don't take my responsibilities lightly!

Its hard to believe that a year ago today I was starting out here at CDOT. I'm looking forwards to the next year, which is no doubt going to be even more exciting and eventful that the last. who knows where we'll go!

This, the last post I'll be making for my OSD700 class is going to discuss the work I've been doing on the above mentioned bugs.

I've been working on these two for a while, and as of today I'm very, very close to getting them land. 726904 is R+ and is waiting on 517363 ( more on that later )

I've written several times about 726904 ( here, here, here ) but I will summarize it for you once more. It's titled "nsVideoFrame::GetVideoIntrinsicSize setting wrong size" and I filed it in mid February while working on 517363. I noticed that the initial size of a video element wasn't behaving how I expected it to if there were no explicit sizes defined for it ( Either through height/width attributes or CSS ). I mentioned this is 517363 and Robert O'Callahan pointed me to the specification, and upon investigating, I found that Firefox was setting the video size incorrectly.

I've iterated on this bug so many times I've lost count ( I lied, I have all 14 versions of my patch ). Fixing up the GetVideoIntrinsicSize method as probably only 15% of the work I did. The rest was all put into updating the reftests that my patch broke. I'd say the most challenging part of updating the reftests was to make sure that they were still testing what they set out to. As a bit of extra work, I also modified a getVideoSize method to work better for our purposes in this bug.

Now that 726904 is ready, I've focused my efforts back on 517363, and I'm making great progress. This bug wanted to add poster frame scaling to the video element. In Firefox 11, the stable version as of the writing of this post, when you add a poster frame to a video, Firefox will stretch/shrink it with no regard for it's intrinsic ratio, making it fit in the video frame. With this fix in place, the poster image will always have it's aspect ratio preserved if it needs to be resized.

This patch has been a fun one to produce, because I had to learn how to scale the image properly, and efficiently. Taking from areas in the same file that scale the video frames, I was able to construct a process for the poster frame that would do exactly what we needed.  There were several issues I had to deal with, such as centring the image, and making sure I took into account borders.  I now have a (hopefully) solid patch that works, and I based it off of my patch for 726904. About 45 minutes prior to writing this I pushed both patches together to try ( https://tbpl.mozilla.org/?tree=Try&rev=2fde97b75aa7 (This link will expire)) so we're going to know soon whether these patches bring Firefox's Video element up to par with the spec.

These two patches may not have landed, but they will be landing very, very soon. When they do land, I'll be proud to know that My hard work brought Firefox Video up to standard when determining it's Intrinsic size, and that I enhanced poster frame behaviour for all Firefox users worldwide. I'm looking forward to taking on another challenge sometime soon!

When I first started in OSD600, I knew next to nothing about the open source community, but I was eager to learn more about it ( because I dislike paying for software ). In the span of a few weeks I had to get familiar with the tools of the trade ( IRC, Git and GitHub, Version tracking, etc ). I created a now obsolete tool called VideoSequencer, using JavaScript. It was designed to take any number of HTML5 videos, and string them together one after the other, as if they were one video. While the tool never saw the light of day, I thoroughly enjoyed the time I spent working on it, and the freedom that having the source open to all gave me when asking for advice on how to solve a problem. I finished OSD600 with a new respect for the open source philosophy and a solid knowledge of the tools.

After OSD600 ended, I began a a series of three consecutive co-op work terms, two of them placing me at CDOT, where I was able to apply the skill I developed in OSD600 to a new level. I became part of a community of highly skilled developers working on Popcorn.js, Butter.js and Popcorn Maker. The experience I gained from this had me more than ready to take it up a notch when I signed up for OSD700 late last year. Because I was already familiar with the Popcorn.js community, I chose to get myself involved in Firefox development.

When the semester began, I did initially feel a little nervous. I had been told time and time again that the Firefox source code was large and complex, and I knew I'd face plenty of challenges. Humph pointed me towards a bug that looked like a good starter challenge. The bug was for a problem with setting the mozFrameBufferLength attribute on media elements. I spent dozens upon dozens of hours tracing through code, debugging, tinkering and waiting for builds to finish all trying to fix this bug. I probably learned the most important lesson on this bug: Ask for help! I finally solved the bug by blogging about it and by seeking help on IRC.

Another important lesson was taught to me while working on this bug. Although I'd put so much time into it, the fix was incredibly simple. I added a single missing keyword to a function. Even the most simple of solutions can evade someone who's not familiar with a piece of code.

Following that experience I found myself working on a bug related to scaling poster frames. This was also an area I had no experience in. I did some initial investigation into the code, looking for places where the current poster frame drawing was handled. My familiarity with the code was growing, especially after the time I spent on my first bug, looking through the media code. I did my best to build on what I'd learned on my first bug. I blogged about my issues and asked questions on IRC. I was eventually able to make a work in progress patch and throw it up for some feedback.

It was around this point where I learned another thing about programming on a project of Firefox's size. When working on a piece of code and testing specific features, 9 times out of 10 you'll end up filing a new bug. I filed a bug based on my poster frame scaling bug, when I discovered that Firefox wasn't behaving according to spec when sizing a video element as a page loads.

I've since iterated many times on that bug, going though over 10 versions of the patch. I've yet to complete it though. The reason for this is simple: ref tests. Ref tests compare a page to a reference image, ensuring output stays consistent. My problem lies in the fact that I'm changing the natural behaviour of the video element, which had ref tests that enforced the incorrect behaviour. I've been trying my best to get them to pass, but between the poster frame scaling and the video resizing bug, I've been foiled at every turn.

My experience developing for  Firefox has been a wonderful one. I've been able to contribute to and land code in a widely used application. I've been able to resolve several issues holding the browser back, making it better than ever, and that gives me a real sense of accomplishment. I've learned a lot about collaborating on a project the size of Firefox, and the importance of communication when you're lost in a bug.

I really enjoy spending time hacking on this code. I'm going to finish the bugs I've been working on even if they don't land before the semester ends. But with some luck and hard work I might be able to get them working in time. A lot of the courses I've taken at Seneca have taught me the things I need to know. Things like object oriented design, algorithms, Database analysis and design, etc. But only OSD700 gave me a real world experience. I've been able to communicate and collaborate with real developers working on a real product. I don't think I could have found this at any other educational institution in the province. When I look back on the time I spent as a Seneca student, I know that I will think of the amazing opportunities that were given to me, especially while in OSD700.

Bug 736400 - media.[ogg,webm,wave].enabled cannot toggle off media playback

I found this bug while playing around with media decoder user preferences. I noticed that under certain circumstances it would be impossible to disable a media type. I wrote a quick post about this experience here.

The fix has now been merged into mozilla-central:  https://hg.mozilla.org/mozilla-central/rev/391418d235a8

Bug 726904 - - nsVideoFrame::GetVideoIntrinsicSize setting wrong size && Bug 517363 - Preserve video poster aspect ratio when scaling

The two bugs are now basically one problem. The problem being making sure that landing one patch does not break the other. I've been spending a large chunk of my time hacking on this. Problems I'm facing recently are related to mochi tests and reftests.

Now that I have try server access it's been easier for me to test my patches. My latest patch for 726904 seems to work fine on my Linux box that I use for development, but fails all the reftests when I push to try. I honestly haven't a clue why. But I'll keep hacking until I figure it out.

Selenium Grid is a Java based testing infrastructure that relies on a central server, called "The Hub". Connected to this hub are separate entities, called "nodes". When Selenium receives a connection requesting tests to be run, the hub will look at the request, and based on what browser/os and what nodes are currently connected, the hub will forward the test commands to the node. Upon receiving tests from the hub, the node will launch the requested browser, perform the tests and return the results back to the hub. The hub will then send the results back to the script that initiated the tests. Nodes are handy because (once I can figure out how to configure everything properly) we'll be able to run tests on different platforms and different browsers. You can read more about Selenium Grid here.

Selenium tests can be written in several different languages ( C#, Ruby, Java, etc. ) but I have chosen to use Python. For our purposes, tests will be grouped into python files by type, i.e. TrackEvents, Menus, Save/Export. Inside each python file, we will place the test cases. Each case is defined as a class, for example "testcase_TrackDrop" would be a good name for testing dropping a track onto the timeline. The python module that Selenium provides gives us a multitude of useful commands for creating tests (more on that later). Simple things like checking for an element's existence are possible, as well as specifying clicks, drags and drops, to even more complex things like injecting JavaScript that can perform some function and return a value to selenium. The basic structure of a test case would be to perform a list of actions, and enforce several assertions before, during and after executing actions on the UI. If all of the assertions return true, selenium will record the test case as a Pass. You can check out the python API here.

Writing tests shouldn't be too difficult, even for those who are less familiar with python ( First time I ever used it was about 2 weeks ago ).  Selenium provides an extremely useful Firefox add-on called Selenium IDE that enables tests to be prototyped very easily ( although there is a slight learning curve ). With the IDE you can specify the actions you wish to perform, selecting what to perform them on in the webpage and where you want them to be performed. It also allows you to run the tests live on the target web page, so it's super easy to debug the tests as you develop them. Once you've written your tests, the IDE gives you an option to export them into Python. You can read about & get the Selenium IDE here.

After exporting the test into Python integrating it into the test system I've been developing will be straightforward and simple. You must determine if the test belongs to an existing set of test cases (like I described earlier) or if you need to create a new file for the type of test you have created. I'll go over both types for you guys.

If you are adding a new Python file for the test case, add this header to the top of your Python script:

from selenium import selenium
import unittest, time, re, sys

sys.path.append( "../../../../content/" );
import btv

global testvars
testvars = btv.ButterTestVariables
									

Ensure the "setUp" method of your test case class looks like:

def setUp( self ):
  self.verificationErrors = []
  self.selenium = selenium( testvars["Host"],
                            testvars["Port"],
                            testvars["Browser"],
                            testvars["Grid"]
                            )
  self.selenium.start()
									

...which grabs the necessary configuration variables for Selenium, and opens the connection to the grid

Copy the meat of your test (read: test command & assertions ) into a "test_case" method

def test_case(self):
    sel = self.selenium
    sel.open(testvars["ButterTestPage"])
    sel.set_speed( 500 )
    sel.wait_for_page_to_load("7500")
    for i in range(60):
        try:
            if sel.is_element_present("id=TrackEventView1"): break
        except: pass
        time.sleep(1)
    else: self.fail("time out")
    sel.mouse_move_at("id=TrackEventView1", "5,0")
    sel.mouse_down_at("id=TrackEventView1", "5,0")
    self.failUnless(sel.is_element_present("id=TrackView2"))
    sel.mouse_move_at("id=TrackView2", "300,5")
    sel.mouse_up_at("id=TrackView2", "300,5")
    self.failUnless(sel.is_element_present("id=TrackEventView1"))
									

Make certain to tell selenium to open the right test page using "testvars['ButterTestPage']"

You should then fork and clone my ButterSeleniumTesting repository on GitHub.

Within the 'contents/' folder is a file called "testRunner.py" which needs to be made aware of the new test case(s).

If you created a new file, import it below this bit of code:

#------IMPORT TEST CASE FILES-----#
print sys.argv[2];
sys.path.append( "../clones/" + sys.argv[2] + "/test/selenium" )
import testcases_tracks
									

If no new file was created skip the above step

Add the test to the test runner. Use the current lines there as an example of how to load them.

self.suite.addTests([
#-----TEST CASES GO HERE-----#
    unittest.defaultTestLoader.loadTestsFromTestCase(testcases_tracks.testcase_TrackDrop),
    unittest.defaultTestLoader.loadTestsFromTestCase(testcases_tracks.testcase_DeleteTrack)
    ])
									

You should now be good to go!

The team will have to decide on a proper way to review and approve tests as we move forward. Perhaps this could be done by creating a "try" server of sorts.

Another large component of the system is reporting test results. I was directed by Selenium's *very* sparse documentation to use a completely undocumented Python tool called HTMLTestRunner for doing this. After many hours of cursing and pacing back in forth in thought, I managed to get my code to generate easy to read static html report pages. Each test job that the grid gets will output a timestamped html file, and overwrite an existing "last_run.html" file that can be viewed to see what passed and/or what did not pass. These static report pages are helpful but are ultimately not quite what we want to be using in the long term. Here's a sample report page from an actual test run. I have a couple ideas for upgrading this process. I could modify HTMLTestRunner to post data to a PHP script which would record the results in a database, and have another page that can query the database for test runs and results ( this is probably the more complex solution ). The second idea is a little more simple. I'll changed the titles of the test result pages to commit ID's and create page that would scrape the results directory and list each test run in chronological order.

Another consideration will have to be maintenance. The test system I created needs to clone a new butter repository for *every* job. This will inevitably use up a lot of disk space, so It will need to have a mechanism in place to keep the disk usage in check.

There you go! A not so brief description of what's been done! Feel free to reach out to me if you have any questions, concerns or ideas. Thanks for reading!

virtual nsMediaDecoder* Clone() {
  if (!nsHTMLMediaElement::IsOggEnabled()) {
    return nsnull;
  }
  return new nsOggDecoder();
}
									

in each of the decoders. I built nightly and tested the prefs, everything looked great.

One thing I did not anticipate, neither did my reviewer, was the Raw media type. I'm not entirely sure as to what it is exactly, but it is disabled by default for Desktop Firefox builds. It is, however, enabled when building Mobile Firefox. When My patch was landed on Mozilla-Inbound, It killed the mobile builds.

The failing build was being caused by my call to nsHTMLMediaElement::IsRawEnabled() in the Raw Decoder. Unlike the other "is[Type]Enabled()" methods, the Raw version was not a static member of the class, and thus, would fail when building for that platform. I quickly made the method virtual, and threw up the fix. It was promptly merged into mozilla-inbound, and right off the bat I saw it failing once again on Android.

Turns out IsRawEnabled iscalled within the static IsRawType function. It was failing because it needed to know that IsRawEnabled was now a member of nsHTMLMediaElement. A silly thing to miss, and because of it we had to once again back out the patch. I fixed it up, and threw up the new patch.In a change of pace, Chris Pearce pushed it to the try servers for testing, and everything looked good!

Lesson learned? Even small patches should be tested, cause you never ever know what you could break!

And on Android, I'll leave you with the words of philor:

[19:16] <philor> nobody expects the Android bustage: its three main weapons are fear, surprise, unexpected bustage, and a fanatical devotion to the Pope

Here's a list of all the Firefox bugs I've been active on:

• Bug 495040 - Implement playbackRate and related bits
• Bug 665598 - pref to completely disable html5 video/audio elements/objects
• Bug 665395 - there should be a pref to completely disable media including disable Audio API extension (window.Audio object)
• Bug 736400 - media.[ogg,webm,wave].enabled cannot toggle off media playback
• Bug 726904 - nsVideoFrame::GetVideoIntrinsicSize setting wrong size

Implement playbackRate and related bits

I started this bug after Dave challenged us to implement something new in Firefox, rather than only go about fixing bugs. To be honest when I took it, I knew I was getting in over my head. Despite this, I felt that I should challenge myself. I began this bug by merging in a 2 year old patch into the current code base. Once I fixed all of the conflicts, I had the playbackRate and defaultPlaybackRate attibutes present on HTML5 media elements. I spent several days examining and getting familiar with the process of displaying video frames, but to be honest, the scope of what needed to be done was far beyond my understanding. After discussions with Chris Pearce, I determined it to be the right choice to post what I had, and leave the implementation of changing playback speed to someone with more experience in that code. I wouldn't say it was for nothing, not at all. I now have a better understanding of the inner working of media elements, which is no doubt going to be useful in the future.

pref to completely disable html5 video/audio elements/objects

I was pointed to this bug by Chris Pearce, after discussing the above mentioned bug. This bug wants to add a browser wide pref to disable all media types. Currently, there are prefs to disable the individual media types ( ogg, webm, wave, raw ), but no way to disable all of them at once. This one was pretty easy to find my bearings in. I added the pref "media.enabled" and added logic to disable media if the pref were enabled.When testing, I noticed that if I had played a video already, and then disabled the media type, The video would still be able to play. I filed 736400 based on this.

Speaking with Chris Pearce today, we agreed that this pref isn't needed. So The bug will probably be closed. On the bright side, I did file a new bug

there should be a pref to completely disable media including disable Audio API extension (window.Audio object)

This bug came to me along with the previous one. This one's looking for a way to disable writing raw audio data in JavaScript, using a user pref. By default, it would be disabled. The usefulness of this pref would be for users of Firefox who are concerned about websites playing audio using JavaScript without their permission. It can be likened to FlashBlock's disabling of Flash objects.

I've got an experimental patch in the works, but recent talks with Chris Pearce have shown me I need to change the direction I've been moving in. I will likely have a patch ready to go sometime this weekend.

media.[ogg,webm,wave].enabled cannot toggle off media playback

I filed this one when I noticed that under specific circumstances, the user prefs to disable media types would not actually disable media. Searching for instances in the code where the pref was checked, I noticed that it was done before instantiating a decoder type. The code there appeared to be solid, and worked if a decoder had not existed previously. I realized there might be a different code path being taken if a decoder previously was instantiated. This proved true, and the problem revealed itself in the clone method of each type of decoder.

The first time a media element is created, the MIME type of its source is used to check if that type is enabled. When it is cloned however, The check is not performed. I zeroed in on the method used to clone a decoder, and found that by the time the clone method was called, the MIME type of a media was no longer available, thus making it impossible to do the same check. I determined it was then necessary to add the check for each decoder in the clone method of each decoder type. This worked perfectly. you can check out my patch here: https://bugzilla.mozilla.org/attachment.cgi?id=607031&action=diff

nsVideoFrame::GetVideoIntrinsicSize setting wrong size

I've been working on this one for quite a while now. You can read more about it in some of my previous posts ( 1, 2 ). Progress on it the past few weeks included a review of my patch, and some fixes to style in my tests. I also uploaded a corrected patch containing the binaries of images I've used. This bug is likely going to land along with bug 517363 because they both fix sizing and display issues, and one has the potential to break tests that were fixed in the other.

This brought me to bug 495040. The purpose of this bug is to implement playbackRate on audio and video elements. PlaybackRate is a value that represents the speed of the media's playback. Regular playback speed is 1.0, so doubling playback speed would need a playbackRate of 2.0, and halving it would need playbackRate to be set to 0.5. Matthew Gregan had already posted up a work in progress patch over 1 year ago, so I started there.

The WIP patch was very difficult to apply to the current tree, due to its age. There were many conflicts I had to fix. Reading through the comment history of the bug, I found that Matthew had implemented audio timescale-pitch modification using a library called SoundTouch. Reading further I found that the use of Soundtouch was going to be separated out to another bug, and this bug would just implement the playback speed changes. This simplified things, as I could strip out bits related to SoundTouch. After that it was just a matter of resolving the merge conflicts and updating old code to fit with the current state of the media code.

This is all compiling nicely now. I'm now at a place where I have no real idea what to do yet. I need to actually take that attribute I've created (playbackRate) and use it to change the playback speed of the media. I've been spending most of my time studying how the videos are being decoded and displayed, but I only recently realized that I also need to change the audio playback speed as well. So, I shall continue my search, and will likely poke around on IRC for hints on where to go for this.