I have the privilege of having my desk located around a bunch of really intelligent people from the Mozilla Services team. They've been talking a lot about all the new technologies around server provisioning. One that interested me is Docker.

Docker is a pretty nifty piece of software. It's essentially a glorified wrapper around Linux Containers. But, calling it that is doing it an injustice.

Docker interests me because it allows simple environment isolation and repeatability. I can create a run-time environment once, package it up, then run it again on any other machine. Furthermore, everything that runs in that environment is isolated from the underlying host (much like a virtual machine). And best of all, everything is fast and simple.

For my initial experimentation with Docker, I decided to create an environment for building Firefox.

Building Firefox with Docker

To build Firefox with Docker, you'll first need to install Docker. That's pretty simple.

Then, it's just a matter of creating a new container with our build environment:

curl https://gist.github.com/indygreg/5608534/raw/30704c59364ce7a8c69a02ee7f1cfb23d1ffcb2c/Dockerfile | docker build

The output will look something like:

FROM ubuntu:12.10 MAINTAINER Gregory Szorc "gps@mozilla.com" RUN apt-get update ===> d2f4faba3834 RUN dpkg-divert --local --rename --add /sbin/initctl && ln -s /bin/true /sbin/initctl ===> aff37cc837d8 RUN apt-get install -y autoconf2.13 build-essential unzip yasm zip ===> d0fc534feeee RUN apt-get install -y libasound2-dev libcurl4-openssl-dev libdbus-1-dev libdbus-glib-1-dev libgtk2.0-dev libiw-dev libnotify-dev libxt-dev mesa-common-dev uuid-dev ===> 7c14cf7af304 RUN apt-get install -y binutils-gold ===> 772002841449 RUN apt-get install -y bash-completion curl emacs git man-db python-dev python-pip vim ===> 213b117b0ff2 RUN pip install mercurial ===> d3987051be44 RUN useradd -m firefox ===> ce05a44dc17e Build finished. image id: ce05a44dc17e ce05a44dc17e

As you can see, it is essentially bootstrapping an environment to build Firefox.

When this has completed, you can activate a shell in the container by taking the image id printed at the end and running it:

docker run -i -t ce05a44dc17e /bin/bash # You should now be inside the container as root. su - firefox hg clone https://hg.mozilla.org/mozilla-central cd mozilla-central ./mach build

If you want to package up this container for distribution, you just find its ID then export it to a tar archive:

docker ps -a # Find ID of container you wish to export. docker export 2f6e0edf64e8 > image.tar # Distribute that file somewhere. docker import - < image.tar

Simple, isn't it?

Future use at Mozilla

I think it would be rad if Release Engineering used Docker for managing their Linux builder configurations. Want to develop against the exact system configuration that Mozilla uses in its automation - you could do that. No need to worry about custom apt repositories, downloading custom toolchains, keeping everything isolated from the rest of your system, etc: Docker does that all automatically. Mozilla simply needs to publish Docker images on the Internet and anybody can come along and reproduce the official environment with minimal effort. Once we do that, there are few excuses for someone breaking Linux builds because of an environment discrepancy.

Release Engineering could also use Docker to manage isolation of environments between builds. For example, it could spin up a new container for each build or test job. It could even save images from the results of these jobs. Have a weird build failure like a segmentation fault in the compiler? Publish the Docker image and have someone take a look! No need to take the builder offline while someone SSH's into it. No need to worry about the probing changing state because you can always revert to the state at the time of the failure! And, builds would likely start faster. As it stands, our automation spends minutes managing packages before builds begin. This lag would largely be eliminated with Docker. If nothing else, executing automation jobs inside a container would allow us to extract accurate resource usage info (CPU, memory, I/O) since the Linux kernel effectively gives containers their own namespace independent of the global system's.

I might also explore publishing Docker images that construct an ideal development environment (since getting recommended tools in the hands of everybody is a hard problem).

Maybe I'll even consider hooking up build system glue to automatically run builds inside containers.

Lots of potential here.

Conclusion

I encourage Linux users to play around with Docker. It enables some new and exciting workflows and is a really powerful tool despite its simplicity. So far, the only major faults I have with it are that the docs say it should not be used in production (yet) and it only works on Linux.

Globaleaks 0.2 Alpha is out.

Globaleaks is an open source project aimed at creating a worldwide, anonymous, censorship-resistant, distributed whistle-blowing platform. It enables organizations interested in running whistle-blowing initiatives to setup their own safe zone, where whistle-blowers and recipients can exchange data.

2 Years ago I helped out with the development of Globaleaks 0.1. And although I am not active anymore, I really support the initiative behind it. Now with the HERMES Center for Transparency and Digital Human Rights backing it up, it has grown a lot and shaped up to be a very organized and thought through project.

TL;DR:

• Full rewrite
• More flexible and extensible
• Linux ready-made system and network hardened installation
• Written in python using twisted
• New Frontend

Try it out:

Try out the demo. It is pretty straight forward.

Help out:

As young project, Globaleaks can use some help fixing bugs. Just head to the wiki and read through it. It is pretty straight forward, and explains the modules, security concepts and set up instructions.

Globaleaks already has Debian and Ubuntu ready packages. An easy way to help out is to set up a  PPA for us on Launchpad.

Get in touch:

You can contact the Globaleaks team at info () globaleaks org or on IRC on #globaleaks at irc.oftc.net

Here are some screenshots of the new frontend

Congratulations you are using Tor

Receiver selection page

The submission receipt

Configuring a receiver

Configuring a context

In part 01 of these series, I showed why is it important to always define the language and the direction of all HTML content and not rely on the defaults: The content may get embedded in a document with different direction and be displayed incorrectly.

This issue is laughably easy to avoid: If you are writing the content, you are supposed to know in what language it is written, so if it’s English, just write <html lang=”en” dir=”ltr”> even though these seem to be the defaults. Nineteen or so characters that ensure your content is readable and not displayed backwards. Please do it always and tell all your friends to do it.

The problem is that you don’t only have to explicitly set the language and the direction, but, as silly as it sounds, you have to set them correctly, too. A more subtle, but nevertheless quite frequent and disruptive bug is displaying presumably, but not actually, translated content in a different direction. This happens quite frequently when a website supports the browser language detection feature, known as Accept-Language:

