Edit: The add-on has now been released, so check out the announcement post: Towards Browse-Based Browsing with Home Dash. Thanks for the feedback!

I started hacking on an idea last week in the context of the Prospector experiments [mozillalabs.com]. I’m looking for a small set of people to try it out and give some initial technical feedback. For example, I know I’ve hard-coded some sizes/images that happen to fit my 1280×800 screen on my Mac, but I am curious how it works or doesn’t work on other platforms, window sizes, etc.

You can install the restartless add-on [edit: addons.mozilla.org] if you’re already running Firefox 4 Beta 10 [firefox.com] or later. I’m not really describing it on purpose. But not to be too confused, below is a sketch from when I started hacking on it. And as usual, you can check out the source first from GitHub [github.com] or directly from the .xpi.

You can email me the feedback at edilee@gmail.com or just reply with a comment!

- Brainstorm next Prospector experiments

At the Mozilla All Hands last week, and we held a discussion to brainstorm various ideas to try out in the Prospector family of experiments. A couple of the current experiments like Speak Words and Instant Preview help users get back to top sites almost instantly with just one key stroke, but these mainly help for the relatively small set of sites that users frequent and not so much the remainder of the history available in Firefox.

So the next set of experiments will focus on improving the experience of searching for pages in Firefox. Interesting findings from Query Stats could help identify relevant pages or help build a better view of your past browsing behavior. Additional data about each page could be tracked by Firefox such as unique phrases from the page or how long a tab was opened and interacted with.

Displaying the search results also received some attention as to how to add all this extra information in a clean way. Some ideas ranged from being more space efficient by showing location bar results on one line to taking up more vertical space as one might not need to use the page when searching. This led to ideas of using the whole tab content area to show rich results and provide interaction such as grouping/switching of types of results like pages, apps, videos, etc.

- Prepare search bar -> button demo

Along the lines of combining the location bar and the search bar, I’ve been hacking together a Prospector experiment that changes the search bar into a list of buttons. This allows for explicit control for the user to decide when searching should be local to Firefox’s history or over the web. It also makes it apparent that there are multiple search engines to choose from and clicking another button switches the current search request to another provider.

When clicking a button, it inserts a keyword and focuses the location bar, so it’s like doing a smart bookmark keyword search with the first location bar suggestion being the search. Combined with Instant Preview, it’ll automatically update the results immediately as you type more words or switch engines.

- Attend Open Web App discussions

I was curious what kind of web-apps were being created in general across the various web-app stores available today because I wanted to see if the search bar -> button experiment above could add to the types of available apps. This is because generally speaking, these search buttons processes some words from the user and converts it to a url or a set of results.

From the screenshot above, the last button is actually for Google Translate, so when I click the button and type “hola mis amigos”, Google translates it immediately as I type to “hello my friends“. This somewhat feels Ubiquity-like, which had all sorts of commands, so potentially allowing the web app manifest to describe these “searches” or “actions” could lead to web-apps that are more than just bookmarks.

- Push restartless code examples to GitHub

I’ve been hacking on restartless add-ons for a while now and noticed that I copy/paste some useful helper functions for when I start a new add-on. Other people hacking on these bootstrapped add-ons could make use of them as well, so I created a “restartless” repository on GitHub. I’ll write a post going into more detail later, but briefly, it’s a collection of git branches where each branch contains a helper function or provides an example usage or pattern.

- Tracking down flash crashes

I’ve been running into Flash crashes on OS X for a while and noticed other people were in a similar situation. So to help resolve it, I started tracking down the various flash crash reports, and I’ve posted about my findings and issues that I ran into.

Over the last many months, flash has been crashing for me on any page with flash video when I browse away. This means flash crashes when clicking a link or typing in the location bar. Or probably worst when a site that has a flash intro it crashes when loading the main content of the site.

This seems to only affect the Flash Player 10 plugin on OS X, but it was still a bit tricky finding out what crash reports are related to this particular issue.

- There are many versions of the flash plugin

If a bug is reported with a crash signature like [@ FlashPlayer-10.6@0x4b4b39 ], watching the number of crashes for that signature go down may initially seem like something was fixed, but actually users are upgrading their version of flash and crashing at a different address. Additionally, it’s harder to see the actual number of crashes for this issue at a glance as the reports are spread across many entries.

- FlashPlayer-10.6 plugin version is missing

