On analysts and reality

Posted on April 5, 2010 by Justin Dolske

Saturday: “Piper Jaffray Senior Research Analyst, Gene Munster, on Saturday said he believes Apple sold between 600-700 thousand iPads on the first day.”

Monday: “Apple announced this morning that they had sold over 300,000 iPads on the first day.”

Posted in PlanetMozilla, Technology | Comments Off

Fun hack of the week

Posted on March 17, 2010 by Justin Dolske

I recently wrote an interesting solution to a problem, and thought I’d share…

The Problem.

I have multiple DOM nodes, scattered across multiple pages and windows, which I may want to modify in the future. Code already runs once per node (so that’s free), but I want to make future updates fast and avoid dealing with document lifetime issues… The first rules out wading through the DOMs of a thousand tabs, and the second rules out simply storing the nodes in some JS array (which risks leaks/bloat by keeping long-lived references to content DOMs).

Specifically, this problem is for bug 550293, where I’m keeping the crashed-plugin UI in sync across multiple tabs when submitting a crash report.

The Solution.

[I'm sure there are multiple solutions, but this one fit in well with the other things the code was doing...]

First, I decided to drive things by notifications and observers. The code that was already running (to initialize the crashed-plugin UI) now adds an observer for each instance. To update them, I just fire a notification when needed.

But I don’t want the observer service causing leaks by keeping the observers and nodes alive, so when adding the observers, they’re added with a weak reference (see nsIObserverService.addObserver()).

Oh, but now there’s a new problem — if nothing is holding a strong reference to the observer, it will be garbage collected at some random point in the future. [This can be a confusing bug; the observer works fine if you trigger it quickly enough, but if you're slow in testing it will seem to randomly fail!]

So, here’s the clever bit… To keep the observer alive, but not so alive that it outlasts the expected document lifetime, I add a dummy event listener to the document that also holds onto the observer (directly, or via a closure). When it’s time for the page to die a normal death, it clears its event listeners, which clears the strong-reference to the observer, which allows it to be GC’d. [I don't know why it swallowed the fly, perhaps it'll die...]

Summary.

let someDOMNode = ...
let observer = {
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIObserver, Ci.nsISupportsWeakReference]),
  observe : function(subject, topic, data) {
    // do stuff with someDOMNode...
  },
  handleEvent : function(event) {
    // Not called.
  }
}
observerService.addObserver(observer, "some-interesting-topic", true); // weak reference
someDOMNode.ownerDocument.addEventListener("dummyEventName", observer, false);
Posted in PlanetMozilla | 2 Comments

I <3 XUL

Posted on March 4, 2010 by Justin Dolske

(reference)

;-)

Posted in Firefox, PlanetFirefox, PlanetMozilla | Comments Off

Not quite smooth as buttah…

Posted on March 2, 2010 by Justin Dolske

So, I finally got around to watching this video which has been been making the rounds as of late (not a Rickroll, I swear to god! WHY DOES NO ONE TRUST ME?! :-). I fired it up the 1080p version in fullscreen mode, and was slightly disappointed to find that while the video was playing back rather well, it wasn’t quite perfect. As the beer commercials say, “rich, but not smooth.”

So I next loaded it up in Safari, to see how it compared. Previous versions of Firefox have had some jerky-video problems (due to running garbage collection at bad times or doing too much main-thread disk IO for session restore), so I was fully prepared to file a bug on the problem — smooth playback in another browser would be a strong indication that something in our code was causing the poor performance.

However, what I found was that playback in Safari was much much worse that on the trunk Firefox build I was using. While Firefox yielded good playback with an occasional glitch, Safari gave a consistently poor playback of around 3 fps.

There’s one clear, inescapable conclusion here: Flash sucks. :-) But seriously, folks, I’m happy to see that trunk builds perform well. I should still file a bug to investigate if we’re responsible for the occasional stutter in playback (or if that’s just Flash), and if results on Windows are similar to OS X or not. But I’m still pleased to see that this arbitrary trunk nightly — not even beta quality — is doing a good job.

