(reference)

;-)

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.

I’m getting all verklempt.

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!)

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!

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.

* 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.

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!

* CrashKill. We’ve been making a big push to reduce Firefox crashes. I’ve largely been working with 3rd party crashes (eg bug 519340). Some of these 3rd parties are very responsive and quickly work to resolve the crashes their product is causing, others are… less so. It was surprising to me to find that other software is directly responsible for a huge number of Firefox crashes… Antivirus software, Flash, and malware seem to be the worst.

* Firefox on Tegra. Working on getting Firefox 3.6 running well on Tegra netbooks, and diving into localization issues so we can fully support Windows CE like other platforms.

* Firefox application updater. I mentioned in a previous update that my fix for bug 517102 made the updater 3x faster. I’m working on what should be another big performance and reliability boost in bug 529464.

* Password manager fixes and features. These have been in-flight for a while, but unfortunately didn’t make Firefox 3.6. But I’m pushing to wrap them up in coming weeks and get them into the next release. Notable changes are bug 499417 (refactoring the “master password” code, a first step to bigger changes), bug 499233 (finally killing multiple master password prompts on session restore), bug 465636 (add timestamps to login metadata), and bug 223636 (support automatic login for HTTP Auth).

* Rewriting the Weave’s crypto backend (bug 513798). Last year I rewrote Weave’s crypto code to use NSS (Firefox’s own crypto library) instead of OpenSSL. That’s been working swell, but it’s a binary component, and is a real pain to deal with when making Weave available on other platforms (like all the new mobile devices we’re working with). Dan Witte recently landed JS-Ctypes, which allows JavaScript code to call into native libraries. So now I’m porting the Weave C++ code to JS to take advantage of this.

* Using CSS Transitions in HTML5 video controls (bug 521890). David Baron has added support for the CSS Transitions spec to Firefox trunk, so I took a look at having our HTML5 video controls use this feature. When I implemented the controls for Firefox 3.5, I had to use a pile of JavaScript timers and callbacks to implement the fade and slide effects… CSS Transitions GREATLY simply doing such things. Currently blocked on one issue.

* Performance work. Noticed an issue with Necko not caching protocol handlers well (unknown what the perf impact is yet), looked how often we check perferences at runtime (a LOT, no bug yet), and am starting to look at the impact of all the timers we have firing and how they might be impacting power usage. Also investigating a problem with restoring maximized windows. We inefficiently restore the size, which slows down opening a window on Tegra devices (which generally use maximized windows).

* Got a speedy new Windows 7 desktop, and have been getting it configured and running.

My next big project is finishing up Doorhanger Notifications, which are a critical UI feature for the revamped Firefox 3.7/4.0 themes. Matt Noorenberghe started the implementation this summer as an intern, so I’ll be wrapping that up and making it fit updated designs.

(*phew*)

Silverlight?

On my OS X box? How the fuck did that get there? I sure don’t remember installing it. Grrrr!

A little web searching later, and I found my answer. It’s silently installed with Flip4Mac (a set of Quicktime components to allow playing Microsoft proprietary media formats on OS X), which I had installed a week or two ago to try something, and then promptly forgot about. The installer doesn’t have a word to say about it, unless you click a little “Customize” button on the 5th screen on the install:

That really annoys me. Silent, sneaky software installs are evil, evil, evil.

At least Flip4Mac includes an uninstaller, so I ran that. It’s actually a package, so you’re confusingly prompted to “Select the disk where you want to install the uninstaller software.”, but it was otherwise painless. Now to just restart my browser, check about:plugins, and…

GAHHHH! It’s still there. Their uninstaller uninstalls the Flip4Mac bits, but not the Silverlight plug. Solution:

rm -rf /Library/Internet\ Plug-Ins/Silverlight.plugin/

It’s finally dead, Jim.