Adding to the issue of there being many versions, for some reason the version information for FlashPlayer-10.6 shows up in reports as 0.0.0.0. Fortunately there’s an additional debug identifier that is consistently reported for the same version of the plugin.

Below is a listing of some recent versions and debug ids:

10.2.151.49
nov 30
3CDC6F1339C791580EC31A451724F0110


10.1.102.64
nov 4
7F846A865E18B6E54DA2E5B46E7CF5B20


10.1.85.3
sep 20
392E898E2D7BCE8B02FFCE2287F7DF570


10.1.82.76
aug 10
5295F1D9A734E9FDD5350646BF2615A40


10.1.53.64
jun 10
28AEE5D0CE3E55DB5AE5787143EC0F960

I gathered these by looking through Adobe’s security bulletins to find the date and version of the new release. With the release date, I could then search for crash reports from before the release and see which reports disappeared. Then from the reports that did disappear, I can record the debug identifier to be for the new version.

- Crash reports not being submitted

Another issue that has recently been fixed was that most people running into these plugin crashes had no option to send a crash report. This was because Firefox by default runs in 64-bit mode and was unable to create a report for 32-bit plugin crashes. This means the frequency of the crashes were massively under-reported and the sparse crash data made it harder to find relevant reports.

- Improving crash-stats triaging

For this particular case, I can think of a couple features that could have made tracking down flash crashes more efficient.

Because the crash signature kept changing from version to version, I had to inspect many crashes to see if the whole stack is similar to other stacks. For one set of crashes, I was looking for AnswerNPP_Destroy in frame #8 to identify the family of crashes. Being able to search in part of the stack could also make it easier for various component teams find relevant reports.

For another set of crashes, the crash reason was always EXC_BAD_ACCESS at address 0x44c. So in addition to being able to filter by crash signature, being able to search by reason and address could have avoided needing to click through many crash signature reports.

There’s a number of bugs filed for these flash crashes like bug 590955, bug 572134, and bug 617469. I’m still not sure if it’s an issue with OOPP or a bug in the plugin, so it’s hard to say if flash will stop crashing by a new Firefox beta release or a plugin update. But just as a heads up, getting the latest Flash Player 10.2(.151.49) beta or Firefox 4 beta8 won’t fix these crashes.

Being able to run chrome-privileged code from the Error Console has been very convenient for me to help users debug issues with Firefox or an add-on when they get stuck in some strange state. I can quickly test an idea or a snippet of code and have the user run it to track down where things are going wrong. However, there’s some issues that make it tricky to use:

• Users get confused doing Tools -> Error Console -> Paste -> Evaluate
• Users might not copy/paste correctly or perhaps the code got wrapped oddly
• Javascript version seems to be 1.6, so let needs to be replaced with var, etc.
• Scripts are heavily GCed, so modules are imported to attach objects to keep them alive
• Everything needs to be on one line, so beware of any lines with // comments!
• Console output is html-like and strips tags and empty output leading to confusion

One additional drawback in Firefox 4 is the Error Console is now disabled by default, so having users first go to about:config and toggling devtools.errorconsole.enabled to true is an extra step where users can get lost. (Don’t forget about the click-through warning page! ) Additionally, I believe enabling the Error Console requires a restart, so debugging a live instance is troublesome unless the problem is easily reproduced.

New preference to enable the Error Console (under the Tools menu)

Fortunately, Firefox 4 comes with restartless add-ons! You can just package up an add-on with two files: bootstrap.js and install.rdf, with the relevant code running from the startup() function. It’s simpler for users to try out as it looks like any other add-on install, so just point to the .xpi and click Install.

Just make sure that if you want the code to only run once, have the add-on uninstall itself after running. Otherwise it’ll be like any other add-on that runs when Firefox starts.

Code snippets to for one-time scripts and easy reloading of scripts

Another neat trick for reloading or running an updated script is having the add-on auto-enable itself when it’s disabled. I can now just make changes to the files and click Disable once from about:addons, and it’ll automatically reload itself instead of needing to click Enable. Also because now I can just edit the file and not need to copy/paste into Error Console, I can easily track my changes with revision control software.

I’ve provided the bootstrap.js and install.rdf files needed for this simple restartless add-on. From there you just need to:

1. Delete one of the auto-uninstall or auto-enable snippets from bootstrap.js
2. Add in the code you want to run inside startup() of bootstrap.js
3. Package up the files into an xpi: zip restartless.xpi bootstrap.js install.rdf
4. Distribute/install restartless.xpi