Posted in Firefox, PlanetFirefox, PlanetMozilla | 5 Comments

No big whoop

Posted on February 10, 2010 by Justin Dolske

The URL shown here is making the rounds. WARNING: don’t visit this URL unless you’re prepared to have your browser crash (the screenshot is from a current trunk nightly, which survives the Flash crash due to Out Of Process Plugins support).

I’m getting all verklempt.

Posted in Firefox, PlanetFirefox, PlanetMozilla | 2 Comments

Crashed Plugin UI

Posted on February 10, 2010 by Justin Dolske

Yesterday I landed bug 538910, which introduces some new UI for when a plugin crashes. This builds on top of the fantastic Out Of Process Plugins (OOPPs) work from the Electrolysis team, which allows the browser to keep running even after a plugin dies. So, now that crashes from plugins like Flash, Java, Silverlight, and Quicktime don’t take down Firefox, we need to show the user something to indicate when a plugin has a problem and how to deal with it.

A picture is worth a kiloword, so let’s start with that:

When a plugin crashes, we now show a placeholder (as in the pic above) to indicate that the page is missing some expected content. The browser runs a single plugin process (per plugin type), which is shared across all tabs and windows, so any page using a plugin when it crashes will have it replaced with this UI. But if the plugin on the page is sized too small to show the UI (text and icon), we’ll instead show a notification bar.

Recovering from a plugin crash is easy — simply reload the page. It would be nice to restart just the plugin without reloading the whole page, but scripts on the page won’t be expecting the crash, and can break or misbehave. It would be an interesting future experiment (addon?) to allow attempting to do this anyway, but for now reloading the page is a simple, conservatative approach that we know will always work.

You might have noticed that at the bottom of the placeholder UI there’s a message saying “A crash report was submitted.” Mozilla has an existing system for collecting Firefox crash reports, which are hugely useful for helping us detect and fix problems that users encounter. Plugin crashes are also able to generate these reports, and we can notify plugin vendors of their bugs. Crashes are annoying enough, so we decided that then was the wrong time to have annoying popups or checkboxes which require the user to make a decision about submitting a report. Instead, submission is controlled by a preference (exposed as a checkbox in the usual browser preferences window), and the browser will automatically submit the crash report when it’s enabled. The preference is shared with the existing Crash Reporter, so if you’ve previously told it to not submit crashes, that choice will continue to be honored (and, now you can disable submission without having to wait for a crash to happen — but we hope you won’t do this because these reports are so helpful for improving Firefox’s stability).

The visual style of this UI is also being used for what’s shown when a plugin is missing, disabled, or blocked. We’ve always had UI for those cases, but it was a bit barebones and ugly. Now it looks better, and further refinements are coming (see bug 545070).

If you’d like to check out this new UI, you’ll need to be running a current Windows or Linux trunk nightly. Sorry OS X, no OOPP for you yet. You can wait for a plugin to crash, or just kill it off from the OS’s task manager (look for a “mozilla-runtime” process).

Finally, here’s a particularly nice screenshot of how nice this UI can look in content. Thanks to Stephen Horlander for the beautiful visual design, and to Alexes Limi and Faaborg for UX. I think this will be the best crashed plugin experience you’ve ever had. (Oh, and don’t miss Sean Martell’s epic alternate version!)

Posted in Firefox, PlanetFirefox, PlanetMozilla | 24 Comments

Colorize that build!

Posted on January 28, 2010 by Justin Dolske

If you’ve ever built Mozilla from source or run the unit tests, you’ll know that doing so can generate a lot of console output. When errors happen, it can take a bit of scrolling to figure out exactly what failed, and where. I recently switched to pymake (because it’s sooo much faster), and it generates even more output.

Recently Shawn mentioned he had some magic pixie dust to colorize build output (which I didn’t know was possible on Windows), and I extended what he had to do a bit more. I’m finding it hugely useful, so figured I should share!