1. The web server sees that the browser requests content in Hebrew.
2. The web server sends a response with <html lang=”he” dir=”rtl”>, but because the website is not actually translated, the text is shown in the fallback language, which is usually English.
3. The user sees the content just like this numbered list, which I intentionally set to dir=”rtl”: with the numbers and the punctuation on the wrong side, and possibly invisible, because English is not a right-to-left language.

Of course, it can go even worse. Arrows can point the wrong way and buttons and images can overlap and hide each other, rendering the page not just hard to read, but totally unusable.

This bug is also an example of the Software Localization Paradox: It manifests itself when Accept-Language is not English, but most developers install English operating systems and don’t bother to change the preferred language settings in the browser, so they never see how this bug manifests itself. The site developers don’t bother to test for it either.

The solution, of course, is to set a different language and direction only if the site is actually translated, and not to pretend that it’s translated if it’s not.

Here are two examples of such brokenness. Both sites are important and useful, but hard to use for people whose Accept-Language is Hebrew, Persian or Arabic.

Here’s how the Mozilla Developer Network website looks in fake Hebrew:

Mozilla Developer Network website, in English, but right-to-left

Notice how the full stops are on the left end and how the text overlaps the images in the tiles on the right-hand side. This is how it is supposed to look, more or less:

Mozilla Developer Network home page in English, left-to-right

I manually changed dir=”rtl” to dir=”ltr” using the element inspector from Firefox’s developer tools and I also had to tweak a CSS class to move the “mozilla” tab at the top.

The above troubles are reported as bug 816443 – lang and dir attributes must be used only if the page is actually translated.

After showing an example of a web development bug from a site for, ahem, web developers, here is an even funnier example: The home page of Unicode’s CLDR. That’s right: Unicode’s own website shows text with incorrect direction:

The Unicode CLDR website, in English but right-to-left

The only words translated here are “Contents” (????) and “Search this site” (????? ???? ??), which is not so useful. The rest is shown in English, and the direction is broken: Notice the strange alignment of the content and the schedule table. A few months ago that table was so broken that its content wasn’t visible at all, but that was probably patched.

Here’s how it is supposed to look:

The CLDR home page in English, appropriately left-to-right

I tried reporting the CLDR home page direction bug, but it was closed as “out-of-scope”: The CLDR developers say that the Google Sites infrastructure is to blame. This is frustrating, because as far as I know Google Sites doesn’t have a proper bug reporting system and all I can do is write a question about that direction problem in the Google Sites forum and hope that somebody notices it or poke my Googler friends.

One thing that I will not do is switch my Accept-Language to English. Whenever I can, I don’t just want to see the website correctly, but to try to help my neighbor: see the possible problems that can affect other users who use different language. Somebody has to break the Software Localization Paradox.

Filed under: Firefox, Free Software, localization

Backstory

Every 3 months, we at Mozilla have to reset our LDAP passwords. The system helpfully sends the first reminder 2 weeks before your password expires, then the second reminder 1 week before your password expires and the last reminder 2 days before your password expires.

Sometimes time passes by faster than you know and you end up with a Locked out of LDAP account.

The 3 month LDAP password reset is such a large part of our lives that I propose it become a standard unit of measure for elapsed time.

Usage

Used in casual conversation:

Pat: Hi!

Jordan: Hi!

Pat: I haven't seen you before. How long have you been at Mozilla?

Jordan: I've been here for 6 LDAP password resets.

Pat: Oh, weird. I've been here for 7. Good to meet you! Would you like a banana?

Jordan: Would I ever!

Used in casual conversation on IRC:

<patbot> anyone use less? <corycory> i only use sass. it's the best. * riledupriley has quit (Quit: riledupriley) <patbot> :( <hugbot> (patbot) * r1cky has joined #casualconversationexample <r1cky> morning! <nigelb> r1cky: hai! <nigelb> Ah, it's nearly mfbt. <mtjordan> sure. been using it for 3 ldap password resets. <mtjordan> patbot: why do you ask?

Used in Bugzilla comments:

Jordan [:jordan] 1 day ago Comment 0 [reply] [-] Readonly mode causes the site to ISE. Pat [:pat] 1 day ago Comment 1 [reply] [-] I looked into it. Turns out we haven't used readonly mode in at least 4 LDAP password resets. I think we just need to add a fake authentication module. Easy peasy.

Used when joining a new group:

From: Pat To: some-group@mozilla.org Subject: Welcome Jordan to some-group! Hi all! I'd like to welcome Jordan to some-group! Jordan brings expertise that is invaluable. I'm excited! Yay! Jordan: Tell us about yourself! Pat From: Jordan To: some-group@mozilla.org Subject: Re: Welcome Jordan to some-group! Hi! I'm excited to join some-group! Hopefully I bring something useful to the table. I've been at Mozilla for 7 LDAP password resets, I like top-posting and I make a mean cold brew coffee. Looking forward to my first meeting! Jordan On Blah blah blah at blah blah blah, Pat wrote: > Hi all! > > I'd like to welcome Jordan to some-group! Jordan brings > expertise that is invaluable. I'm excited! Yay! > > Jordan: Tell us about yourself! > > Pat

Used in an email to everyone@ about departing:

Dear everyone! It is with sadness that I tell you I'm leaving as of next Friday. As you know, I've been with Mozilla for 32 LDAP password resets and frankly, I'm totally out of usable Sherlock Holmes story titles, so I'm off to new challenges. I will miss you all.

[Comments]

Sometimes web pages display brief warning boxes at the top with "learn more" links. The learn more link in a specific warning box should go to a page specifically about that warning with, in rough order:

1. screenshot of warning box
2. quoted full text of the warning (for searchability / search engine discovery)
3. detailed text answering:
   • how could have the issue occurred?
   • what should the user do to resolve the issue?
   • how can the user avoid the issue in the future?

E.g. the "Learn more ›" link in the yellow warning box in this screenshot:

links to: https://support.twitter.com/articles/82050-i-m-having-trouble-confirming-my-email which:

• Neither has screenshot nor text of warning
• Covers several topics unrelated to the warning
• Does not answer the above questions

And could be improved by linking to a specific page about this particular warning, containing the above points 1-3, and answering all three questions in point 3.

