Profiling and collecting data right now is a pain. Each platform as its own set of tools that are often never at hand when you notice something going slowly. Or you noticed a short lived hang that you can’t really reproduce once you attach your profiler.

Built-in profiler to the rescue. By having a profiler built in we get many benefits. We can build a profiler that works across platform, that is always on, that grabs markers for important events (page load start, new tab open, first paint), that can be started/stopped programmatically, that can integrated with the UI using extensions and inlines the JS stack.

I made a 5 min demonstration of this profiler in action:

Quicktime version: Profiler Screencast 420p.

This is a proof of concept at this stage. It currently only works well on Mac and somewhat on Android but with a bit of work it should work well on all platforms we support. Further down the road we’re hoping to move the front end to a web application that we can easily collect profiles and link them within bugzilla.

We’re looking for help porting this to windows and linux, hooking in libunwind and working on the web front end. If you’re interested in helping out let us known.

I first tried to get involved with Mozilla in 2007 several years before applying for an internship position. As an insider it’s easy to imagine how one would start to contribute to Mozilla by finding a bug on bugzilla or contacting someone on IRC. In practice this is much harder. I tried searching similar keywords such as ‘mozilla contribute programming’. This search leads to the promising page http://www.mozilla.org/contribute/ which is similar to what I remember finding several years ago. The visual layout of the page however puts emphasis on Webify Me/WebFWD but does not mention direct ways to contribute via Coding and QA.

I still remember the mindset that I had back in 2007. I was specifically looking for a task to work on and I was hoping to get a point of contact to be able to ask questions for that specific task. I finally got involved with Mozilla once I was offered an internship where I received clear tasks and mentors to ask questions to. I hope that the process for new community members will resemble the internship process.

I feel like mentored bugs will help address this. I hope that we focus on making them more visible through SEO, http://www.mozilla.org/contribute/, simplifying wiki links. We need to improve the quantity and quality of the mentored bugs. This is where Contributor Steward will be helpful. Quality for mentored bugs is still lacking. Josh Matthews posted a great explanation, yet I took a random of mentored bugs and myself was confused where to start on certan bugs.

I hope to discuss many suggestions with David Boswell in the future, and I hope others follow suit on the mozillians mailing list.

1. Use ‘adb devices’ to get each device’s serial number.
2. Set the environment variable ANDROID_SERIALS to the serial number.
3. Run reftests by using a unique http and ssl port for each instance: EXTRA_TEST_ARGS=”–http-port=$ANDROID_REFTEST_HTTP –ssl-port=$ANDROID_REFTEST_SSL”

Here are the scripts I use:

device_xoom.sh

export ANDROID_REFTEST_HTTP=38888
export ANDROID_REFTEST_SSL=30443
export ANDROID_SERIAL=03abd624740a0d057
export ANDROID_DEVICE_NAME=XOOM

fennec_reftest.sh

echo $(cat ~/.config/moz_tree)/$1
cd $(cat ~/.config/moz_tree)
install_fennec.sh
EXTRA_TEST_ARGS="--http-port=$ANDROID_REFTEST_HTTP
--ssl-port=$ANDROID_REFTEST_SSL --setpref=layers.acceleration.force-enabled=true"
MOZ_HOST_BIN="../obj-fn-opt_para/dist/bin/" make -C $(cat ~/.config/moz_tree)/$1
reftest-remote | tee ~/mozilla/reftestlogs/fennec_reftest_log_$ANDROID_DEVICE_NAME.txt

Source: Wikipedia

The changes are in the nightly build and can be enabled by setting the preference |gfx.color_management.enablev4| and restarting your browser. You can confirm that the feature is enabled by visiting Is your system ICC V4 ready. At this point we encourage everyone to help test the feature and would like to collect feedback in bug 488800.

By using the gold linker you can reduce the incremental build time from 5 minutes down to 15 seconds!

Here are the steps I used to setup gold:

1. Download the binary from: http://hg.mozilla.org/users/b56girard_gmail.com/files/raw-file/tip/real-ld and http://hg.mozilla.org/users/b56girard_gmail.com/files/raw-file/tip/real-ld-gold (thanks to mwu).
2. Place the files in |<…>/android-ndk-r4c/build/prebuilt/linux-x86/arm-eabi-4.4.0/arm-eabi/bin| and make sure they have the execute bit set. (WARNING: There’s multiple bin directories, make sure you go in arm-eabi/bin)
3. Increase nofile ulimit: open /etc/security/limits.conf and add the line |* hard nofile 65535|, then use |ulimit -n 65535| (Bug 10708)
4. Disable elf-hack: Add |ac_add_options –disable-elf-hack| to your mozconfig. (Bug 671944)
5. Clobber build recommended.

With an updated binary we could get around step 3 and possibly even step 4.

I made a ZNC (IRC Bouncer) module called cmdnotify. The module will invoke a script when a highlighted word is mentioned if you are not attached to the bouncer. In my case I relay the message over SMS to my phone.

If you’re interested in setting this up for yourself you will first want to configure ZNC and then install my cmdnotify module.

Please pay attention to any regression you may encounter with plugin rendering and file them as blocking Bug 598425.