First, the pretty picture. This particular example is a bit gaudy, but shows a lot of what it does. The mostly useless nsinstall output (of which there’s a *lot*) is dark blue. Compiler warnings are yellow, errors are red.

Oh, and xpcshell tests benefit too!

To add this to your Windows MozillaBuild environment, just add this stuff to ~/.profile, and then open a new shell window.

There’s probably a lot more that could be done with this (and I’m sure it missed all kinds of interesting cases), but it’s a good, simple start!

Posted in PlanetMozilla | 5 Comments

Handy trick

Posted on January 13, 2010 by Justin Dolske

If you’re involved with developing on Mozilla, odds are you’ve got at least one or two (dozen? :) profiles for testing. Some used regularly, some created-and-forgotten for one-off testing, some you’ve forgotten what they’re for. And you probably jump through gymnastics with the Profile Manager to create, select, and delete said profiles.

Once upon a time I used to do the same thing, until someone pointed out that there’s a different way to create and select profiles.

Old And Busted:

1) run firefox -P
2) Create new profile
3) Click, click, typeity, click
4) Select new profile
5) Swear, run firefox -P again because you didn’t mean to set that as your default
6) What was I doing again?
7) Oh yeah, test that thing. Quit.
8) run firefox -P
9) Delete profile
10) Lather, rinse, repeat for repeating testing with a clean new profile.

New Hotness:

1) mkdir /tmp/blah (or ~/profiles/blah for more permanence)
2) firefox -profile /tmp/blah
3) rm -rf /tmp/blah

At least for my workflow, I haven’t used the Profile Manager since. (This trick doesn’t depend on Profile Manager at all, so even it was removed at some point this would still work.) Some folks might prefer the Profile Manger for their needs, but this works great for me.

Posted in Firefox, PlanetFirefox, PlanetMozilla | Comments Off

Observations from a Comcast outage.

Posted on December 11, 2009 by Justin Dolske

I use a Comcast cable modem at home… I’ve been satisfied with the service; it’s fast enough for my needs and is generally dependable (brief glitches happen once in a while, which quickly fix themselves). However, for the past two days my modem wasn’t able to connect at all, so for the first time I actually had to call Comcast. A few observations on the experience…

* The first thing you hear when calling 1-800-COMCAST is “This is Shaquille O’Neal, and this is Ben Stein… Thank you for calling Comcast” (in their voices). This is a fantastic way to confuse callers, since it sounds like you’ve dialed a wrong number. Why have a celebrity voice on their number at all? I don’t get it.

* While their phone system routes your call to the right department, you get treated to a completely irrelevant advertisement for their telephony service. These kinds of forced ads piss me off to no end. [See also: long-winded offers you're forced to listen to when activating a new credit card.]

* I was amused that their automated phone service suggested that if I was having problems connecting to the internet, I could get help on their website.

* I dread calling “technical support,” because it usually means wasting time as they run though a standard troubleshooting checklist unrelated to what the actual problem is. To Comcast’s credit, I wasn’t subjected to this and it was an efficient process. The techs were nice, but I wish they had better diagnostic tools — the first two calls resulted in “your cable modem is dead, buy a new one”, and then my “dead” modem started to work the next morning!

* The scripted “I’m sorry you’re having a problem, I can assist you with this issue” phrase techs are required to say sounds really corny when you’ve heard the exact same line on each call. Mix it up a little?

* Dear Apple and AT&T — it’s just days until 20-fucking-10, and I still can’t tether my iPhone to my MacBook for internet access in a pinch? Sheesh.

Posted in PlanetMozilla, Technology | 2 Comments

Be prepared.

Posted on December 4, 2009 by Justin Dolske

How I plan to survive next week’s MoCo all-hands meeting:



3 liters (aka a double magnum or jeroboam) of Stone Brewing’s Double Bastard Ale. Mmmm, I can’t wait. Team Firefox will drink well!

Posted in PlanetMozilla | 2 Comments