Related: Scary Twitter warning: "... removed the email address from your account...

In response to my post earlier this week on Tinderbox’s end-of-life, reader Carsten Mattner asked:

Reading [your post], I couldn’t figure out what replaced Tinderbox for the Mozilla builds. What feeds tbpl? Does Mozilla not use Tinderbox to build continuously?

When I left Mozilla in 2007, there was a Release Engineering project in progress to actively replace Tinderbox (Client) with buildbot. So in short, no, Mozilla does not use Tinderbox Client to drive its continuous integration builds, and hasn’t for some time.

Do they still use buildbot today?

I didn’t know the answer to that question, so I tracked down Coop on IRC, who graciously gave me a few minutes of his time to answer exactly that.

He said:

• Mozilla currently uses “95% buildbot, with 5% Jenkins for random small projects”
• There are multiple buildbot masters that drive the buildbot clients
• Unlike the out-of-the-box buildbot master setup, the masters query a job scheduling database instead of monitoring source control for changes themselves; they then report their results to a database, which tbpl (and other services) use to generate their reports/dashboards; the buildbot master waterfall pages aren’t accessible to the external world (which makes sense, because they include unsecured administrative functionality1)
• There are about 60 masters right now, but Coop said “number keeps growing though, so we need to rethink the whole solution”

So there’s your answer, Carsten!

_______________
1 A long standing criticism of mine, among others?

I’ve got a Beer & Tell to give about alembic. Alembic is a migration tool that works with SQLAlchemy. I’m using it for database migrations with PostgreSQL.

So, here’s what I want to say today:

• Written by SQLAlchemy wiz Mike Bayer
• Here’s the tutorial. Socorro is now using alembic in production with SQLAlchemy 0.6.x. I’m hoping to get us upgraded to 0.8.x soon.
• Here’s what running an upgrade in production for Socorro looks like. Awesome right?
• Here’s what a migration looks like.
• Here’s a configuration file.
• Generating a migration from the command line might look something like:
  alembic revision -m "bug XXXXXX Add a new table" --autogenerate

The most difficult thing to deal with so far are the many User Defined Functions that we use in Socorro. This isn’t something that any migration tools I tested deal well with.

Happy to answer questions! And I’ll see about making a longer talk about this transition soon.

cross-posted from the Webmaker blog

We use Bugzilla to work open and get stuff done

Webmaker, like many Mozilla projects, uses an issue tracker called Bugzilla for filing tickets and getting stuff done. These two new pages provide tips and tricks for filing bugs, and for getting the most out of Bugzilla:

1. Bugzilla for Webmaker — the best place to start. How to file a Webmaker bug, plus simple tweaks for making Bugzilla easier to use.
2. Bugzilla for Webmaker: PRO TIPS – for digging deeper. How to make it easier for users to file tickets, tagging, searching and tracking bugs, Frequently Asked Questions and more.

Anyone can create, comment or contribute to a ticket

We work open. Webmaker is an open source, non-profit project powered by a global community of friendly humans like you. Anyone can create a ticket, comment on a ticket, and contribute. Just because it’s called a “bug” doesn’t necessarily mean there’s something wrong. It could just be a to-do, or a suggestion. All your tickets are welcome — don’t worry if you’re doing it right. We’re a friendly community, and we want your ideas!

What: Mozilla Open Web Open Mic
When: May 22, 6-9pm ET.
Where: Mozilla Toronto, 366 Adelaide St. W, 5th Floor

Mozilla Open Web Open Mic (OWOM) is back for May. Put on by the Mozilla Toronto community, OWOM features a science share exploration and lightening talks (5 min). April’s event had a great turnout (50-60 people) and included a variety of content from WEBVTT, to MakerFaire, to my talk Building for Mobile Web Compatibility.

The call is currently open for science share participants and speakers. Sign up at
https://mozillianstoronto.etherpad.mozilla.org/owom-may-2013

Interested in attending? Sign up now at
http://owommay2013.eventbrite.ca/#

Tagged: mozilla, mozilla community, toronto

In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard.  I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox.  I think I was a bit offended at the simplification, but time has proven him right.  I’m certainly no hedgehog.

I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both.  And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.

We all need to define ourselves to others. It helps us be understood, and hopefully valued.  Labels can be useful for that. We also, even more, like to label others.  It helps us simplify our approach to them.  If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much.  The more people we interact with, the more important these shortcuts are.  Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day).  And the best at these roles are those who use a different labeling system than their peers.  Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.

Labels are useful and practical in the short term.  And I don’t know how one could run a large HR department without them.  But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures.  Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.

As I write this, I realize that I feel quite strongly about this topic.  Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label.  Much waste ensued.  Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah.  I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph.  And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.

Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents.  Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.

Back in March, we kicked off the first in hopefully a series of train-the-trainer (TTT) events for webmaking.

The idea is to run events that train people who go on to train others how to teach the web. We focused on practicing an open and participatory ethos, adapting lesson plans, and facilitating events.

This is a post to share what we did and encourage people in designing their own train-the-trainer events.

How to run a Webmaker Train the Trainer

Our prototype, the Reps Training Days, ran for four days in Athens, Greece with 40 Reps from around the world. The agenda was based on Laura Hilliger’s research and insights on successful TTT program and on Allen Gunn’s participatory event methodology. It was made possible by the amazing Mozilla Greek community.

Our participants were Mozilla Reps, a fantastic ambassador program with some of the most active and thoughtful Mozillians. Reps have been early adopters and innovators with Webmaker. They organized nearly 50 events during last year’s Summer Code Party and are leading the way in developing tools, tutorials, and localization for Webmaker. It seemed like a natural fit to run our first TTT with them.

1. Participate in a Webmaker event

The first day of Training Days was spent observing and participating in a Hive Pop-Up, organized by Hive Athens. This was an opportunity for the participants to experience a webmaker event firsthand, to see the tools and activities in action, to learn about the logistics, and to understand the vibe.

We then circled up to discuss what we saw. Participants shared their reflections on what worked well at the pop-up and what they would change if they did their own.

2. Build the training agenda

Then we opened up the training days properly. While we had topics in mind we wanted to hack on together, it was more important that everyone in the room thought about what they want to learn or discuss. So we had an agenda brainstorm.