Note: In this context we mean that the drawing is asynchronous from the view point of the browser process. The drawing between the plugin container and the plugin (via NPAPI) is unchanged, for that see the proposed spec NPAPI:AsyncDrawing.

These instructions start from the point where you have a simple build of Firefox completed with the latest windows SDK and VS 10.

• Create a new project using ‘Project from Existing Code’ (See Joe Walker’s comment if you don’t have this).
• Select ‘Visual C++’, enter a project name (ex: mozilla-central), source directory as project file location, select ‘Show all files in Solution Explorer’.
• Make sure you un-select ‘Add Files to the project from these folders’, hit Next.
• Select ‘Use external build system’, hit Finish.
• Project will be empty until you select ‘Show all Files’ from the solution explorer, File -> close the solution, re-open it. Source files should appear (I had to do this step 3 times)
• For autocomplete select Project ->Properties -> NMake.
• Under ‘Preprocessor Definitions’ add XP_WIN (return here later to add any definition your may be compiling with/find missing)
• Under ‘Include Search Path’ type in ‘<objdir>\dist\include’ (I recommend to have built your project from command line for this step)
• For debugging select ‘Debugging’ still under the property page, type in the absolute path to firefox.exe. Recommended command argument ‘-P “Minefield” -no-remote’.

I strongly recommend using ‘Console’ when working from the command line.

Optional: Add a build/clean target (Can otherwise be done outside of Visual Studio using the command line)

• Create a single script, build.sh, that you can invoke that will trigger a build with the configuration you need. It should set all environment variables needed.
• Copy the ‘mozilla-build/start-msvc10.bat’ to ‘mozilla-build/start-msvc10-build.bat’.
• Replace the last line to read something like ‘”%MOZILLABUILD%”\msys\bin\bash –login <path-to-your-build-script>/build.sh’.
• Select Project->Properties->NMake, for Build Command Line type ‘C:\mozilla-build\start-msvc10-build.bat’.
• Advanced: Create multiple project configuration for each mozconfig build configuration you would like to work with then have them invoke specific build scripts and firefox.exe.

You can modify your script to do incremental builds to reduce your turn around time.

A proposal for integrating mercurial queues and bugzilla to share patches in progress.

Overview

Bugzilla is a great tool for tracking progress towards the resolution of a bug. Posting comments and uploading completed patch for review is good but I feel like most of the magic happens mostly offline. I’m talking about mercurial queues where patches are attempted, scrapped and improved. Some developers are already sharing their queues but without proper integration this rich information goes mostly unnoticed.

My proposal is to index developers’ mq repositories, on an opt-in basis, and to integrate this information with bugzilla by extending the bugzillatweaks add-on. This would make developers’ patches show up in bugzilla as they are created, improved and provide a full revision history/changelog. This lets other users know that a patch is progress. For developers this provides an easier way to import patches from a dependent bug, continue a blocker/security bug if the assigned developers is away, consult the changelog to see every solution that was attempted and of course giving feedback to and studying unposted patches.

I wouldn’t dream of adding another step to the workflow of developers so the solution I’m suggesting is a simple one time opt-in to have your queue repository indexed. Well almost. Patches can’t be indexed until the developer adds the bug number in the patch summary but this gives a bit of control over which patch will get indexed.

Sample

I have a jetpack prototype working (did I mention how amazing jetpack is?) and have had Ehsan opt-in for my demonstration.

First we see a simple case where Queuezilla displays the most recent patch Ehsan is working on for a particular bug:
Screenshot

Here is a more complicated bug where we can see regular patch attachments and all the patch parts that are being worked in Ehsan’s repository:
Screenshot

Finishing the add-on

This add-on is still missing a web service to periodically index mq repos of developers that opt-in. I am curious to hear from developers who would like to start using this add-on before spending the time to develop the service because the add-on is only useful if several developers participate.

If so please let me know if you are currently using a mq repo or if you have an alternate setup where your progress could be indexed.

Disclaimer: This is not aimed at replacing patch attachments and provides no review system. A stable patch file is a must for the review process.

My concern is the current mozilla wiki does a great job of being a key reference for nearly every topic but acts as just that, a reference. I have discussed offline a few times the idea of creating resources aimed specify at new members. Dria’s recent blog (1) posts (2) asking for screencasts and resources aimed at learning mozilla caught my attention.

My goal is not to duplicate the existing resources but to create a comprensive guide that gives an appropriate overview of all the different systems, interactions and processes we have in place and explain how they fit together and use them.

I would like to get feedback on the bare essentials that should be covered. I would like to receive input on this before I commit to a Syllabus. Here is the current Syllabus I had in mind.

Communicating at Mozilla

Discuss how we use e-mail, IRC, bugzilla, blogs and RSS. What medium should be used to discuss what.

Developing at Mozilla

Checking out the source, building, finding a bug in bugzilla ([good first bug] tag maybe?), finding a mentor for your bug, applying & creating patches, running tests, tinderbox, tryserver, getting your patch reviewed and landed. For this one I was considering walking a user through reverting to prevision revision before a small bug, recreating the patch, testing it and showing the steps taken to land the patch.