To do this: we split into groups for 3 people. On post-it notes, we wrote down topics. 1 topic per post-it and the encouragement to write it as concretely as possible.

Then everyone pasted the notes on the wall. We read them all and then clustered them by themes. This collaborative board formed both critical event documentation as well as agenda fodder for the coming days.

3. Teach someone something

To warm up to the idea of teaching, we then got into pairs. The task: teach someone something in 5 minutes.

One person would go and then switch. Even if you knew what was being taught, you were encouraged to play a good learner, asking good questions and prompting the teacher.

After this exercise, we circled up and discussed what we observed from this experience. For many, it was a great way to think about how to explain something clearly, using metaphors and knowledge building blocks. It helped bring people into a teaching mindset.

4. Make a learner profile

Now that we’ve been thinking about teachers and learners, we made small groups and hacked together a learner’s profile.

This goal of this activity was to think about who our learners are. We used Webmaker tools to make these profiles, which was also a fun, maker-y way to be introduced to these tools. Participants were encouraged to think about real people they want to teach.

5. Hack an event invitation

After we’ve made our learner profiles, we thought about the kind of event we wanted to run. Most of the participants have already organized Webmaker events in the past, so there was already some familiarity with the format.

Nevertheless, it was helpful to hack together an event invitation. The idea was to think about your target learner and to make an invitation that would speak to them. Again, we used Webmaker tools to quickly pull these invitations together on the web.

6. Deep dive into lesson plans

With a learner profile, an event invitation and some familiarity with Webmaker tools, we then introduced the hackable kits. These are remixable lesson plans that help mentors, trainers, etc. to teach the web. The idea is that they are adaptable to different contexts and that people can share new ways of teaching in a shared format.

Participants poked around in the kits and asked questions. We also did some fun icebreakers so they could see the activities in action and get some energy going.

7. Playtest lesson plans

Now came the fun part. We had to plan for a real live event the next day. So participants got into groups of five with one group facilitator.

They had to design a four-hour agenda for local youth. Using three recommended activities from the kits, they adapted the lesson plans. Then they walked through a script for the next day, including having people role-play as learners. It was a lot of fun to see and a great way to prepare for the big day.

8. Put training to practice at a live event

So with some nervousness, we got ready for the live event. About a hundred youth were coming. We split into different rooms, each group of five trainers getting about 20 learners.

While there were the inevitable challenges (the internet is down! one kid won’t listen!), the Reps did a terrific job. They rolled with their scripts, adapting them as they saw what was working. They also taught well in smaller pairs with their learners, sometimes adding new challenges or tools to fit their needs.

It was a beautiful and fun thing to see. All the training the days before paid off: the youth had a lot of fun and so did we.

9. Reflect on event, lessons learned and where from here

We ended the event with a closing circle. We talked about what we saw that day, what worked well, what didn’t. We each shared one thing we appreciated about the experience, and what we’re excited about doing next.

With that, we headed out into the city to enjoy the day and the rest of our time together.

10. Go forth and teach!

Each participant left the Training Days with a local plan. It was a short list of possible collaborators in their hometown, a date for a small team huddle to bring those people together, and then a date for a larger Webmaker event to organize with their new collaborators.

We also started interest groups in topics like localization and offline tools. And now, a few months later, the participants from Training Days are now “Webmaker Super Mentors”, mentoring people in an online course to learn how to teach the web.

In the coming months, we hope to keep remixing and improving these agendas, as well as work with people who are interested in TTT in their own cities or communities.

Let us know if you’d like to get involved! #teachtheweb

Firebug 1.12 alpha 6 introduces one new feature called simply: Use in Command Line

This feature allows referring various page objects (HTML elements, JS objects, network requests, cookies, etc.) from within Firebug Command Line.
The user can also use object's properties in JS expressions.

See issue 6422 for more details.

This post explains the feature in detail and also asks for feedback.

How it works

As depicted on the previous screenshot the feature is represented by a new context menu item called Use in Command Line. This item is available for various objects (in various panels).

The action is simple: an expression $p is inserted into the Command Line if you execute the command. It's a variable that refers to the clicked object. You can also use the variable to access any property of the object.

What happens on the screenshot:

• The DOM panel shows an object person implemented on the page.
• The user clicks on the person's value (the green right hand part) and executes Use in Command Line.
• Command Line popup is opened within the DOM panel (so, the user doesn't have to leave the DOM panel).
• $p expression is inserted into the Command Line (and the command line automatically gets focus).
• The user presses the Enter key to evaluate the expression.

Note that the person object implemented on the page looks as follows:

var person = {
    name: "Bob",
    age: 38
}

If you want to access properties of an object just use dot notation. You can do following in our example.

$p.name

See, even the auto-completion works as expected!

Supported Objects

The feature is implemented for various objects across all Firebug panels. Here is a list of those objects.

• Any JS object (even functions etc.)
• HTML elements
• CSS rules and properties
• Cookies
• Network requests

Call for Feedback

All objects accessible through the $p variable are coming from the page content except of network requests and cookies.

We are actually logging nsIHttpChannel for network requests and nsICookie for cookies. So, the object comes from chrome (privileged scope) and isn't accessible in the page content. This way, the user has more info, but it could be confusing since the user could expect that the data are actually accessible from the page content (and Firebug is for page content debugging).

Possible options:

• Do not implement the feature for network requests and cookies
• Implement the feature only for XHRs (and show the real XMLHttpRequest instance) and cookie (coming from document.cookie)
• Keep it as it is
• Anything else?

What do you think?

Also, would you like to refer more objects at the same time? Something like having more variables (a history) available: $p0, $p1, $p2, ...

How would you expect it to be working?

Thanks for any feedback!

Mozilla brings power of the web into ordinary people's hands. Every day I spend countless hours working with volunteer communities around the world to translate Firefox web browser. Reading Sudheesh Singanamalla's blog post about his encounter with a farmer in rural India was such a touching experience.

A Localization journey - A Farmer's tale - A Delightful Experience

It was on my way back in a cramped out bus, travelling researching about language changes and variations within the state of Andhra Pradesh, that I sat next to a man, quite old.

Me : What do you use in the internet? How do you talk to your son?
Old man: I go to Rajat's Net Cafe nearby by house and then talk from there on Google (meant Google+)
Me : Do you know how to read English and understand which button to click and so on?
Old man : Oh, i don't know English, but i use it in Telugu. The shop guy Rajat has seen me since he was small, so after my son went to Delhi, he separately bought a Telugu keyboard so that i can be using the keyboard.
Me: Okay, but then how do you read the information on the computer screen? Isn't that in English?
Old man : (Laughs) Don't you know, there is this software something called Firefox, it is in Telugu.
Me : Really? Can you tell me how the software looks?
Old man : You should know more, you're an engineering student but if you ask i'll tell you, its a small thing like this earth picture but a small cat , orange in colour is holding it.
Me: (smiling crazily) You know how to use it in Telugu?
Old man : Yeah, its not hard, I know how to read Telugu and also know how to use mouse, so clicking gets me the job done.
 

Yesterday, Google organized an invite-only summit for mobile web and tools developers. As an engineer working on Firefox Developer Tools, I was invited to be on a panel about mobile testing and tooling. This is my attempt to write down my answers in hope they’ll be useful for someone out there. I suggest reading them as separate, individual mini essays.

Read it on Medium

As engineers, I believe the way we approach a problem is as important as the code we write. This is especially relevant in the context of UI engineering where design is such a vital element.

Unfortunately, it seems quite hard to find good content about everything that happens around us and inside our heads when we are building user interfaces. This is what The Layout is about.

My intent is to create a space for high quality content discussing the principles, mindset, and practices that I believe shape the craft of UI engineering. It is meant to be a shared space with many voices—so, expect some awesome guest authors.

I’ve just posted the very first article, Mind the Gap. My plan is to publish a new article every other week-ish. For now, subscribe to the RSS feed or simply follow The Layout on Twitter or Google+ to get future updates.

I really hope you enjoy it!

With my chapter for the upcoming Smashing Book 4 done and talking about “The Vanilla Web Diet” and some workshops in the making I thought it is a good idea to show in an example how to make a seemingly good solution better by rethinking it with the principles of the vanilla web diet in mind.

The solution I am targeting is the image swivel effect that was posted a few days ago on CSS tricks. I sent my solution to the author and he was very interested in getting more information as to the why. The effect as it stands works and does the job to inspire people to play with it. The comments showed that where lots of developers had a go at creating their own solutions fixing some of the issues I am about to cover here. My favourite probably is Eduardo García Sanz’s Pure CSS solution which to me is a good plan to achieve an effect like that if you don’t need touch support or keyboard access.

Check out this Pen!

Before I get accused of “hating” – the code is OK as a demo to get creative juices flowing but it has many issues that would show up when used in production. It is also mouse-dependent and doesn’t work on touch devices. Therefore I’ll start by stating what I find troublesome about the published solution and then explain how to approach the problem to make it as simple and maintainable as possible. I also add support for mouse, keyboard and touch access and try to achieve the effect whilst not blocking people out.

If you prefer to see this as a screencast, here is one I recorded explaining the ideas, the issues I found with the original code and how my solution works. This is live and unscripted.

How much markup do we need?

Let’s start by looking at the solution that is shown in the CSS tricks article.
The HTML is the following:

<div id="faces"> <div id="face-area"> <div id="image-1" style="display: none;"> <img src="/images/look-left-3.jpg"> </div> <div id="image-2" style="display: none;"> <img src="/images/look-left-2.jpg"> </div> <div id="image-3" style="display: none;"> <img src="/images/look-left-1.jpg"> </div> <div id="image-4" style="display: none;"> <img src="/images/look-center.jpg"> </div> <div id="image-5" style="display: none;"> <img src="/images/look-right-1.jpg"> </div> <div id="image-6" style="display: none;"> <img src="/images/look-right-2.jpg"> </div> <div id="image-7" style="display: none;"> <img src="/images/look-right-3.jpg"> </div> <div id="the_faces_overlay"> <div class="the_faces" data-number="1"></div> <div class="the_faces" data-number="2"> </div> <div class="the_faces" data-number="3"></div> <div class="the_faces" data-number="4"></div> <div class="the_faces" data-number="5"></div> <div class="the_faces" data-number="6"></div> <div class="the_faces" data-number="7"></div> </div> </div><!-- END #face-area --> </div> <!-- END #faces -->

Warning sign #1: Repeated HTML structures without logical connections

This is a very common mistake I see when starting an effect like that. We create something that contains the content and then something that gets acted upon to show the effect. Thus we lose the benefit of already interacting with the parent element and using event handling to find out where we are. I guess historically this is based on “CSS only solutions” that needed that kind of separation as you could not calculate or detect mouse position in CSS.

As we create two separate sets of markup for an effect we need to find a way to connect the element that was interacted with to the one we want to show. This means adding IDs to all the elements, classes to all the elements we interact with and a data attribute to tell which of the images to show. This is bad for maintainability. If we add an image, we need to also add an element to interact with. Great code is catered to making maintenance as easy as possible. Here we have a lot of dependencies to deal with when adding or removing an image.

Warning sign #2: Lack of semantic markup
The other gripe I have with this HTML is that it means nothing at all. As the order of the images is important, the right HTML construct to use here is an ordered list.

Warning sign #3: Lack of alternative content
Another big HTML mistake is adding images without an alt attribute. This means that screenreader users would get the file path of the images read out to them. Either provide a sensible alternative text or add a alt=”” to hide the image from screenreaders.

Warning sign #4: Dependency on the number of elements
One big warning sign to me here is that our effect is dependent on the number of images in the widget and that we need to have the data attributes and the IDs maintained together although they are on different elements.

The more elements we add means the more IDs we need to maintain. This is not what coding is about. Computers are good at calculating things for us.

Warning sign #5: Empty elements and inline styles

Whenever I see inline styles I know something went wrong. There is no point in them and if ever they should only be generated by code, not by humans. The same with empty HTML elements: you probably did some extra work that is not needed. HTML is there to contain content or provide interaction. If you have a lot of empty DIVs without an obvious templating use case, something went wrong.

Giving no power to CSS

The CSS of the solution is not much, and it doesn’t do much either. This is a shame seeing how much easier it is for a visual maintainer to change CSS rather than changing JavaScript.

body { background: #333 } #faces { height: 333px; width: 500px; margin: 0 auto; border: 8px solid white; } #face-area { height: 500px; width: 333px; position: relative; } #the_faces_overlay { position: absolute; width: 500px; top: 0; left: 0; } #faces .the_faces { height: 333px; width: 14.2857143%; float: left; margin: 0; padding: 0; }

Warning sign #6: CSS dependent on the amount of elements

The glaring issue here is the “width: 14.2857143%;” which is calculated by dividing 100% into seven parts. This means that if you delete an image from the HTML, you also need to change the CSS width here. You should never be dependent on the amount of elements in your CSS, as those are prone to change. In this case especially there is no logical way to find out why this is the width. CSS calc() can at least make that obvious but in general it is a bad idea to create look and feel that is tied to a certain amount of elements.

Goldfish jQuery

The jQuery code to make the effect work is very short:

// Reveal the "center" image var centerImage = $("#image-4").show(); // Bind hovers to each column $(".the_faces").each(function() { $(this).on("mouseover", function() { $("#image-" + $(this).attr("data-number")).show(); }).on("mouseout",function() { $("#image-" + $(this).attr("data-number")).hide(); }); }); // Reset center image $("#face-area").on("mouseleave", function() { centerImage.show(); }).on("mouseenter", function() { centerImage.hide(); });

It is, however, very demanding to the browser. Slowing down a browser can be done in many ways – the most damaging ones are heavy computation, accessing the DOM and lots and lots of event handling. The latter two is what we do here.

Warning sign #7: lack of data caching

We loop over all the elements with the class “.the_faces” and add a mouseover and mouseout handler to each of them. Every time these get fired, we read an attribute, create a string with it and access an element that has the ID of the string and show or hide it. Showing and hiding using the jQuery methods is another access to the DOM as it manipulates the display style property. We show and hide the “center image” upfront and also on another event hander on the overall parent element.

If we were to add touch and keyboard handlers we’d triple the amount of assigned event handlers as we apply them on each image.

I call this Goldfish code – we keep asking the browser for things we should already know. The widget interface we have here is static HTML - there is no loading of content, no changes in it. Therefore there is no point in continuously reading out what the data-number attribute is and ask the browser to find the element with a certain ID. Caching results is a very simple thing to do and the performance benefits are amazing.

Rethinking the solution the vanilla web diet way

I approached the solution by looking at what we need to do here:

• We have a widget of a certain size with images in it
• We have an unknown amount of images – it should be dead easy to remove or add one or replace them all
• Moving the mouse over the widget should loop through the images, also touching the widget should do so and it would be nice to be able to flip forward and backward with the keyboard
• Should things not work out it would be nice to have an display that still makes sense

The HTML - we don’t need IDs or data attributes

<a href="/productpage" id="rollover"> <ol> <li><img src="pics/IMG_0518.jpg" alt""></li> <li><img src="pics/IMG_0517.jpg" alt=""></li> <li><img src="pics/IMG_0516.jpg" alt=""></li> <li><img class="current" src="pics/IMG_0515.jpg" alt=""></li> <li><img src="pics/IMG_0519.jpg" alt=""></li> <li><img src="pics/IMG_0520.jpg" alt=""></li> <li><img src="pics/IMG_0521.jpg" alt=""></li> </ol> </a>

We should link this to something – after all a beautiful effect like that should react in some sale or deep-dive, right? Good thing is that in HTML5 links can contain other elements. So all we add is a link. This automatically gives us keyboard access to the widget – something otherwise we’d have to create by using roaming tabIndex.

As the order of the images is important, an OL is the right element to use. Each image has an empty alt attribute to ensure there is no hassle with screenreaders. Instead of defining which image to show as the first one in our JavaScript we keep this maintained in HTML, too, by adding a class of “current” to the image.

Showing and hiding with CSS

body { font-family: arial, sans-serif; } #rollover.js { display: block; margin: 2em; z-index: 3; position: relative; height: 270px; width: 200px; cursor: none; } #rollover.js img { width: 100%; position: absolute; top: 0; left: 0; visibility: hidden; } #rollover.js img.current { visibility: visible; }

As our functionality is dependent on JavaScript, our styling should be, too. This we can achieve by adding a “js” class to the element when JavaScript is available and only apply the styles when needed. This CSS gives the widget a fixed size and positions all the images stacked inside it.

Instead of doing a hide() and show() in JavaScript, all we need to do is to apply a class of “current” to the element we need to show. All the hiding and showing is thus done in CSS which means that in the future we’d want to do other visual things with the “shown” and “hidden” images, all we need to change is the CSS.

(function(){   if (document.querySelector) {   var rollover = document.querySelector('#rollover'); rollover.className = 'js';   var images = rollover.querySelectorAll('img'); var all = images.length; var width = rollover.offsetWidth; var ox = rollover.offsetLeft; var boundarywidth = width / all; var current = 0; var x = 0; var index = 0; var touched = false;   var setcurrent = function(index) { if (images[index]) { images[current].className = ''; images[index].className = 'current'; current = index; } };   var findindex = function(x) { index = parseInt((x - ox) / boundarywidth, 10); if (index !== current) { setcurrent(index); } };   rollover.addEventListener('mousemove', function(ev) { if (!touched) { findindex(ev.clientX); } }, false);   rollover.addEventListener('touchstart', function(ev) { touched = true; }, false);   rollover.addEventListener('touchend', function(ev) { touched = false; }, false);   rollover.addEventListener('touchmove', function(ev) { if (touched) { findindex(ev.changedTouches[0].clientX); ev.preventDefault(); } }, false);   rollover.addEventListener('keydown', function(ev) { var key = ev.char || ev.key || ev.which; if (key === 37) { index = index - 1;} if (key === 39) { index = index + 1;} if (index < 0) {index = 0;} if (index > all - 1) {index = all - 1;} setcurrent(index); }, false);   if (rollover.querySelector('.current')) { for (var i = 0; i < all; i++) { if (images[i].className === 'current') { current = i; break; } } } else { setcurrent(current); } } })();

Quite longer than the jQuery, but bear with me as this does a lot more and in a much less demanding fashion. We wrap our code in a closure to makes sure we don’t leave any nasty globals behind. That should always be the first step.

Then we test if the browser supports document.querySelector. This is the standard answer to jQuery’s $() and is supported by lots and lots of great browsers. It is not supported by old and outdated browsers, which is why it is a good idea to test for it. This means that old Internet Explorer versions will not get the effect but instead they get the images as a numbered list (as we made the CSS dependent on a class applied with JavaScript). This is good, as it means we don’t need to test on these old browsers, which is hard to do and frankly a waste of our time.

We get a reference to our rollover widget using document.querySelector() and add the “js” class to it. This hides all the images and sets up the look and feel of the widget – all maintained in CSS. No need to loop through a lot of elements or use inline styles to hide them.

Next we get references to all the DOM elements we need and calculate what we need to find out what to show when the mouse cursor or the finger is on a certain part of the widget.

First we get all the images and store them in images. This will not change while the page is open, and querySelectorAll() gives us references to all of them. We store the amount of images in all to compare against later on.

Next we do the thing dynamically that the original solution did by hand – calculate the width of the different strips of the interaction that shows and hides images. We do this by reading out the offsetWidth of the widget as it is defined in CSS, so we don’t know and don’t want to hard-wire any widths in our JavaScript. We find out how far left the widget is in the browser by reading the offsetLeft property and store that in ox. Then we calculate the width of the interaction boundaries by dividing the width of the widget by the amount of images and store that in boundarywidth.

This makes the widget flexible to change any time the CSS changes or the amount of images does. If you remove or add an image, the width of the boundaries is calculated newly. No need to change the CSS to reflect that width. We made this now maintainable simply by adding or removing list items.

We define the current shown image index as 0, preset an x variable as 0, define the current index of the detected movement as 0 and set touched to false.

The index will be the index of the image to be shown at a certain point in the interaction. The index of the currently shown one is be stored in current, x will be detected position of the mouse or finger on the screen and touched defines if the screen is currently being touched or not.

The setcurrent() function hides the last shown image and shows a new one by shifting the “current” class from one to the other. It then stores the new image index in current. This is a very simple way to show a new state in a collection of things that can only show one at a time. No need to ask the browser which one is visible when we can store this in a variable like current.

The findindex() function converts the detected horizontal position of the mouse cursor or the finger of the user into an index of our image array. All you need to do is to subtract the left position of the widget itself and divide the value by the boundarywidth. Convert it to an integer and compare it to the current index and if it differs, call setcurrent().

All that is left is to assign the event handlers to make the magic happen. The first is a mousemove listener on the widget that calls findindex() when no touch happened. The current horizontal mouse position is stored in clientX of the mousemove event.

Touch interaction needs to be initiated (at least in Chrome in my testing here) so we set the Boolean of touched to true when a touchstart happened and to false when touchend was detected.

When a user moves a finger over the widget the browser fires the touchmove event and the current horizontal position is stored in the clientX property of the changedTouches array. We only detect the first finger in this case.

Keyboard detection doesn’t give us a position on the screen, so all we do is manipulate the image index directly. We listen for a keydown event and check the code of the key that was pressed. If it is the left arrow we subtract one from the current index and in the case of the right arrow we add one to it. We ensure that the index stays in the allowed limits and call setcurrent().

The last thing to do is to show the current image. If there is one with the right class in the HTML we need to find out its index and we do that by looping over them until we find the right one. If there isn’t any we just apply the current class to the first image (as defined at the start of the script).

Many solutions to the same idea

I hope this gives you an idea of how to approach an effect like that when you want to put it in production. There are of course other ways of doing it, but I wanted to ensure a few things that get very often forgotten:

• The whole effect is now generated from the HTML, so all you need to do to create a new swivel is add other images
• The whole look and feel is defined in CSS and you can resize the widget without having to worry about the size of the different boundaries
• It can be used with a keyboard, the mouse or on touch devices
• The DOM interaction is kept to an absolute minimum which means the performance on low spec devices is much, much better
• There is no jQuery dependency

As Digital Preservation is part of the agenda of the US Library of Congress, they're doing a workshop on Software Preservation next week, and Mozilla was invited as an expert group. Otto de Voogd and myself are in the delegation going there (I'll be roughly in the Washington, DC, area from Saturday until June 2) for Mozilla - and the text below is a guest post by Otto with questions that we would like some feedback on so we can represent the Mozilla community as well as possible:



On the 20th and 21st of May the Library of Congress holds a workshop on the topic of preserving software.
Otto de Voogd and Robert Kaiser will be representing Mozilla, putting forward our viewpoint as custodians of a codebase with a significant heritage and importance.

Many questions and thoughts arise. Here's an overview of ours; we look forward to feedback.


- Should archivists keep source codes or executables or both?

Executables and source code are both valuable. Executables are valuable because the source code is sometimes not available, or perhaps the build tools are not, and setting up a build environment for older code can be a difficult and complex thing.

Source is valuable to determine how a program works. It also makes it possible to reuse code and algorithms, especially, but not only, in the case of open source software.


- Preserving documentation.

Preserving documentation that goes with software, seems logical.
Would this need to go as far as preserving discussion threads and entries in bug trackers?


- Preserving environments/platforms.

It seems obvious that without preserving an environment in which the software can run, it is going to be impossible to experience the software.
Preserving such an environment should therefor be part of the software preservation effort.

To avoid the physical constraints imposed by preserving old hardware (which would be a preservation effort in its own right), a solution would be to build virtual machines and emulators.
As hardware capacity constantly grows, running virtual versions of older hardware should generally be feasible.

To fully recreate an environment we'd also need to preserve the operating systems and other software tools that the preserved software needs to run.
Those being software themselves would logical already be included in any software preservation effort.

Preserving documentation concerning environments, would also be required.
To build virtual machines and emulators it would be helpful for hardware makers to make technical specifications available. One could envision this to become a legal requirement at least for older hardware.

Can we imagine a world where web based emulators would allow an online digital library to serve users worldwide? Users who would be able to run old software in emulators running in their browsers...


- Is everything worth preserving, if not how does one go about selecting what is worth preserving?

Does one need to preserve every version of software, just the last version or all major releases? What about preserving software that has not spread widely. Would there be some threshold, or some other criteria?


- How does one index software and search the library?

There will be a need to gather meta data about software and the preservation of documentation as we already mentioned. This meta data and documentation could serve to populate an index enabling for instance the search for particular features.


- Can software preservation help in making code reusable?

If there are good ways to actually find relevant and useful code, this could lead to more reuse not only of actual code, but also of algorithms and concepts.
It may also become a valuable source for students who wish to learn about actual implementations of software solutions.

At the very least a minimum of meta data, such publication dates, copyright owners and licenses should be available to determine how certain code can be reused.
In particular for open source software we believe that software libraries should strive make it available without restrictions.


- Preserving data formats.

The software preservation effort should also include an effort to preserve data formats. Including technical descriptions of those formats and the tools to read, write and edit those formats.


- Can software preservation help in the discovery of prior art?

We believe it can, and as such preserving old code could be a great tool in preventing the repatenting of existing software concepts.

Of course we believe that software patents shouldn't exist in the first place, as software is already covered by copyrights, but at the very least prior art is a good avenue to prevent some of the worst abuse of software patents.


- How do copyrights affect software libraries?

A lot of software is licensed to be used on a particular piece of hardware or only available via subscription. How does this affect software libraries? Should there be exceptions like there are for traditional libraries?

In the life cycle of software, the commercially exploitable time is limited, likely anything older than 10 years no longer has any commercial value.
Maybe copyrights on software should be significantly reduced to something like 10 years, which is more than enough to cover the commercially exploitable timeframe of the software life cycle.

Such a limit would greatly enhance the work of software libraries, increasing availability and ease of access as well as removing a lot of the red tape involving requests for permission to keep copies.


- What about software as a service?

And what about software as a service, where neither the source code nor the executables are ever published? How can something like Gmail be preserved, when neither the service's code nor the environment is available to the public?


- Preserving "illegal" or cracked copies?

What if a copy of a piece of software comes from an illegal source? A cracked version with modifications maybe? They have value in themselves as they are a cultural expression.

What if such an illegal copy is the only copy still available? Would it make sense to preserve that too?

I sat in on three sessions at Google IO 2013 yesterday.

Memory Lane with Chrome Devtools and GMail was the first.

The presenters showed off their Heap Tracking Profiler and Memory Tracking tool in the Timeline and explained how to use them to track down a leaky DOM node. It was a practical application of how to use a developer tool to solve a particular problem.

One interesting takeaway that surprised the presenters during their research: Always allocating more memory (caching) as a way to improve performance in a large application like Gmail is not a panacea for slow performance. Having a large heap space actually slows down the garbage collector and your performance suffers. It’s a fine balance.

What surprised me was how they analyzed their problem by tracking a user with a known high memory problem for three days. The Google team constantly monitors their apps’ performance via the window.performance API and can single out hotspots in the population.

The next talk I sat in on was about Chrome Apps. The presenter, Erik Kay showed off some of the “Immersive” experiences of Chrome Apps and the different ways they could interact with the hardware on the Chrome Book. The talk included a demo of a small thermal printer being hooked up and controlled over USB which garnered some applause.

The Chrome Web Store lets you buy apps for Chrome.

The only real mention of Android was that they were using PhoneGap and Cordova to provide their compatibility layer. Same for IOS. There will be compatibility issues with deploying on iOS but it seems surprising that they would pursue this completely separate technology for Android. Surely they could ship a full version of the Chrome Runtime and deal with hardware incompatibilities directly.

The questions from the room were interesting. One man (not a Mozillian) asked about WebRTC compatibility across the different platforms, pointedly repeating the question of whether or not he’d be able to use WebRTC in an app on iOS. Only when their WebView supports it.

Another man asked something about interoperability between B2G and ChromeRT. Erik said that there is “no forcing function yet to drive standardization”.

I think my biggest takeaway from this talk was that people wearing Google Glass look like dorks.

My second biggest takeaway was that I was very surprised that there was zero mention of the Google Play Store for Chrome Apps.

Last talk I attended was a Fireside Chat with the Blink Team. While I was expecting an actual fire and was disappointed there wasn’t one, the team bravely took questions from an audience confused about feature-detection, unprefixed CSS and market fragmentation.

Dan Buchner asked the panel something about standardization and I felt a little badly for the Blink team who had a whole chunk of slides talking about how they’re going to be good citizens. (If you want to participate, you should join blink-dev@chromium.org.)

I was interested in ChromeStatus.com/features which shows a spreadsheet of features in-progress. Time will tell how their Intent to Implement and Intent to Ship broadcasting will work from an Open Source point-of-view, but they are currently claiming that a third of their intents to implement are coming from outside of Google.

I wanted to meet Paul Irish after the talk but Steven Shankland showed up and pushed me out of the way. When he was done I did get to meet him, but I think Buchner had made him angry or something. Maybe he was just tired. I dunno.

If you have been wondering about status for the transition to mozbuild as a replacement for makefile infrastructure, a source is becoming available. People involved with the conversion have been meeting bi-weekly on the topic – details and content can … Continue reading ?

So lots of people are having trouble disabling safe mode using my earlier instructions and I discovered it is because of problems overlaying the dialog. So here are some new instructions that should work for everyone.

First, create a disablesafemode directory in distribution/bundles where the Firefox executable is located (you'll probable have to create the distribution and bundles directories as well). Then create a file called chrome.manifest that looks like this:

content disablesafemode content/ override chrome://browser/content/safeMode.xul chrome://disablesafemode/content/safeMode.xul

Then create a subdirectory called content. In that directory, create a file called safeMode.xul that looks like this:

<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="chrome://global/skin/"?> <dialog xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" id="safeModeDialog" buttons="," ondialogcancel="closeFirefox();"> <script type="application/x-javascript;version=1.7"> <![CDATA[ function closeFirefox() { Components.utils.import("resource://gre/modules/Services.jsm"); Services.startup.quit(Services.startup.eForceQuit); } ]]> </script> <description> Safe Mode has been disabled. </description> </dialog>

This will cause a dialog to be shown instead of the safe mode dialog that when the user closes, will simply close Firefox. If you'd prefer to show no dialog at all, change ondialogcancel to onload.

I've tested this a lot, and it is working for me. Please let me know if you have problems.