Planet Firefox

Fast JavaScript is a cornerstone of the modern web. In the past, application authors had to wait for browser developers to implement any complex functionality in the browser itself, so that they could access it from script code. Today, many of those functions can move straight into JavaScript itself. This has many advantages for application authors: there’s no need to wait for a new version of a browser before you can develop or ship your app, you can tailor the functionality to exactly what you need, and you can improve it directly (make it faster, higher quality, more precise, etc.).

Here are two examples that show off what can be done with the improved JS engine and capabilities that will be present in Firefox 4. The first example shows a simple web-based Darkroom that allows you to perform color correction on an image. The HTML+JS is around 700 lines of code, not counting jQuery. This is based on a demo that’s included with Google’s Native Client (NaCl) SDK; in that demo, the color correction work is done inside native code going through NaCl. That demo (originally presented as “too slow to run in JavaScript”) is a few thousand lines of code, and involves downloading and installing platform-specific compilers, multiple steps to test/deploy code, and installing a plugin on the browser side.

I get about 15-16 frames per second with the default zoomed out image (around 5 million pixels per second — that number won’t be affected by image size) on my MacBook Pro, which is definitely fast enough for live manipulation. The algorithm could be tightened up to make this faster still. Further optimizations to the JS engine could help here as well; for example, I noticed that we spend a lot of time doing floating point to integer conversions for writing the computed pixels back to the display canvas, due to how the canvas API specifies image data handling.

The Web Darkroom tool also supports drag & drop, so you can take any image from your computer and drop it onto the canvas to load it. A long (long!) time ago, back in 2006, I wrote an addon called “Croppr!”. It was intended to be used with Flickr, allowing users to play around with custom crops of any image, and then leave crop suggestions in comments to be viewed using Croppr. It almost certainly doesn’t work any more, but it would be neat to update it: this time with both cropping and color correction. Someone with the addon (perhaps a Jetpack now!) could then visit a Flickr photo and experiment, and leave suggestions for the photographer.

The second example is based on some work that Dave Humphrey and others have been doing to bring audio manipulation to the web platform. Originally, their spec included a pre-computed FFT with each audio frame delivered to the web app. I suggested that there’s no need for this — while a FFT is useful for some applications, for others it would be wasted work. Those apps that want a FFT could implement one in JS. Some benchmark numbers backed this up — using the typed arrays originally created for WebGL, computing an FFT in JS was approaching the speed of native code. Again, both could be sped up (perhaps using SSE2 or something like Mono.Simd on the JS side), but it’s fast enough to be useful already.

The demo shows this in action. A numeric benchmark isn’t really all that interesting, so instead I take a video clip, and as it’s playing, I extract a portion of the green channel of each frame and compute its 2D FFT, which is then displayed. The original clip plays at 24 frames per second, so that’s the upper bound of this demo. Using Float32 typed arrays, the computation and playback proceeds at around 22-24fps for me.

You can grab the video controls and scrub to a specific frame. (The frame rate calculation is only correct while the video is playing normally, not while you’re scrubbing.) The video source uses Theora, so you’ll need a browser that can play Theora content. (I didn’t have a similar clip that uses WebM, or I could have used that.)

These examples are demonstrating the strength of the trace-based JIT technique that Firefox has used for accelerating JavaScript since Firefox 3.5. However, not all code can see such dramatic speedups from that type of acceleration. Because of that, we’ll be including a full method-based JIT for Firefox 4 (for more details, see David Anderson’s blog, as well as David Mandelin’s blog). This will provide significantly faster baseline JS performance, with the trace JIT becoming a turbocharger for code that it would naturally apply to.

Combining fast JavaScript performance alongside new web platform technologies such as WebGL and Audio will make for some pretty exciting web apps, and I’m looking forward to seeing what developers do with them!

Edit: Made some last-minute changes to the demos, which ended up pulling in a slightly broken version of jQuery UI that wasn’t all that happy with Safari. Should be fixed now!

July 30, 2010 09:14 PM

July 30, 2010 08:53 AM

I am going to focus on these side projects in the coming weeks, in addition to driving the Firefox security releases. If you see anything missing or something that needs my attention, please let me know.

Projects in order of importance

1. Patch for Bugzilla to add rich bug relations.
   This will give us greater confidence that bugs aren’t missed/overlooked. It will also help development by organizing bugs consistently and allow for richer tools, processes, and progress reporting
2. Create a new “release management” system that will manage all aspects of a release.
   This will allow consistent processes between different teams/releases, make sure nothing is missed, add checking tools, and generally become the “truth” when it comes to release metadata (schedule, state, status, etc)
3. Get Mozilla Pulse (http://pulse.mozilla.org) solid, usable, and useful.
   Pulse has the opportunity to make all systems at Mozilla better. I hit some bumps with RabbitMQ but will be working on ironing them out and providing a scalable, HA system that can later be handed over to another team
4. Create a triage reporting tool.
   This will make the approval processes more open by publishing triage notes and results. It will also be a place to put action items so that they are acted upon before the next triage session
5. Finish new release note framework.
   I started this when I first came but got tied up in other projects. The way we do release notes involves a lot of copy and paste, it is difficult for QA to create automated tests, etc. I intend to fix this
6. Patch for TabCandy to support user-defined rules.
   The response to TabCandy has been great, but I think having this feature will be essential for power users and those who don’t want to manually organize tab groups. I’ve looked at the TabCandy code a bit and this shouldn’t be too hard to hack in. I may work on this a bit as a breather from the above projects (but probably not)

If you have any ideas about these systems (or others you think release management needs), please let me know!

July 26, 2010 07:01 PM

Progress:

---

• Spent most of the week working on Bug 523410 [Core] – Disable LSPs in WinSock for Firefox [Windows]. I now have a pretty good understanding of the implications of implementing this and believe the benefits are worthwhile.
• Landed on trunk Bug 540537 [Firefox] – In China, set default browser does not work [Windows]. This might not fix all of the issues but it definitely fixes one of the issues.
• Landed on trunk Bug 580579 [Toolkit] – While creating services from category ‘profile-after-change’, service for entry ‘nsUpdateServiceStub’, contract ID ‘@mozilla.org/updates/update-service-stub;1′ does not implement nsIObserver. [All].
• Created builds using 1.9.1 and 1.9.2 for Thunderbird, SeaMonkey, and Sunbird just to be sure that landing Bug 367539 [Toolkit] – When upgrading an existing install use the uninstall.log to uninstall the previous version before install [Windows] on 1.9.1 and 1.9.2 won’t adversely affect them and all is clear to fix this bug on 1.9.1 and 1.9.2.

Future:

---

• Finish the patch for Bug 523410 [Core] – Disable LSPs in WinSock for Firefox [Windows].
• Fix Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All]. I wanted to get this done last week but the first two items in the progress section got in the way.
• Land on 1.9.1 and 1.9.2 Bug 367539 [Toolkit] – When upgrading an existing install use the uninstall.log to uninstall the previous version before install [Windows].
• Fix Bug 577563 [Toolkit] – Consider renaming log files so they don’t have a .log file extension [Windows]. This bug breaks uninstalls after running a utility that removes log files… meh.
• Get review / land Bug 570689 [Toolkit] – Convert preprocess-locale.pl to a python script [Windows].
• Get review / land Bug 575838 [Toolkit] – Build scripts should be able to handle @BINPATH@/extensions/testpilot@labs.mozilla.com/* in package-manifest.in for the installer [Windows].
• Continue work on silent updates for windows.

July 26, 2010 05:27 AM

July 23, 2010 04:56 PM

The first iteration of the Inspector’s style panel has landed!

It’s pretty basic right now and we’re going to be beefing it up and adding to it in the hopefully very near future. What it shows right now is a list of all CSS properties for the selected (highlighted) element in a web-page. It will also tell you which elements the rules were inherited from (in reverse-order) and from which stylesheet the rules came from. You may need to expand the panel slightly to see the full text.

These panels are not positionable yet, but with the landing of the titlebar patch in bug 552982, it’ll be a quick thing to add. I’m hoping that comes in Real Soon Now. The funny-looking title bar that doesn’t do anything in the current version is actually a toolbar I added as a placeholder for the real thing. In the meantime, I suggest moving your browser window to the left of your screen to allow some space at right for the panel to live in (as well as some space below your window for the tree panel to inhabit).

What’s next?

I still have a few downstream patches requiring review.

• Milestone 0.3, create DOM Object viewer for Inspector.
• Milestone 0.5, rewrite tree panel
• Milestone 0.6, create popup editor

I have a patch for the popup editor which needs to get added to that last bug which I demoed at the Summit Science Fair. I need a similar editor for CSS editing. Once those are squared away, I’ll be working on redesigning the highlighter panel and getting the styling finished up for the various pieces on all platforms.

Please file bugs in Firefox::Devtools.

July 19, 2010 05:44 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

---

New & noteworthy

Firefox 4.0 Beta 2 is being released this week — or early next week — and adds tabs-on-top for Mac, as well as the first iteration of App Tabs. There’s also an expanded Test Pilot study included in this beta to help us get more data on how people use the new menu and other elements of the redesign.

With one week disappearing to the Mozilla Summit, and with Firefox 4 betas being on a two-week release schedule, this beta release lands a few important milestones, but not a lot more on the UI side. Lots of exciting stuff on the infrastructure side:

• Retained Layers — which, among other things, makes scrolling a page very smooth,
• JS performance improvements,
• CSS transitions & transforms,
• & a fix for the bug that was causing multiple dock icons on OS X when plugins are running.

---

Status reports on current UX priorities:

Start page video for the new

Alex Faaborg:

• New video is coming for beta 2, waiting until freeze happens. Also would like to do the captures on OS X.

Notifications

Alex Faaborg:

• Low priority right now, but we need to get the panel stuff done (for instance geolocation is still styled as as tooltip on windows, and the combo button looks like a drop down control)

Firefox menu

Alex Faaborg:

• Lots of work completed over the weekend, spec of intended design, tracking how commands are migrating over, and a projected heatmap of usage that also got some nice attention in the press.

Site identity

Alex Faaborg:

• Need to discuss planned changes with the UX team before we propose anything more officially
• Need to get mockups done for Frank of the different states

Firefox Sync

Alex Faaborg:

• Top priority now.

Home tab & App tabs

Alexander Limi:

• First iteration of App Tabs have landed! Just in time for beta 2. Doesn’t support drag operations yet, but is available from the context menu on tabs for now.

Download Manager

Alexander Limi:

• No changes this week, but plan to get in touch with Paolo, who I talked to about this at the Summit.

HTML5

Alexander Limi:

• Had some conversations with Tantek, he has expanded & updated the HTML5 wiki page.

“Paper Cuts”

Alexander Limi:

Paper cut overview bug is here.

• We’re arranging a “Paper Cuts” hacking session this Thursday in Mountain View for Mozilla employees, and anyone that wants to follow along on IRC.
• If successful, we’ll try to do this at the end of every week for the developers that are interested.

Main window refresh

Stephen Horlander:

• Most of the major pieces are in.
• Still need progress bar on tabs and combined stop/go/reload.
• Focus on Windows/Mac on refinement bug fixing.
• Need to evaluate Bookmarks Menu Button feedback.
• Next major thing is going to be theming the Window frames/controls for non-Aero configurations — XP, Aero Basic, Classic.

In-content page design

Stephen Horlander:

• Will wait until add-ons redesign has a first implementation ready.

Add-ons Manager

Jennifer Boriss:

• Still on track — “Personas” has officially changed to “Backgrounds”, so making new mockups to incorporate the change
• Mock-ups still need a few tweaks. Working on these now.
• Talk of combining plugins and extensions into a single category — what does the UX team think?
• Disable/ask about extensions on first-run — Boriss to ask add-ons team about what data we have that can inform this. (e.g. do we know when extensions were first installed, which extensions have binary components, &c.

Jetpack & the Extension Bar

Jennifer Boriss:

• No change from last week.
• Action: contact Dietrich and ask about what state it’s currently in.

Privacy

Jennifer Boriss:

• Mulani still working on the implementation of the site-centric prefs.

TabCandy

Aza Raskin:

• We are in the process of getting review. Missed beta 2.
• We’ve created a Reviewer’s Guide for those wanting to get into the code.
• Starting to look at doing a video intro for the first-run experience.
• Need to do a deep-dive on app-tabs + TabCandy.
• Need help with deciding keyboard shortcuts — a veritable bikeshed factory.

Post-Firefox 4 Home Tab

John Wayne Hill: (UX intern)

• Continuing to work on details of concepts in between startup experience stuff, put new sketches online, working on higher fidelity ones
• think more about notifications from add-ons, non-Firefox installed add-ons, &c.

Startup performance perception

Alexander Limi & John Wayne Hill

• Startup Experience overview page is up.
• Filed all necessary bugs.
• Got some champions for bugs.
• Need to get champions for newly filled bugs, prioritized the list in terms of effort and value.
• We’ll bring the list to Tuesday’s developer meeting.

Mobile

Madhava Enros:

• Not present.

Feedback session

Quick feedback and/or blockers; for in-depth discussions, we do design sessions on Wednesdays.

Other topics covered

Focus for next beta:

• Location bar improvements 
  • Meta bug for the location bar improvements
  • Frank is on the combined stop/reload/go improvements.
  • Design session on Wednesday, also talk about privacy indicators in Larry etc + Privacy Icons + Firefox Menu.
  • Protocol removal/improvements: as early as possible, Frank wants to look at this after stop/go/reload.
  • URL hover design/implementation.
  • AwesomeBar results — visual design improvements.
• Home/App tabs: dragging + chromeless + right-click to bring controls back + app tab behavior in multiple windows (limi)
• Doorhanger notifications: not landing in time for next beta, probably later (1-2 betas out)
• Startup Experience:
  • Meta bug for Startup Experience issues.
  • Run it by Vlad, dbaron or Stuart, identify biggest wins, prioritize.
  • Drawing the window all at once needs to be nominated for blocking the final release — it looks really broken if we only draw part of the bottom half with the top missing with the new glass theme.
  • Ask on startup, not shutdown for session restore.

Questions for the Firefox Development Meeting

• Startup Experience prioritization & feedback on feasibility for Firefox 4.

---

About the meetings

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning & dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.

July 18, 2010 11:50 PM

Progress:

---

• Submitted a 1.9.2 patch for review for Bug 576939 [Toolkit] – Backport app update fixes to 1.9.2 [All]. This includes fixes for several long standing bugs and adds application update ui tests for 1.9.2.
• Started patch to backport to 1.9.2 Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All].
• Submitted a patch for Bug 540537 [Firefox] – In China, set default browser does not work [Windows]. This might not fix all of the issues but it definitely fixes one of the issues. Thanks go out to Lingfeng Guan for tracking down the registry fixes and for testing. btw: the try server was absolutely useless for this bug due to random errors for multiple submissions.
• Discussed the solution with dveditz and johnath for Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All]. Should be able to fix this next week.
• Wrote a service for silent / background updates on Windows along with much of the code for being notified when an update is available, checking if there is a running instance of the application to be updated, etc. The current work provides several of the stepping stones in the full path to getting this working.

Future:

---

• Fix Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All].
• Fix Bug 577563 [Toolkit] – Consider renaming log files so they don’t have a .log file extension [Windows]. This bug breaks uninstalls after running a utility that removes log files… meh.
• Land on 1.9.1 and 1.9.2 Bug 367539 [Toolkit] – When upgrading an existing install use the uninstall.log to uninstall the previous version before install [Windows]. Yay!
• Get review / land Bug 570689 [Toolkit] – Convert preprocess-locale.pl to a python script [Windows].
• Get review / land Bug 575838 [Toolkit] – Build scripts should be able to handle @BINPATH@/extensions/testpilot@labs.mozilla.com/* in package-manifest.in for the installer [Windows].
• Continue working on silent / background updates on Windows.

July 18, 2010 08:58 PM

I did a lightning talk at the Mozilla Summit about my pet infrastructure project, Mozilla Pulse. I’ll be talking about it in more depth in a future blog post. This post is more a call for help from message broker experts.

I’ve been running into issues with RabbitMQ (the erlang message broker that runs on pulse). I griped a little on Twitter and got some responses, so I decided to write a more in-depth description of what I am running into. I’m not going to explain any message broker specific terminology, so feel free to skip this post if you don’t know what I am talking about. None of this should be important if you just want to use pulse in the future.

The general idea of using a message broker at Mozilla is to make useful tools on top of infrastructure, with the infrastructure (producers) being loosely coupled from the tools (consumers). Because of this, I came up with this configuration for an initial prototype:

Exchanges

org.mozilla.exchange.bugzilla (topic)

• All Bugzilla messages are routed in here. Bugzilla is the producer, with permissions of “.*bugzilla” “.*bugzilla” “.*bugzilla”. That is, the Bugzilla producer can do anything to the Bugzilla exchange
• The message routing key hierarchy looks like bug.added, bug.changed.[field], etc
• The plan was to add more, sticking logic in the producer (that is, bug.changed.resolution when the message data is CLOSED should be elevated to bug.closed instead, etc)
• The message rate is very high-volume for Mozilla’s Bugzilla, as you can imagine

org.mozilla.exchange.hg (topic)

• All hg.mozilla.org messages are routed in here. HG is the producer, with permissions of “.*hg” “.*hg” “.*hg”. That is, the HG producer can do anything to the HG exchange
• The message routing key hierarchy looks like hg.mozilla.central.repo.[opened/closed], hg.releases.mozilla.1.9.2.[commit/push], etc
• The message rate is not that high-volume, though when watching all repositories it could be a bit bursty

org.mozilla.exchange.build (topic)

• All build.mozilla.org messages are routed in here. Buildbot is the producer, with permissions of “.*build” “.*build” “.*build”. That is, the Buildbot producer can do anything to the build exchange
• This is currently experimental and the routing keys haven’t been figured out to provide the most value
• Very high-volume, though less so than the Bugzilla exchange

Consumers

These were my general goals for consumers:

1. Be as simple as possible so people can start playing with pulse, proving the idea and getting some momentum
2. I do not want to be the bottleneck for experimentation, so no user accounts or administration tasks necessary to just consume messages
3. Users writing consumers should not need to learn about any of the underlying message broker terminology or technology
4. Users could be running consumers on their local machines, and when they reconnect all the messages they missed should be there waiting (they could clear the old messages or process them depending on their needs)

Because of those, I came up with the following plan:

1. Create a user named public with a password of public and permissions of “” “” “.*”, which as far as I know means the user can read from anything but not write or create. The public user can still write and create server-created resources, which means when it asks for the foo queue, the server will create it if it doesn’t exist and public will then only have access to read from it
2. Create a trivial shim library in python on top of carrot to abstract out the message broker bits and help Mozilla-specific consumers get up and running quickly
3. Make sure people testing set a unique string for their applabel, which means their queue will be unique and message delivery will not fall back to round-robin between different people

So, seemed like a good plan, right? And it worked! Until…

Issues

Deleting unused queues

It became clear people (myself included) created some queues and then later changed to a different queue. The old queues were sitting there accumulating messages which would never be consumed. I went to delete the queues and…..rabbitmqctl doesn’t have a delete queue command. Darn. Ok, I have the BQL plugin installed, so not a huge deal to pop in and delete them through that, but it seems odd this functionality is missing.

Running out of memory with old persister

There were some bugs in the Bugzilla producer which caused messages to be extremely throttled. I fixed them and immediately the broker ran out of memory and fell over. This was because there were 10 or so queues that weren’t having messages actively consumed, each with ~1000 messages. I didn’t see this in testing because all my testing consumers were running and consuming the messages that were sent without any buildup. Additionally, the server is running on a VM (it’s a prototype after all) which doesn’t have a bunch of memory to begin with.

I tried to connect to the queues with a python consumer (using carrot) to drain them, but everything just hung. I could not drain the queues and unblock the server, which meant I couldn’t write an administration script that removed 500 messages out of any queue with > 500 un-acked messages.

Reading around, a lot of people are running into this problem. The good news is that the new persister is supposed to fix it, though it isn’t quite done yet. It looks like the new persister is in QA and many people on the mailing lists are running it, so I decided to take the plunge on this prototype system.

Incompatibilities between RabbitMQ 1.7.x and 1.8.x

The prototype pulse system was running RabbitMQ 1.7.x and everything was working well (except for the out of memory bit above). To get the new persister, I had to update to 1.8 (as the latest persister branch is 1.8 based). I decided to upgrade to 1.8 release and make sure everything else still worked before adding the additional layer of pre-release code on top. This is what I did:

1. Downloaded rabbitmq-public-umbrella
2. Compiled, installed, and then activated some plugins

I deleted the old persister log, started the server, and immediately found an issue.

The public user couldn’t seem to create queues anymore. Darn, that meant people wouldn’t be able to use my shim lib. Reading around, it looked like it could be caused by having a 1.7.x data directory with 1.8.x, so I deleted the whole data directory and let RabbitMQ recreate it. I then built up the exchanges, users, and permissions exactly as before. The problem was still there.

So, it looks like the RabbitMQ change to the new AMQP semantics in 1.8 broke what I was doing. Apparently, it is no longer possible to have a read-only user create a queue. I guess this makes sense, though it was my (naive) understanding that automatic queue creation was built into the AMQP spec. That is, the read-only user is requesting it, and if it exists it is handed back to the user, otherwise the server creates it on their behalf. Perhaps this is a bug?

In any case, I opened up the permissions for the public user (this is a prototype system with no real users remember).

Running out of memory with new persister

I decided to take the plunge and make sure the new persister fixed my memory issue before pursuing the permissions issue. This is roughly what I did to upgrade:

1. Downloaded rabbitmq-public-umbrella
2. Downloaded the new persister branch
3. Replaced rabbitmq-server in rabbitmq-public-umbrella with the persister branch
4. Compiled, installed, and then activated some plugins

I then created some queues, started up the Bugzilla producer, and sent thousands of messages through. RabbitMQ fell over again, as far as I can tell with the same problem. I deleted the whole data directory and let RabbitMQ recreate it. I then built up the exchanges, users, and permissions exactly as before. And it still ran out of memory.

Questions

1. Are people successfully running the new persister for RabbitMQ?
2. Do I need to explicitly turn on the new persister when using the new persister branch? If so, how? There are (understandably) no docs that I can find.
3. Am I setting up the exchanges, queues, and vhosts wrong? As far as I can tell everything was working great before the OOM stuff and the 1.8 semantic changes.
4. Is there a better way to structure what I want to do?
5. Is my use-case not supported by RabbitMQ? That would be odd, as this seems like the exact use case that message brokers were made to solve. Do other brokers support what I want?

July 17, 2010 08:05 PM

July 16, 2010 10:45 AM

Q: Kathleen who?

Kathleen Wilson works for the Mozilla Corporation, and manages our queue of incoming certificate authority requests. She coordinates the information we need from the CAs, shepherds them through our public review process and, if approved, files the bugs to get them into the product.

Q: Holy crap! One person does all of that? Is she superhuman?

It has been proven by science. She is 14% unobtainium by volume.

Q: That’s really awesome, but I am a terrible, cynical person and require ever-greater feats of amazing to maintain any kind of excitement.

She came in to a root program with a long backlog and sparse contact information, and has reduced the backlog, completely updated our contact information, and is now collecting updated audit information for every CA, to be renewed yearly.

Q: Hot damn! She’s like some kind of awesome meta-factory that just produces new factories which each, in turn, produce awesome!

I know, right? She has also now removed several CAs that have grown inactive, or for which up to date audits cannot be found. They’ll be gone as of Firefox 3.6.7. They’re already gone on trunk.

Q: Wait, what?

Yeah – you can check out the bug if you like. I’m not positive, but I think this might represent one of the first times that multiple trust anchors have ever been removed from a shipping browser. It’s almost certainly the largest such removal.

Q: I don’t know what to say. Kathleen completes Mozilla. It is inconceivable to me that there could be anything more!

Inconceivable, yes. And yet:

1. She’s also made what I believe to be the first comprehensive listing of our root, with signature algorithms, moduli, expiry dates, &c.
2. In her spare time, she’s coordinating with the CAs in our root program around the retirement of the MD5 hash algorithm, which should be a good practice run for the retirement of 1024-bit RSA (and eventually, in the moderately distant but forseeable future, SHA-1).
3. She has invented a device that turns teenage angst into arable land suitable for agriculture.

Fully 2 of the above statements are true!

Q: All I can do is whimper.

Not true! You can also help! Kathleen ensures that every CA in our program undergoes a public review period where others can pick apart their policy statements or issuing practices and ensure that we are making the best decisions in terms of who to trust, and she’d love you to be a part of that.

• subscribe to the mozilla.dev.security.policy usenet group
• or the mailing list version
• or the google group clone

Q: I’ll do it! Thanks!

No, thank you. That wasn’t a question.

July 13, 2010 02:24 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

This is an older update that wasn’t published because I managed to break my blog in interesting ways while testing the new & very excellent Plone 4 beta release. Since it happened just before the Mozilla Summit, I didn’t have time to fix it, so I’m publishing these two older updates today too. Apologies if this is confusing anyone. The date in the header is the correct date for when the meeting happened.

---

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

---

New & noteworthy

This week is a bit special, since we were all away at the Mozilla Summit last week, so the traditional project updates do not apply this time.

---

Firefox Beta 1 shipped before the Summit — hooray! — and we spent most of this meeting this time identifying what we should focus on for the upcoming betas. Firefox 4 has a seriously aggressive beta schedule, with a new beta shipping roughly every two weeeks until we get to the final release in Q4 2010.

The list of items that we identified:

• Session Restore: cascading loading + UI
• Home tab
  • snippets infrastructure
  • UI for session restore
• Extension bar: need to make sure this isn’t scoped as only Jetpack
• Menu bar cleanup (both new & traditional menu)
• Context menu cleanups
• Chrome menu cleanups
• Customization of tabs/menu etc
• Sync UI
• Sharing
• Mac installer improvements
• Minimum tab width & redundant buttons
• Focus issues: tab-modal dialogs, content should never steal focus from chrome, new tabs should always be focused, flash steals keyboard shortcuts (Neil Deakin might have advice here?)
• Improved “List all tabs”: Recently closed tabs, only show tabs outside of the visible set
• Find in Page fixes
• Download manager as panel
• HTML5 widgets
• Panels needs focused effort
  • we need to use them for tab modal dialogs
• Location bar
  • stop/go/reload
  • Identity block (+ geo, + activity manager)
  • Styling of the AwesomeBar results
  • Progess of active tab loading
  • autocomplete (speak URL)
  • URLs on hover — since status bar is going away
• Progress indicators in general

Outcomes and conversations from the summit

• People very excited about the new theme!
• Lots of talk about Apps, feels more solid — nobody questions whether we want to do specific apps anymore. Much design work and standards work left.
• Discussions on add-ons as things that are not installed by the user (crapware), happy to see this discussed
• Discussion on the extension bar was very useful, some ideas on how to do toolbars & related matters
• Device UI session was good, lots of feedback, figure out the conceptual model, figure out how it should look on OEM devices
• Talk to product group about opportunity in slate devices this holiday season — would be good to be a better experience than IE8 on these devices.
• Tabs in titlebar should be possible (but not default, obviously) on the Mac — just like with the Firefox menu button
• Fixing session restore had a lot of support
• Work offline: need to make sure there aren’t any real use cases for it that we’re missing — nobody has given any real reasons yet, there’s a lot of “superstitious behavior,” however
• Check with platform team what the status on fixing caching (possibly in the dev meeting tomorrow)
• Linux: Found that Gnome is heading in this direction (custom window decorations) anyway, so makes less sense for us to do this. Still support FF menu button in the tab bar instead.
• Are there quick wins on UI effects (fading icons in, fade between back/forward) that we can make use of easily?
• Site-specific privacy talk led to good feedback, new ideas, people willing to help
  • State of privacy defaults (third-party cookie behavior) still seems very up in the air, a number of ideas that perviously seemed promising have been partially abandoned
  • We should try and sniff out current state of this from Dan Witte, Sid Stamm, et al.

---

About the meetings

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning & dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.

July 11, 2010 11:50 PM

One of the goals of the new add-ons manager API was to create something that was itself extensible. A couple of times in the past we’ve had to add new types of add-ons to the UI like Plugins and Personas. In both cases squeezing them into the UI was something of a kludge involving a bunch of custom code for each case. We already have a number of new types of add-ons that we want to add, things like search plugins which are currently managed by their own custom UI.

To help simplify this the API is largely type-agnostic. Internally it uses a number of so-called add-on “providers”, each of which may make information about add-ons available. Each provider is basically a JavaScript object with functions defined that the API can call to ask for information about add-ons that the provider knows about. The provider then just has to pass back JavaScript objects to represent each add-on. Each of these must have at minimum a set of required properties and functions and may also include a set of optional properties. The full set is defined in the API documentation.

With this design the user interface doesn’t need to care about implementation details of any of the providers, how they store their data or what exactly their add-ons are and do. Because each gives objects that obeys the same interface it can just display and manipulate them.

To try to show this all off I recently put together a small demo extension for the Mozilla Summit that registers a new type of add-on to be displayed in the main add-ons manager. This is a short overview of some of the highlights and I’ll make the code available for people to look at and take examples from. The add-on was a basic implementation of Greasemonkey allowing user scripts to be installed, managed through the add-ons manager and do it all as a restartless add-on.

Making a restartless add-on

Add-ons don’t have to be developed with Jetpack to make them restartless, although the Jetpack SDK certainly makes things easier on you, at the expense of less access to the internals of the platform.

The first thing to learn about making a restartless add-on is that you can forget about using XUL overlays or registering XPCOM components to be called at startup. Neither are supported at the moment, and maybe never will. Instead you have to provide a bootstrap script. This is a simple “bootstrap.js” file in the root of the extension that should include a “startup” and “shutdown” function. These are called whenever Firefox wants to start or stop your add-on either because the application is starting up or shutting down or the add-on is being enabled or disabled. You can also provide “install” and “uninstall” methods to be notified of those cases but that is probably unnecessary in most cases.

At startup the demo extension does some basic things. It registers for some observer notifications, registers a new add-on provider (I’ll talk more about that below) and does a little work to include itself in the add-ons manager UI (again, see below).

The rule is this. Anything your add-on does after being started must be undone by the shutdown function. The shutdown function often ends up being the inverse of startup, here it removes observer notification registrations, unregisters the add-on provider and removes itself from the UI. It also shuts down a database if it was opened.

Implementing a new provider

This extension implements probably the simplest possible provider. As far as the API goes all it supports is requesting a list of add-ons by type or a single add-on by ID. These functions pass add-on objects to the callbacks. For this add-on these objects are held in a database so that code does some fairy uninteresting (and horribly synchronous) sql queries and generates objects that the API expects.

Adding new types to the UI

Perhaps the hardest part of this extension is getting the new type of add-on to display in the UI. Unfortunately one thing that we haven’t implemented so far is any kind of auto-discovery of add-on types. Instead the UI works from a mostly hardcoded list. This is something that we think it would be nice to change but at the moment it seems unlikely that we wiull get time to before Firefox 4, unless someone wants to volunteer to do some of the work.

The demo extension works around this restriction by inserting some elements into the add-ons manager window whenever it detects it opening. In particular it adds an item to the category list with a value attribute “addons://list/user-script”. The add-ons manager UI uses this kind of custom URL to decide what to display when a category is selected. In this case it means displaying the normal list view (that plugins and extensions currently use) and to ask the API for add-ons of the type “user-script”. There is also some code there that overrides the normal string bundle that the manager uses to localize the text in the UI to allow adding in some additional strings. The code I am showing is of course badly written in that it is hardcoded and so could not be localized, please forgive me for cutting corners with the demo.

That is basically all that is needed to have the UI work to display the new add-ons from the registered provider however the demo also throws in some style rules to pretty things up with a custom icon

Notifying the UI of changes

When you implement your own provider you have to be sure to send out appropriate notifications whenever changes to the add-ons you manager happen so that any UI can update accordingly. I won’t go into too much detail here, hopefully the AddonListener and InstallListener API covers the events you need to know about enough. You can see the script database send out some of these notifications.

Get the full code

This has been a very short overview of the highlights of this demo, hopefully enough for the interested to pick up the code and make use of it themselves. The full source of the extension is available from the mercurial repository. Right now I wouldn’t really release this as an extension. As I’ve mentioned it uses synchronous sql queries (on every page load no less!) and cannot be localized. These things can be fixed but this was just made as a demo in basically one evening to show off the sorts of things that are possible with the new add-ons manager.

July 09, 2010 09:30 PM

With all of the work that has gone into the new add-ons manager for Firefox 4 I thought it would be interesting to take a quick look back at the history of this part of Firefox and a quick look at what the future may hold.

Phoenix 0.2

Even in the earliest versions of Firefox, extensions were supported using the old XPInstall style packages. These had some pretty fundamental problems though in that there was no built in support for uninstalling extensions nor any way to disable them. There wasn’t even an extension manager window to see what you had installed at first. The very first time that a list of extensions and themes appeared in Firefox was way back in version 0.2, back when the product was called Phoenix. It was a very basic user interface and appeared inside the preferences window.

Firebird 0.6

After the product got a rename to Firebird the next incarnation of the manager split the themes and extensions into separate parts of the preferences window.

Firefox 0.9

Everything changed when Firefox 0.9 came along with its standalone extension manager window and support for the new install.rdf packages which are essentially unchanged from the extension packages that are used today.

Themes and extensions were displayed in different windows and a basic update service was in place, to be improved in the backend code for Firefox 1.0. This first version was mainly written by Ben Goodger

Firefox 1.5

Firefox 1.5 saw very few differences on the surface of the extension manager, some slight changes to the visual styling along with the rest of Firefox.

Behind the scenes, Darin Fisher made large changes. He allowed the manager to support loading extensions from different locations on the system including the Windows registry. He also created the ability to just extract extensions into the profile folder, which would be detected automatically the next time Firefox ran. Rob Strong then took over ownership of the manager to get it stable for release. This also saw my first patch to the extension manager, the rather insignificant bug 307925.

Firefox 2.0

Firefox 2.0 finally combined the separate extensions and theme windows into the unified add-ons manager.

Underneath more changes were going on including the first blocklist service to allow us to remotely disable extensions that were found to be harmful to users. Since its creation we have very rarely used this feature but when it has been used it has helped prevent security exploits and crashes.

Firefox 3.0

With Firefox 3 we started including Plugins in the add-ons manager window and for the first time you could download and install add-ons from addons.mozilla.org directly within the add-ons manager. This was the first big feature that I worked on in Firefox and I’m always pretty happy when I hear from the add-ons team just how much it is used.

Internally the blocklist got upgraded to support blocking plugins and new install locations were added for platforms other than Windows to support integration with other applications on the system.

Firefox 3.5 and 3.6

No real visual changes happened in Firefox 3.5 and 3.6 however Firefox 3.5 improved the blocklist service yet again, allowing for a couple of different levels of severity while Firefox 3.6 added support for warning users about outdated plugins on their system and brought the fledgling Personas into the manager allowing quick switching between simple backgrounds for the main Firefox window.

Firefox 4.0 beta

Firefox 4 is seeing a complete redesign of the add-ons manager adding support for extensions that don’t require restarts, an automatic update system with less interruptions to the user and a more useful way to discover new add-ons.

Behind the scenes the new add-ons manager is now capable of managing new types of add-ons more easily than it was possible before.

Firefox 4.0

The user experience team are hard at work making the final designs for how the add-ons manager will look in the final Firefox 4 release. While only preliminary this is a quick idea of the sort of thing that they are going for:

In the future we have plans to bring more types of add-ons into the main manager. Things like search plugins which currently are managed by their own custom window can fit in here. We also want to simplify customizing your extensions. Although it is unlikely we would stop allowing extension developers to create their own preferences windows we are looking into adding support for changing simple settings directly in the add-ons manager rather than needing to open new window. We’re hopeful that we can set up more automated ways of updating your installed plugins which are often the cause of security and stability problems and we want to significantly improve theme selection to make it easier to see what themes are available and switch between them.

It’s possible that some of these things may even happen in time for Firefox 4.0 but time is running short to get new things in before the final release.

July 09, 2010 06:16 AM

Add-ons have really been an integral part of Firefox ever since before its first release. In fact Firefox has had an add-ons manager of some form since version 0.2 (which was at that time called Phoenix). Firefox 4 will include a completely redesigned add-ons manager and while many nightly testers will have already seen our work, now the beta release is out I wanted to talk about some of the new features it includes. If you’re interested I’m also writing a companion piece that talks about the history of the add-ons manager from its first appearance through to what the future may bring.

Changing the home of add-ons

The most obvious change that you’ll see is that the add-ons manager in Firefox is no longer a separate window. Instead it appears as a tab within the main Firefox window, just like webpages. One of the big things that I think revolutionized web browsing was the introduction of tabs to allow you to keep many webpages open in the same window. This is because in general it is pretty difficult to keep track of multiple windows. Opening one tends to block the other making it difficult to quickly switch around them unless you are very careful about where you place them all. This really applies to parts of the user interface as well as webpages themselves. With the new design you’ll never go back to your webpage to read something and have a hard time finding the add-ons manager again.

The Firefox user experience team has been talking about putting parts of Firefox’s user interface into tabs for some time now and other web browsers have done this sort of thing already. When we were redesigning the add-ons manager this was one of the first choices that we made.

Learn more about add-ons

One of the first big features that I worked on when I started at Mozilla was adding the “Get Add-ons” pane to the old add-ons manager. It was an area that allowed users investigating what this part of Firefox was for to see a list of a few recommended add-ons as well as do simple searching for add-ons listed at addons.mozilla.org and install them right there without having to open a webpage. It turns out that many use this as their main way to get add-ons, somewhere around one in five of every add-on downloaded from addons.mozilla.org comes through this pane. What we wanted to do with this redesign was to extend the sorts of information and recommendations that we can provide directly in the manager.

While still only showing a placeholder in the current beta the revamped Get Add-ons section will eventually include recommended and features add-ons, lists of the most popular add-ons as well as a short overview of what add-ons are for those who have never used them before.

Make changes without restarting

The new add-ons manager supports a new type of add-on, one that doesn’t need you to restart Firefox in order to use it. It is possible for quite a lot of extension developers to change their add-on to use this feature but perhaps the easiest way to support it is to use the new Jetpack SDK to build your add-ons. An example of an extension built on the SDK is MailPing, a simple tool to let you know wen you have new emails at your Google or Yahoo mail account.

Find the add-ons you need

Once you have a large number of add-ons installed it can be hard to find the one you are looking for if you want to make changes to it. In fact if you can’t remember whether the add-on you were looking for is a Plugin, Extension or Theme then the old manager made you look through each list till you found it. With the new manager we’ve added a few tools to help you. You can quickly sort the add-ons in a list in a few different ways. We’re also building search right in. Typing something in the search box will look through all your add-ons for you trying to guess which you were looking for. In the future this will also return results from the extensive catalogue of add-ons available from addons.mozilla.org.

See more about your add-ons

You’ll probably see that in the new manager there is room for more information about your add-ons that was previously unavailable unless you visited addons.mozilla.org. Although in the initial beta lots of this information is not real, by the time we release Firefox 4 we expect you to be able to see information about ratings and reviews (particularly important when looking for new add-ons to download) and have the ability to easily contribute to add-ons that you could not do without.

Still to come

This is all just the early betas so there is still a lot of new things to come. In particular the way the manager looks right now is the same on every platform and based on early designs. The user experience team are now finalizing how the manager should look on all platforms. Future betas will also bring better feedback for the update and install processes.

Hopefully you’ll find the new add-ons manager easier to use but either way we are always looking for feedback so why not let us know what you think?

July 09, 2010 06:15 AM

Firefox 4.0 Beta 1 includes some new web developer tools, "Console" and "Inspector".

This post will cover the Console, what it does now and the direction we  are headed with it. The developer tools team would like feedback from  web developers and others who might use these tools, so please try it out and either comment in Bugzilla, through one of our feedback tools (such as http://www.mozilla.com/firefox/beta/feedback ) or in the comments of this blog.

The Meta Bug for this Console work has a list of blocking bugs, for those who are interested.

***

What is the "Console"?

The console displays log messages, warnings and errors that originate in web pages. The current Error Console in Firefox displays messages that originate in any open web page, Firefox itself and the underlying Gecko platform code. One of the main changes we wanted to make with the new Console was to pre-filter all of the messages so you are  only seeing messages that originate in the current browser tab. You can activate the Console though Tools menu -> Heads Up Display. (The "Heads Up Display" name will be changing soon to something like "Console").

The existing Error Console is displayed in it's own window, the new Console is initiated per browser tab, and is displayed (by default) as a panel that drops down over the corresponding tab's web page. You can open the console for each tab if you want to. Each will funnel console messages about that document to the correct console.

The existing Error Console:


The new Console:


Now that we are tying the log messages directly to each tab, there is a lot higher signal to noise. This is, of course, a work in progress. There are a couple of bugs that need to be fixed before all of the messages are properly identified as being from a particular tab: bug 568034 and bug 567165.

Another goal is a rich, interactive (command line) interface that allows quick introspection of JS Objects you might be interested in.  You can execute functions, write code directly into the console command line and the output displays the result of the executed commands. We want the command line to be a very powerful tool for users to quickly find out the state of variables and the effects of function execution.
There are several bugs on tab-completion, JS object inspection and helper functions, which are under heavy development right now and should be available in upcoming betas.

Tab completion in the command line interface will allow you to easily introspect the properties of various JS and DOM objects.

Helper functions in the command line will allow developers to have a "$" function regardless of whether a "$" function is already defined. If defined, nothing happens and the developer can use her existing function. If not,  we provide a "$" that does document.querySelectAll, among other things.

The console work is just getting started. The recent addition of some additional engineers means we will be iterating quickly, so please check it out and give feedback often. You may want to use a nightly build for bleeding edge features. I will post additional "branch" builds to this blog as they are available.

Read more about this beta release on the Official Mozilla Blog
http://blog.mozilla.com/blog/2010/07/06/firefox-4-beta-1-tell-us-what-you-think/

July 07, 2010 03:56 AM

July 02, 2010 08:24 AM

Jetpack

• Fixed a failing test
• Context menu documentation clarification patchification up for reviewification
• Need to review Dietrich’s patch to a test fix

Switch-to-tab

• Patch to allow Alt+Enter on a switch-to-tab result to open that page in a new tab
• Patch to add icons to switch-to-tab results, a Firefox 4 final blocker

Other

• Patch to fix a Firefox 4 beta 2 blocker involving the add-ons manager UI and restartless extensions

July 02, 2010 07:24 AM

Most of my design time has been focused on the visual design of the interface for Firefox 4. Now that the new theme process is well underway I was able to devote some time to designing larger geolocation icons for the notification panels that recently landed.

The final icons turned out like this:

Left to Right: Windows, Mac, Linux

This is based on an idea from Alex Faaborg. Instead of just using a plain globe there are red orbital rings(LASERS!) locking onto your position. The red is in contrast to the blue of the globe. Relaying some level of warning that a website is requesting your location.

I also sketched and rendered a few other ideas that didn’t make the cut:

The final result looks like this on geolocation pages:

Once the panel styling is updated it should look more like this:

More notification icons to come in the future!

July 01, 2010 03:38 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

This is an older update that wasn’t published because I managed to break my blog in interesting ways while testing the new & very excellent Plone 4 beta release. Since it happened just before the Mozilla Summit, I didn’t have time to fix it, so I’m publishing these two older updates today too. Apologies if this is confusing anyone. The date in the header is the correct date for when the meeting happened.

---

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

New & noteworthy

This week saw tabs-on-top land for Windows, and excellent work being done all around — a surprising amount of UI code landed in time for Firefox 4 beta 1.

---

Status reports on current UX priorities:

Start Page video for the new

Alex Faaborg:

• Overall goal is to help mainstream beta testing users quickly transition to our UI changes so that they don't bounce ("where did my menu go?", etc)
• This is my top priority as we finish up beta 1
• Plan is to re-edit the video for each beta release, with it getting longer over time as we continue to introduce new features (home tab, etc.)

Notifications

Alex Faaborg:

• Currently in progress on the account manager mockups, but lower priority than Beta 1 tasks.

Firefox menu

Alex Faaborg:

• Tabs-on-top landed on Windows!
• Future work on hold until after Beta 1.

Site identity

Alex Faaborg:

• Might want to get a get mockup of this out this week.
• Lowest impact: what we have now: [site block] URL
• Moderate impact: [site block] /path
• More radical change [site block] title
• This would also address concerns about no longer placing the title in the window frame, but will highlight other edge cases.

Firefox Sync

Alex Faaborg:

• Had a meeting last week to discuss the ongoing debate of security vs. usability. Moving forward with mockups that include an automatically generated artifact for the user to save.

Tab video

Alex Faaborg:

• Press reaction was neutral (there exists a video) to positive (there exists a video, we agree with the points).
• Comment reaction was what you would expect with YouTube, Digg and Reddit.
• Limi saw a lot of awesome, finally Firefox does the right thing, FWIW

Beta Feedback button

Alex Faaborg:

• Visual changes done (thanks, Stephen!)

Home tab & App tabs

Alexander Limi:

• Meeting with Blair & Frank later today to figure out next steps and any blockers.

Download Manager

Alexander Limi:

• No changes.

HTML5

Alexander Limi:

• Did initial work on the multiple upload widget, more to come.
• Next steps: Publish the initial set of widgets, get feedback.

“Paper Cuts”

Alexander Limi:

Paper cut overview bug is here.

• Sent out email to the multi-minute startup profile people, profiles have started coming in. Keeping sdwilsh in the loop for next steps.
• Didn't get to do the Bugzilla sweep I planned. :(
• Will try to fit in some gardening this week in between main tasks.
• Any suggestions on good people to talk to about the Focus issues?

Main window refresh

Stephen Horlander:

• Drawing in titlebar landed.
• Lots of bugs and lots of fixes.
• Windows XP and Aero Basic backend coming “soon”
• Windows XP: Need to work out full window style bits.
• Bookmarks Menu Button landed.
• Mac: Buttons landed — tabs next, needs review.
• Windows: Follow-up Beta 1 with lots of polish.
• Linux Bugs filed.

In-content page design

Stephen Horlander:

• Limi & Stephen meeting Wednesday at 1pm to create the list of what pages need attention + priorities — then publish, so we can get people to help out.

Add-ons Manager

Jennifer Boriss:

• Mostly fixing beta 1 bugs, no blockers left.
• Mossop is working on wallpaper/theme selector — has implementation already, very cool!

Jetpack & the Extension Bar

Jennifer Boriss:

• Dietrich & al. working on this.
• Displays based on whether there are things to show.
• Customizable.

Privacy

Jennifer Boriss:

• Mehdi & Boriss working on the site-specific prefs.
• Mehdi posted a prototype on AMO.

TabCandy

Aza Raskin:

• Not present.

Post-Firefox 4 Home Tab

John Wayne Hill: (UX intern)

• Good amount of work done last week.
• Critique and Feedback session on Wednesday, 1pm.

Startup performance perception

Alexander Limi & John Wayne Hill

• Didn't get the wiki page created as we wanted yet — will do today or tomorrow at the latest.
• After page is created we need to talk to particular devs on how to approach each issue and then find issue champions.

Mobile

Madhava Enros:

• Sean Martell working on android theme mockups for real this week.
• incorporating  changes/ideas from last week's discussions in Mountain View for sharing UI and “unified start screen” &home-tab-esque screen.
• 1.1 (should be!) out this week.

Feedback session

Quick feedback and/or blockers; for in-depth discussions, we do design sessions on Wednesdays.

Critique and Feedback on post-Firefox 4 Home Tab, Wednesday, 1pm.

---

About the meetings

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning & dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.

June 27, 2010 11:35 PM

Some of you may have noticed we released a quick Firefox 3.6.6 yesterday (Saturday here in the states). This was created off the 3.6.4 relbranch and only included one additional fix. To be clear, anything that was previously marked as 1.9.2.6 fixed did NOT go out in 3.6.6. Confusing, I know.  I also wanted to say thank you to all those that gave up a day of their weekend and got the release out the door.

Because of the release, we moved the previous 1.9.2.6 blocking and nomination flags to 1.9.2.7, as the next released version of Firefox will be 3.6.7.

Code freeze for 3.6.7 and 3.5.11 was Friday, which means we are now frozen. There are still a bunch of open blockers! PLEASE, please take a look at these lists and see if you are on the hook. Even though we are frozen, we will be approving fixes for blockers (mostly security fixes) on an ad-hoc basis if they come in early enough in the week.

• Open blockers in Firefox 3.6.7
• Open blockers in Firefox 3.5.11

June 27, 2010 07:58 PM

Jetpack

• Improved the byte streams API
• Documented more of the life cycle API
• Posted a trivial cleanup patch but derailed by memory leaks, investigation

Switch-to-tab

• Landed patch to show pages in the awesomebar only once, as switch-to-tab, if they’re already open

Other

• Fixed a toolkit favicon bug that came up while Dietrich was working on Jetpack’s tabs API
• Attempted to fix a JS bug involving Unicode error messages that grieves Jetpack, failed

June 26, 2010 08:24 AM

On Monday I finally landed the new “PopupNotifications” JS module, used to display popup-style notifications (as discussed earlier). Since then I’ve spent some time fixing followups, but there’s still a bunch of work to be done (including fleshing out the MDC documentation and trying to find help making menu-buttons nicer). Dave‘s already got a patch up to use the new notifications for the Addons Manager, and Robert is working on getting them working in SeaMonkey.

I completed some reviews, including some for relatively exciting patches from Dão:

• Turning on and fixing the position of the “Firefox” menu button on Windows Vista/7
• Making tabs-on-top the default on Windows (see Alex’s post for more details)

I also spent a bit of time reviewing fixes for dolske‘s prompting code rewrite that landed last week as well as cleaning up the new HUD panel‘s styling.

Next week, I plan on trying to wrap up as much of the notification-related stuff as possible, and move on to getting some patches up for the Account Manager work. Also need to do a bit of prep for the Summit which is coming up quickly!

June 26, 2010 01:36 AM

Progress:

---

• Landed on trunk mozilla-central and comm-central for all applications Bug 367539 [Toolkit] – When upgrading an existing install use the uninstall.log to uninstall the previous version before install [Windows] and created patches for the 1.9.1 and 1.9.2 branches. To support removing files when installing on top of (e.g. a pave over install) the removed-files list used by application update was processed during build time to create a file that is read by the installer to know which files should not be present in the new installation. This works ok for upgrading to a newer version but fails badly when downgrading to a previous version and we would mitigate that updating the removed-files list for the previous branch’s next release to include the new files in the latest branch so they would be removed. Now the installer will remove the previous installation’s files and directories using the uninstall.log as follows:
  1. file deleted if possible.
  2. file can’t be deleted and can be renamed it is renamed and deleted on OS reboot.
  3. file can’t be deleted and can’t be renamed.
  • if the file exists in the installer it is replaced by the file in the installer on OS reboot.
  • if the file doesn’t exist in the installer the file is deleted on OS reboot.
• Landed on trunk Bug 571387 [Toolkit] – Use the official Unicode UAC and ShellLink distributions [Windows]. For Firefox 3.5 Unicode versions of these NSIS plugins were needed but the official distributions for the plugins didn’t have Unicode versions. Now that there are official Unicode versions for these plugins the modified source was removed from other-license in mozilla-central and the official versions were added.
• Landed on trunk Bug 569058 [Toolkit] – Upgrade NSIS version to 2.45 or later (PCA complains when installer / uninstaller is cancelled on Windows 7) [Windows]. This actually just prepares the installer code for upgrading MozillaBuild to include NSIS 2.46 Unicode which will be done in Bug 569534 [mozilla.org] – Add NSIS 2.46 Unicode to Mozilla Build [Windows] and Bug 570473 [mozilla.org] – Release MozillaBuild 1.5 [Windows]. Once these bugs have landed and the build systems have been upgraded to the latest MozillaBuild it will fix PCA from complaining and also fix Bug 506867 [Toolkit] – /S command line option for silent installation is broken – fixed in the latest NSIS [Windows].
• Landed on trunk Bug 572224 [Toolkit] – Remove check-locales.pl [Windows]. The check-locales.pl perl script was added to simplify a bunch of locale changes for the installer and is no longer necessary now that I’ve removed all of the call sites.
• Landed first patch to remove perl scripts that are no longer used on trunk, received r+ on all of the comm-central changes, and submitted for review the two remaining patches for Bug 570689 [Toolkit] – Convert preprocess-locale.pl to a python script [Windows]. A couple of other patches I’ve landed removed all of the installer perl scripts except for the preprocess-locale.pl script which I have completed converting to python. There used to be three perl scripts that were not used, one unused perl module, and three used perl scripts (two of which I was able to remove the usage of). Soon there will just be one python script… yay!
• Landed on the 1.9.1 branch for Firefox 3.5.11 and 1.9.2 branch for Firefox 3.6.6 Bug 522065 [Toolkit] – PCA complains when installer is cancelled [Windows].
• Landed on 1.9.2 branch for Firefox 3.6.6 Bug 552617 [Toolkit] – A paused update can’t be resumed when closing the window using a window manager control [All]
• Landed on the 1.9.1 branch for Firefox 3.5.11 Bug 574041 [Firefox] – Need to update the 3.5.11 removed files list with files added by the latest 3.6.x [Windows]. This should be the last time this has to be done contingent on approval / landing of Bug 367539 [Toolkit] – When upgrading an existing install use the uninstall.log to uninstall the previous version before install [Windows] on the branches.
• Landed on mozilla-build Bug 569534 [mozilla.org] – Add NSIS 2.46 Unicode to Mozilla Build [Windows]. This also removes the NSIS version we used in 1.9.0.x which does not support Unicode.
• Received r+ for Bug 568904 [Toolkit] – Don’t perform a shell refresh when there are no shortcuts for the install location when updating app modal id’s [Windows 7].
• Pinged dveditz again about Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All]… specifically waiting on his additional feedback. Time available to finish this up is getting short.

Future targets:

---

• Continue working on silent / background update for Windows.
• As soon as feedback is provided by dveditz finish the patch for Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All].
• Get review for and land Bug 570689 [Toolkit] – Convert preprocess-locale.pl to a python script [Windows].

June 26, 2010 12:12 AM

Just a reminder that code freeze for Firefox 3.6.6 and 3.5.11 is TONIGHT @ 11:59 pm Pacific time.

If you have any bugs in these queries, we need your attention on them ASAP (if you aren’t in the critical path for Firefox 4 beta of course):

• Firefox 3.6.6 blocking bugs that do not have an approved patch
• Firefox 3.5.11 blocking bugs that do not have an approved patch

If you don’t think one of your bugs should be blocking, please say so in the bug or email me directly.

If you have any bugs in these queries, your patch needs to be landed:

• Firefox 3.6.6 approved bugs not marked as fixed
• Firefox 3.5.11 approved bugs not marked as fixed

These bugs have the checkin-needed keyword and it would be great for other people to land them:

• Firefox 3.6.6 checkin-needed
• Firefox 3.5.11 checkin-needed

Ehsan and Reed may beat you to those checkin-needed bugs though!

June 25, 2010 09:01 PM

If you are a Makefile guru or just have a bit of spare time to slog through Makefile syntax, take a crack at:

• Bug 567134 – Use ASLR in NSS if it’s available

This bug (combined with Bug 559133 – Use ASLR in NSPR if it’s available) will go a long way to hardening Firefox!

If we could get a patch landed for Firefox 3.6.6 (code freeze is tonight!) it would be AMAZING.

June 25, 2010 04:26 PM

June 25, 2010 02:23 PM

This week I put some more finishing touches on the Style Panel patch and the DOM Panel, which should be ready for landing this week to squeak into the first Beta of Firefox 4. While doing that, I rebased my patches for the new tree panel and fired off a try build for you to play with.

Grab it here: Inspector Milestone 0.5 Preview.

Other work that’s moving along nicely:

• Neil Deakin’s ongoing improvements to XUL Panels.
• David Dahl’s work on the Heads Up Display
  
• Firefox 4 Theme work is beginning to land

… Just to name a few.

We also picked up some help from some members of the Bespin team this week. We’re still figuring out what people are going to work on, but it looks like Julian Vierick is going to do some Inspector<->Console cross connection stuff with the DOM Panel. And maybe, just maybe, Joe Walker is going to help me make the Inspector look pretty. I am hopeful.

Give the preview a try and let me know what you think. Feel free to file bugs in Firefox::Devtools.

Update: After the rebasing, I’ve cloned another user repo for ongoing work. It’s too much of a pain to reintegrate patches from a point in time and merge everything together in a way that won’t mung up a future extraction. And cloning is cheap. If anyone has a good idea of how to “applepick” in hg, I’d love to hear it.

New repo is here: http://hg.mozilla.org/users/rcampbell_mozilla.com/mozilla-inspector-3

June 24, 2010 01:13 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

---

New & noteworthy

This is the final week before we do the code freeze for Firefox 4 beta 1, and some UI changes have started making their way into the nightly builds.

There will be several more betas before Firefox 4 enters the release candidate stages, and we’d like to make it very clear that what’s in Firefox 4 beta 1 is not feature complete — neither on the UI side, nor on the functionality side. Mozilla subscribes to the “traditional” definition of beta releases — they are checkpoints where we lock down the code & functionality of the product, ship it to our testers and volunteers, and get feedback on selected parts of the whole picture. This isn’t like Gmail, which was “in beta” for 5 years, and most people were using it as their main webmail account anyway.

The main things to keep in mind for the upcoming beta 1 release of Firefox 4 on the UX front are:

• The UI is not in any way close to the final shipping product, as most of the work done so far has been infrastructure work that can support the new menu approach, the new theme, & cetera.
• The platform differences will be quite large, Windows will have features that do not exist in the Mac OS X version or the Linux version. This doesn’t mean we love any of these platforms any less, or that we’re not implementing those improvements on those platforms — just that the features and UI changes tend to land at different times on different platforms.
• If something seems wrong, it probably isn’t done yet — that doesn’t mean that you shouldn’t tell us about it, just that you can expect a lot of UI weirdness in the early betas.

If you have any confusion as to how your platform is intended to look or work, please consult the Windows, Mac OS X or Linux mock-ups that Stephen Horlander has lovingly provided to give you an idea of where we’re heading over the next few months.

If all that was too vague for you — the general rule is: Don’t Panic. Beta 1 will be a rough beta as far as the UI is concerned — but with much awesomeness on the infrastructure front — and later betas will be a much closer representation of how Firefox 4 will look and work.

---

Status reports on current UX priorities:

Notifications

Alex Faaborg:

• Need to work with Stephen for an update on icons and styling.

Firefox menu

Alex Faaborg:

• Need to file a few follow up bugs on things that are missing:
  • Private browsing,
  • Bookmarks submenu,
  • Developer submenu,
  • About and check for updates,
  • Icons for significant item in each section.

Site identity

Alex Faaborg:

• No owner for beta 1, this is okay for now.

Firefox Sync

Alex Faaborg:

• Main priority this week.

Tab video

Alex Faaborg:

• Complete, will be published later this week. (…and there was much rejoicing!)

Beta Feedback button

Alex Faaborg:

• Inactive from my side, but need an update from Jingua and Aakash this week.

Home tab & App tabs

Alexander Limi:

• Stuck in the review queue at the moment, Dão & Blair have different approaches, Johnathan is on it.
• There’s no UI to play with for app tabs until it gets unstuck.
• Unlikely to make beta 1 release, this is okay.
• Marco is at a natural stopping point with the home tab content, waiting for unrelated non-code coordination.
• Limi & John Wayne should talk to Engagement team about requirements for snippets and messaging.

Download Manager

Alexander Limi:

• No change, still opportunistic.

HTML5

Alexander Limi:

• Setting up a meeting this Tuesday to discuss the HTML5 chrome buttons & app tab implications (Section 4.11).
• Wireframing of individual widgets.

“Paper Cuts”

Alexander Limi:

Paper cut overview bug is here.

• Posted Paper Cuts update post, called out some new targets and talked about current work being done by the team.
• Posted to Reddit asking for broken profiles, already have quite a lot of good feedback & volunteers with multi-minute startup profiles.
• Next steps: A round of janitorial work to make sure things are in good shape, as I haven’t had time to follow bugmail for the past week or so, as well as get the profile analysis going.

Main window refresh

Stephen Horlander:

• Filed Linux Bugs.
• Updated Linux Mockups (again)
• Ongoing email discussion with some Linux developers.
• New Mac patches undergoing review (may make beta 1).
• First stab at new Bookmarks Menu finished, awaiting review
• Working on some last minute polish.
• Jim Mathis posted several patches for drawing in the titlebar.
• Code freeze on Wednesday to make a release before the summit possible.

In-content page design

Stephen Horlander:

• Horlander & Limi to put together a list of what we want to change, and priorities, so we can get assistance from the community on implementation.

Add-ons Manager

Jennifer Boriss:

• Bit of a crazy last week getting together last bets for beta freeze.
• Icons found & created for freeze — props to Faaborg for being master of files in toolkit.
• Final graphics work still going on — want to get Vista done this week, the rest should model off that.

Jetpack & the Extension Bar

Jennifer Boriss:

• Blogged about add-on placement based on feedback from design session with Limi & John Wayne.
• A few problems became clear:
  • Asymmetrical browsing area caused by small status bar not acceptable - bottom right area prime real estate in website design.
  • Need either modification of UI or different UI for touch devices with no hover state.
  • Need a way in UI to open/close bar that works for all operating systems and in fullscreen mode.
• Recommending a few tweaks:
  • Status bar (still) off by default.
  • All add-ons with UI that request the status bar turn the status bar on.
  • Status bar has constantly-visible minimize button.
  • A button still brings the status bar back out - what that looks like the remaining piece of the puzzle, but likely different depending on OS.

Privacy

Jennifer Boriss:

• Missed goal last week to blog about designs — will this week or owe a round of beer.
• Been talking with Mehdi about Summit workshop — will be about 15-20 minutes presentation, 20+ minutes discussion, Q&A, ideas.

TabCandy

Aza Raskin:

• TabCandy 0.4 released: jQuery-free and much faster.
• New Bugzilla Tracker!
• Cannot use HTML5 drag-and-drop (non-settable ghosting or snapping).
• Got a change to CSS transitions spec to allow bounce animation.

Post-Firefox 4 Home Tab

John Wayne Hill: (UX intern)

• More concept work this week. Plan is to present next week.

Startup performance perception

Alexander Limi & John Wayne Hill

• Lots of articles and posts about John Wayne’s blog post
• (Re)starting and expanding the "Startup Experience" focus, want to get feedback on the list today, see below.

Mobile

Madhava Enros:

• Sean Martell is working on Android theme mockups this week.
• Will be publishing the 1.1 field guide with 1.1 release.
• Working with front-end developers to build out the project details pages (and do some subdividing into subprojects) this week - see Planning 2.0.
• Incidentally, looks like we’ll have to use our own mechanism for sharing on Maemo/Meego (example).
• In Mountain View this week, so would like to talk to UX team about the home tab, notifications & modal dialogs amongst other things.

Feedback session

Quick feedback and/or blockers; for in-depth discussions, we do design sessions on Wednesdays.

Startup Experience

Alexander Limi:

Here are some ideas of things we should/could look at:

• Track and refine the current work on recording perceived startup time.
• Enumerate which dialogs can get in the way of starting the browser, and make sure their respective projects are getting them removed (add-on updates, application updates, etc)
  • “Get in the way” in terms of time vs. distraction — some notifications (dialogs should all be phased out in 4.0) may make sense to show on startup, simply because the alternative is a relatively random point in the browsing session.  There may be ways to at least assure that these won’t affect startup time.
• Get some “broken profiles” from the community — ie. the ones that cause multi-minute startup times, etc — and get them analyzed and figure out what to do (reconstruct the profiles, fix the bugs causing them, examine if there’s any data loss, etc). I’m asking for these profiles on Reddit, since I had a good experience asking there last time.
• Add additional criteria for startup performance:
  • Time to focus in the URL or search bar.
  • Time to complete the first address entry (URL or Title match).
• Session restore performance, how quickly can you start using the browser:
  • Cascading page loading, ie. restrict loading to 2-3 pages at once to keep the browser usable even when restoring 100s of tabs.
• Switch prioritized tab on-the-fly if user selects a different one while loading.

• Progress bar:
• Frontmost tab has very visible, fast progress bar.
• Separate progress from activity (ie. “when can I interact with the page”).
• I’m sure there’s lots more we can track and improve. Suggestions very welcome.

Our goal would be to keep track of these goals, post updates and encourage people to get involved in fixing them. Find people that might know how to fix this. Stuff we can’t figure out how/if we can do: bring up at Firefox Development meetings.

Other topics covered

• Jennifer Boriss is out of the office on Thursday and Friday.

Questions for the Firefox Development Meeting

• Open call for reviews on the theme work, get list from Stephen which ones are critical & which are nice-to-have.
• Shout out to Jim Mathis for getting drawing in titlebar done early in the week!

---

About the meetings

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning & dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.

June 23, 2010 08:05 AM

Firefox 3.6.4 was released today! This version of Firefox has out-of-process-plugins (OOPP) for Linux and Windows users. Check out the announcement for more info.

Thank you to everyone that worked so hard over the last couple of months to make this release happen. I know OOPP will be a huge win for Firefox users and will make browsing better all around.

Community testers, release engineering, QA, Firefox and platform engineering, and others did amazing work to make this release solid and release it into the hands of our users.

There were a lot of “firsts” for this release and I believe we learned a lot. I’ll be giving a talk at the Mozilla Summit summarizing what we learned and how we can apply it to future releases, so if you are interested in the nitty-gritty check it out!

Thanks again to everyone for their hard work!

June 22, 2010 09:54 PM

Today, the web console code attached to bug 534398 landed on mozilla-central. This means that starting with tomorrow's  nightly, you will have a new "Heads Up Display" console to tinker with:


If you are interested, the Meta bug is here

There are a number of followup bugs that need to be addressed, the list is here:

Console Bugs

There is a lot of work to do yet, including some platform work. Two glaring bugs are:

"When reporting errors, warnings, etc... to the consoleService, report the originating window or context "

The existing errorConsole in Firefox has messages sent to it that do not know what tab the error originated in. We really want to isolate all messages you see to the tab you care about as a web developer. It becomes tedious to try and watch the scrolling messages at times if a "noisy" page is loaded in one of your 200 open tabs. So you will notice that not all errors are displayed in the console.

and

"create event or method to determine the source contentWindow of loading images and media"

In Firefox, images are loaded differently than script, css and html pages, so much so, that it is difficult to trace these image loads back to the originating tab as well.

Once these two bugs are fixed, your console messages will be very accurately focused to the tab you care about.

The console itself has the standard API: console.log, console.info, console.warn and console.error.

This initial landing into Minefield nightly will hopefully generate some valuable feedback from web developers and Mozilla developers alike. Please do not hesitate to comment here or even better in bugzilla.

Cheers,

David

June 22, 2010 09:08 PM

A lot of Mozilla developers and volunteers these days are using checkin-needed keyword to find a checkin-buddy that can help them pushing their amazing stuff on mozilla-central (or other release branches), and maybe you're among them.

This is really cool and everybody is more than happy to help you completing your work, because we all benefit from it. But, there is something you can do to help people pushing your patch.

Here is some hint to speed up the landing of your checkin-needed patch:

• Set yourself as author of the patch. Maybe you don't know that Mercurial can do this for you if you use Mercurial Queues (And you should really use them). Just edit your Mercurial.ini or $HOME/.hgrc adding an uppercase -U option to qnew command, it will set hg username (you) as author of any qnew patch (username setting is under [ui]):
  

  [defaults]
  diff = -p -U 8
  qdiff = -p -U 8
  qnew = -U

• Set the title of the patch, again if you use Mercurial Queues this is really easy, ensure the patch you want to edit is the current one with hg qtop, then hg qrefresh -m "Bug 12345 - Test bug", otherwise hg qrefresh -e will launch your editor where you can just type-in or paste title, save and close editor. You can set a default editor in [ui] section of Mercurial.ini or $HOME/.hgrc.
• If the bug includes more patches and not all of them should be pushed, use the whiteboard to specify which patch is ready to be pushed.
• If the patch should be pushed to a specific branch (like comm-central, or a project branch) rather than mozilla-central (or a release branch) use the whiteboard to specify where the patch should be pushed.
• Before asking checkin-needed pull the latest branch and ensure your patch applies cleanly. Bitrotted patches usually take more time before being pushed. With Mercurial Queues you can just hg qpop -a, hg pull, hg update default, hg qpush (repeat hg qpush for all patches in queue), fix patches and qrefresh them one by one if you notice failures, then attach updated patches.
• You can directly attach the patch that lives in /your_repository_folder/.hg/patches/mypatch.diff to the bug, or even better export the top applied patch in the queue with hg export qtip > path_to_temp_patches/exportedpatch.diff and attach this file (the latter method should guarantee 8 lines of context for easier reviews).

These small steps will take you just a few seconds, but will save a lot of work to people willing to help you.

Thank you for you amazing contributions.

June 22, 2010 12:51 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

A while back, I gave a presentation here at Mozilla based on feedback from a question thread posted to the Reddit web site: “I work on the Firefox User Experience team, and this is your chance to tell me about your pet peeves.”

We got over 2 000 — yeah, that’s two thousand — replies, and spent some time analyzing and grouping the feedback into actionable bug reports and general focus areas, which was then presented to the Mozilla team and worldwide community in a talk here in Mountain View & broadcast on Air Mozilla.

Unfortunately, the video recording was broken that day, but you can view the presentation slides in HTML5 format here. Copious amounts of presenter notes were added after the presentation was given, so you should be able to follow it even if you can’t see the recording.

The result of this presentation was that a number of bugs were filed under a “Paper Cuts” umbrella — in other words, the small, annoying issues that you encounter every day in any software — and an effort was started as part of the Firefox 4 effort to eliminate as many of these as we can during the beta period. They are similar in nature to what was called “polish” bugs in the Firefox 3 release cycle, but intentionally narrowly scoped, and managed aggressively to ensure that we have a smaller list that can be worked on.

What’s so special about Paper Cut bugs?

I’m glad you asked! The paper cut bugs are issues that are of particular importance to the User Experience team, and as such, we will give priority to help you fix these bugs. It means that we’ll go the extra mile to try and support anyone that helps us with fixing them — so please have a look at the list and see if there’s anything you think you’re capable of fixing, and feel free to contact me directly or post questions in the bugs themselves if you need clarifications or help.

Some paper cut bugs are complicated and require some re-architecting — for instance, the modal dialog issues currently being handled by Justin Dolske & others — but a lot of them are small, self-contained, and the perfect thing to work on while you’re waiting for review for other projects.

Our overall priorities

Of the 7 focus areas identified in the presentation, we chose to focus on two areas in particular for Firefox 4:

• Startup experience
• Focus issues

This doesn’t mean that the other bugs are any less important — but we obviously have to pick our battles to get stuff done. Don’t let this discourage you from handling bugs in the other focus areas, though!

Our current Paper Cut Heroes

Several of the bugs have seen significant activity over the past month, and I’ll try to call out progress and general awesomeness over the coming weeks. Currently, excellent work is being done on:

• Eliminate modal dialogs — Justin Dolske & others have been working on moving all dialogs to be tab-specific instead of window-specific. This means that HTTP authentication dialogs and JavaScript pop-ups no longer force you to answer them before you can switch to a different tab.
• Application updates in the background — Rob Strong is currently working on a service that downloads & applies Firefox application updates transparently in the background, which means you don’t have to wait for the “Firefox is applying your updates” dialog when starting the browser anymore.
• Add-on updates in the background — Dave Townsend, Jennifer Boriss and the rest of the team behind the new add-ons manager have made sure that updates to add-ons are less annoying, and don’t happen on startup anymore. You can still turn on explicit notification of updates if that’s how you roll, but it’s now automatic and transparent for most people.
• Improved tab behaviors — Our intern extraordinaire Frank Yan has been submitting patches to eliminate spurious trackpad input (“fake bounce”) and several other improvements to tab handling.

…and lots of other issues, more updates to come in the next few weeks.

Want to help out?

This week’s selection of paper cuts that we are currently looking for help in resolving:

• Bug #78414 — Application shortcut keys (keyboard commands such as f11, ctrl+t, ctrl+r) fail to operate when plug-in (flash, acrobat, quicktime) has focus. This is mostly working on OS X, but Windows still has this problem. In general, any qualified keyboard shortcut shouldn’t be sent to the plugin, but go to the browser.
• Bug #566489 — Enable inline autocomplete again for URLs, but make it smarter. With the introduction of the Awesome Bar, we stopped “Speaking URL,” which affects our perceived performance, since it takes longer to enter a URL than it did before.
• Bug #492544 — Add “Paste & Go” + “Paste & Search” to context menu on location field + search field, respectively.
• Bug #565104 — Stop sites from opening popup or popunder windows, even in response to clicks. There’s a new type of “pop-under” that seems to be done by triggering a window open and then quickly focusing back on the current window. There’s no conceivable use for this in a web page/app, so this order of events should be detected, and disallowed.
• Bug #565760 — “Forget this password/login” on right click. It should be possible to remove a saved password from a form that is currently storing it.

If none of these issues tickled your fancy, take a look at the full list of paper cut bugs (tree view) — and pick something to fix!

---

Overview of paper cuts

Here’s a quick overview of the focus areas we are trying to fix, along with links to the bugs that collect these in focus areas:

Focus issues

Tracked in bug 565510, contains items such as:

• Web sites should not be able to steal focus when in chrome
• Flash, PDF and other plugins steal focus shortcuts, can’t open new tab using keyboard when inside a YouTube video or a PDF, back button stops working
• Avoid app-modal dialogs, make them tab-modal

Startup Experience*

*Not what you think, focus on perceived performance instead of milliseconds for startup time.

Tracked in bug 565511, contains items such as:

• Rebuild profile on upgrade/reinstall
• “Firefox is open but not responding” alert
• Don’t ask about updates all the time
• Ideally: upgrade in the background — if not, upgrade at shutdown, not startup!
• Shutdown takes a long time for some users (30-40 seconds)
• Include BarTab-like behavior by default
• Put “Restart” and “Restart & Save Session” in “Exit” combomenu in the new design?

Being in Control

Tracked in bug 565512, contains items such as:

• Control over audio in tabs!
• Web sites shouldn’t be allowed to resize windows they didn’t create (i.e. main window)
• Pop-under ads are back, worse than ever
• Put the user in control of generated windows
• Opening new windows should be user-controllable
• SSL: Add an “I know what I’m doing” option to self-signed certs
• Include option to delete Flash cookies
• Fix Master Password
• Don’t let a web app be able to lock up a tab
• Browse-by-name is inconsistent and confusing
• Make a hotkey to list shortcuts + show them in the right-click menus
• Enable autocomplete again, but make it smarter
• Better preview, especially for PDF & types we already have viewers for

Add-ons Plug-ins

Tracked in bug 565513, contains items such as:

• Don’t wait 3 seconds when installing add-ons from AMO or the inline add-ons browser
• When an add-on is outdated / no longer maintained or working, suggest alternatives
• Click-to-activate for plugins — default for rare-but-perf-killing things like Java
• Don’t let add-ons open new pages
• Don’t let apps install add-ons without consent
• Fix the crufty status bar, extensions add clutter

Tab Behaviors

Tracked in bug 565515, contains items such as:

• Opening tabs at the end when new & next to when context-triggered is confusing
• New tabs should keep history from the tab that spawned them
• Tab behavior is very personal, expose more prefs here
• Make it easy to close lots of tabs
• Fix tab stack ordering
• Fix Ctrl-tab to use stacks, so it can be used to compare between 2-3 tabs
• Tab reloads when it is detached; this is annoying and unexpected/dangerous
• Don’t separate windows and tabs in the undo stack
• Let me fit more tabs in the bar, make it easier to find the ones I can’t see
• Blank tabs when clicking should never appear
• Can we fix the "Cmd-click window void"?
• Let me have Private and normal windows at the same time
• Ask when hitting ⌘Q
• Better load indicators — separate activity from progress
• Detect whether your webmail client is already open, don’t open new window
• Eliminate fake “bounce” when scrolling tab bar, you can’t see when you’re at the end

UI&

Tracked in bug 565517, contains items such as:

• Make search field tab-specific & clear when navigating away from results page
• Find in page should to be page-specific, and close when you click outside it, move to top
• Change “Save” to “Download”
• Work offline must die
• Fix downloads!
• Fix mess + ordering in contextual menus; common options first
• “Search Google for…” context menu entry should be in textareas & inputs too
• Fix selection behaviors
• “Paste & Go”; “Paste & Search”
• A useful full-screen browsing experience
• Make Personas work better with the default theme, make them easy to remove
• Favicons on OS X bookmarks toolbar + multiple rows supported

OS

Tracked in bug 565518, contains items such as:

• Multiple screens behavior on Windows is wonky, can we fix?
• Additional Win7 features: Jump lists, windows in Aero Peek, download progress
• Enable NTLM authentication for intranets
• MSI installer with group policies
• Hard to assign default apps on Linux
• Use of Keychain on OS X

June 20, 2010 11:00 PM

I’m on holiday today (6/18) and Monday (6/21)

Progress:

---

• Landed Bug 570066 [Toolkit] – Update UI dialogue box in Firefox disappeared before Firefox could be updated. [Windows 7].
• Pinged dveditz about Bug 544442 [Toolkit] – ‘Add support for signed AUS update snippets [All]‘… specifically waiting on his additional feedback.
• Discovered that Bug 552924 [Toolkit] – Allow distinguishing Universal ppc/i386 from Universal i386/x86_64 builds in AUS request [Mac OS X] will require fixing Bug 572125 [Core] – macutils impl should provide info to distinguish which universal binary distribution is being used [Mac OS X] first.
• Landed Bug 570680 [Firefox] – Remove call to check-locales.pl for Firefox [Windows 7].
• Landed Bug 572221 [SeaMonkey] – Remove call to check-locales.pl for SeaMonkey [Windows 7].
• Landed Bug 572222 [Thunderbird] – Remove call to check-locales.pl for Thunderbird [Windows 7].
• Landed Bug 572225 [Calendar] – Remove call to check-locales.pl for Sunbird [All].
• Received r+ and Mossop landed an app update test fix that broke due to changes in Bug 562795 [Toolkit] – Sorting by name in the digest view is case-sensitive for all types of add-ons [All].
• Received r+ for Bug 572224 [Toolkit] – Remove check-locales.pl [Windows 7].
• Received r+ for the first patch for Bug 570689 [Toolkit] – Convert perl scripts to python [Windows 7].
• While working on silent / background update for Windows I ran into Bug 572162 [Toolkit] – Remove requirement for app dir to be under program files for UAC elevation [Windows 7]. I have a patch but I don’t want to submit it until I flush out how this will interact with silent / background updates. Also discussed the high level process with several people during the week for a sanity check.

Future targets:

---

• As soon as feedback is provided by dveditz finish the patch for Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All].
• Land Bug 572224 [Toolkit] – Remove check-locales.pl [Windows 7].
• Land first patch for Bug 570689 [Toolkit] – Convert perl scripts to python [Windows 7].
• Hope to get review and land the following after Jim Mathies is free from his beta work
  • Bug 569058 [Toolkit] – Upgrade NSIS version to 2.45 or later (PCA complains when installer is cancelled on Windows 7) [Windows].
  • Bug 571387 [Toolkit] – Use the official Unicode UAC and ShellLink distributions [Windows 7].
• Hope to get review for Bug 569534 [mozilla.org] – Add NSIS 2.46 Unicode to Mozilla Build [Windows 7] and finish up Bug 545294 [mozilla.org] – Add WiX Toolset to Mozilla Build [Windows 7] so Ted can finish up Bug 570473 [mozilla.org] – Release MozillaBuild 1.5 [Windows 7].
• Continue working on silent / background update for Windows.

June 18, 2010 09:00 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

For those of you interested in collaborating with the Firefox UX Team, we are now syndicating any activity in our file repository as part of the Planet UX feed.

This means that you can keep track of any new work, changes to existing files, and generally see more of the day-to-day workings of the Firefox UX Team.

You’ll soon start seeing entries like this in the feed:

Firefox UX file repository: 68855: [shorlander@mozilla.com] Mac Firelight Mockups Updates

In the above case, it means that Stephen Horlander has checked in some updates to the Firelight Mockups. By clicking the link, it will take you to a page where you can download the files related to this change.

If you want to subscribe only to the file repository changes, you can do so using this link. Since we don’t syndicate this to Planet Firefox or Planet Mozilla, that’s probably your best option if you follow those, but still want to see the file updates.

Hopefully this makes it easier for you to see what we’re currently working on, as well as making it possible to re-use our work for Mozilla-related projects. We’re looking forward to see what comes out of this, especially from people that want to help out & improve on existing graphics or mock-ups.

June 17, 2010 08:00 AM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

---

New & noteworthy

Several pieces of the UI for Firefox 4 have started landing in the nightly builds in preparation for the upcoming first beta in a couple of weeks. Most of the elements are still a bit rough — and not in their final form or position — but it’s very exciting to see it all come together. Download a nightly build if you’re interested in testing the current state. Windows is the platform that has landed the most changes so far, hopefully Mac & Linux will follow shortly.

---

Status reports on current UX priorities:

Notifications

Alex Faaborg:

• Gavin is waiting on reviews for the Geolocation work.
• Need to ping Stephen Horlander about 64×64 icons.
• Need to brief Dolske & Frank on account manager, HTTPauth & password manager mockups — account manager mockups are brand new!
• Need to hear back from Neil on platform changes — not required for beta 1, though.

Firefox menu

Alex Faaborg:

• Landed in the nightly builds! Implemented as a toolbar for now, but a good start.
• The lack of edit controls in beta 1 is considered to be okay as a temporary tradeoff, since right-click & keyboard shortcuts work as usual.
• Need to start moving towards a panel instead of a native menu to get the right apperance, will get new high fidelity mockups done.

Site identity

Alex Faaborg:

• No changes last week, we are in an acceptable state for beta 1, though.

Firefox Sync

Alex Faaborg:

• Met with Ragavan, MConnor & Justin to discuss our approach to strong privacy versus convenience & user understanding.
• Going to work on a series of mockups at different levels of security: Single password with really good feedback vs. automatically generated military grade passphrase that you have to save.

Tab video

Alex Faaborg:

• Filmed the opening last Friday.
• Audio narration finished over the weekend.
• Should have first draft ready today, just editing & tweaking in After Effects left.

Beta Feedback button

Alex Faaborg:

• Updated mockups for Jingua.
• Somehow we got back to a double notification per study (but single opt-in before sending)
  • Beltzner mentioned that his impression was that we had always been at double notification, the issue was double-opt-in — for privacy reasons we must start notifying when we begin collecting information, don’t think we want to move away from that.
• Implementation is waiting on panel notification changes? Gavin & Jono need to chat.
• Again, need to hear back from Neil on platform changes — but not required for beta 1.

Home tab & App tabs

Alexander Limi:

• Blair’s initial implementation of app tabs is up for review.
• Home tab is being worked on by Marco, current focus is on reusing the search engine strings from search service, which should be the last remaining thing to fix before the simple implementation of the start page is ready.
• Current implementation of Home tab should be simple enough to backport to 3.6.x if required, according to Marco.
• Question: whats the plan for getting app tabs for home page customizations?
• Limi to Clarify with Marco whether the app tab part of the Home tab is going to make it into beta 1 — or whether it’s just the locally hosted start page.

Download Manager

Alexander Limi:

• Nothing new since last week, Mehdi’s patch for library location & correct content type icons still waiting for review.

HTML5

Alexander Limi:

• Posted HTML5 constraint validation mock-ups.
• Next steps: Start designing the individual widgets.

“Paper Cuts”

Alexander Limi:

Paper cut overview bug is here.

• Frank Yan posted a patch that enables multi-selection & range selection of tabs, very cool.
• Next steps: Blog post today! Aim to highlight solved issues, what we should target next, and exciting work that is ongoing in this area — as well as talk about which groups we should prioritize.

Main window refresh

Stephen Horlander:

• Initial Firefox Button landed in the nightly builds! Is implemented as a toolbar for now, but will be moved once we can draw in the title bar.
• Bookmarks Menu Button has an almost-final first iteration patch up for feedback.
• Mac theme improvements are being reworked by Markus to pass review, hopefully they can land before beta 1, but not considered a blocker.
• Updated mockups for all platforms: Mac theme mock-ups & Linux theme mock-ups.
• Jim Mathies doesn’t expect draw-in-titlebar patches to be available until next week; this will either push back beta1 or we need to come up with an alternative — more discussion below.
• Blizzard contacted Red Hat, Ubuntu & Suse people for feedback on Linux theme work.
• Stephen should file a bug for switching tabs-on-top to default on trunk.

In-content page design

Stephen Horlander:

• No changes since last week.
• Need to update/create a project page.

Add-ons Manager

Jennifer Boriss:

• Final in-content design is scheduled to land after beta 1.
• Final pixel-perfect graphics being developed, Windows due this Thursday.
• Handled some last few bugs before code freeze.
• Blogging this week about what won’t make beta 1, and what will.

Jetpack & the Extension Bar

Jennifer Boriss:

• Blogging & a very helpful design session last week, know what to do next now.
• Met with Dietrich last Friday to talk about changes, he’s already working on it.
• Finishing up blog post that documents those changes.

Privacy

Jennifer Boriss:

• Last week: Sketching, planning Summit breakout session with Mehdi.
• Need to blog about mock-ups this week.

TabCandy

Aza Raskin:

• Removed all of jQuery from the code base, now using iQ.
• Working on getting more control over animation timing.
• Saw the first hardware-accelerated operations, is very smooth, but crashy. It does go to 11, though!

Post-Firefox 4 Home Tab

John Wayne Hill: (UX intern)

• Completed lots of sketching.
• Looking to group together some sketches/ideas into concepts this week.

Startup performance & perception

• John Wayne will blog about some of the implications of the startup video recording.
• Aza (& possibly Limi) explore/blog about session restore improvements.

Mobile

Madhava Enros:

• Putting together a brief for an Android theme; want to start generating concept mockups soon — good UI examples for Android are the Twitter client & Doubletwist.
• Finished a “Field Guide to Firefox for Maemo 1.1” blog meta-post about all the new features/UI changes.
• Android sharing story stable for our first version, figuring out Maemo — it depends on how centralized sharing system works.
• Working on a number of Maemo & Android platform integration issues
• See ongoing progress.

Feedback session

Quick feedback and/or blockers; for in-depth discussions, we do design sessions on Wednesdays.

Quick questions from Marco on the Home Tab:

• about:home or about:start? Everyone said about:home — of course, this isn’t visible in the UI by default, so it’s mostly an implementation detail.
• Marco: “Contents for now are still limited to the search field and Mozilla snippets (still miss marketing requirements). Do we have ideas to discuss? I think Beltzner suggested to add something like about:me contents to the page”
• Limi & John Wayne to contact the Engagement team (Limi, JW), where do we want to go next, and how far for Firefox 4

Other topics covered

• Madhava Enros (re-)joins the Firefox UX Team! Will still be working on Mobile, and we’re excited to have him on board for future work on tablets & slate-type devices, as well asn ensuring a consistent experience across all our platforms.
• General discussion on how are people feeling about Firefox 4 Beta 1. Consensus is that it’s in a lot better state than last week — it’ll be shipping with quite a bit of unfinished UI, but that’s okay. 
• There’s an AIGA Design Week in San Francisco this week.
  • Open Studios on Tuesday, Thursday.
  • Design Week party at AutoDesk Gallery on Friday.
  • John Wayne is going, possibly others.
• Stephen Horlander brought up alternative — and temporary — placement possiblities for the Firefox button if we can’t draw in the title bar:
  • If we can’t draw in the title bar, we should put the menu button on glass, left of home as long as tabs are on top.
  • We should probably ask Dão if we can move it to this location immediately, since it’s a better location no matter if the titlebar drawing lands in time for beta1.
• Some discussion around the strings in the new Bookmarks Menu, general agreement that it’s on the right track.
• Alex Faaborg wanted to know if App tabs should be toolbar-less by default? Decision: Be bold! Start without toolbar in the betas, then get feedback & adjust accordingly if it causes issues.
• Everyone was reminded to submit their Mozilla Summit talks & sessions, deadline tomorrow.
• Question for Firefox Dev meeting tomorrow:
  • Retained Layers are in the critical path for extension bar + app tabs, when are they landing? Show sketches of what we’re trying to accomplish for context.

---

About the meetings

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning & dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

Is there anything that you think can be improved in these updates? How is the new project-centric format working out for you? Send feedback to limi@mozilla.com.

June 15, 2010 08:00 AM

Last week I managed to get the Inspector’s new tree panel working locally. It was a good chunk of work, incorporating about 2000 lines of DOMPlate, converted to a new JavaScript Code Module and another 1000 or so lines of JavaScript and CSS from Firebug. This morning I finished up the styling fixes for Windows and Linux and have it running on all three platforms. Mostly.

To be sure, there are some bugs left. Clicking the twisty images still doesn’t expand and collapse the trees – you need to click on the tag to do that. It’s still behaving funny with iframes. I still need to revise the styling for the tree panel and other panels to make it look like I want. I need to add some keyboard controls…

All of this will need bugs filed and patches written. If you’d like to help, please feel free to file bugs on the Firefox::Devtools component. Make sure to use Inspector in the subject or whiteboard so we can track it. We also have a #devtools IRC channel on irc.mozilla.org if you’d like to pop in and say hi.

Other bits I have left to do include verifying my existing test cases and writing a few new ones. There’s a lot of debugging code I need to strip out and lastly, I’ll need to rebase my patches against current mozilla-central and roll it all up into a nice tidy patch for my reviewer victim… I mean friend. Before that though, I hope to churn out some try builds tomorrow or Wednesday for people to play with.

If you want to check out the source and build your own, it’s living in http://hg.mozilla.org/users/rcampbell_mozilla.com/mozilla-inspector-2/. Careful, it’s fluxy!

June 15, 2010 01:09 AM

June 14, 2010 11:42 AM

June 14, 2010 11:42 AM

Jetpack

• Landed the add-on life-cycle API
• And converted the simple storage module to use it
• Fixed a tiny doc presentation bug
• Gave some feedback on Dietrich’s tabs API patch, did a couple of doc reviews

Switch-to-tab

• (Tentatively) positive reviews on patch to show pages in the awesomebar only once, as switch-to-tab, if they’re already open. Will land before the Firefox 4 beta 1 freeze, which is June 18.

Dumps

• Fixed a bug that caused dump() inside JavaScript sandboxes to truncate multi-byte characters
• Fixed another small bug that caused dump() inside windows to miss some carriage returns when it converts them to line feeds

Other

• Fixed an orange that was triggered by a BBC headline, “Woman jailed for giving baby methadone-soaked dummy”

June 12, 2010 12:01 AM

Progress:

---

• Discussed Bug 544442 [Toolkit] – ‘Add support for signed AUS update snippets [All]. Almost done with the app update patch which will include a fallback for when the cert check repeatedly fails’ with dveditz and he asked me to wait for additional feedback.
• Waiting on review for the final patch and landed patches that prepare the build system on mozilla-central and comm-central for landing – Bug 569058 [Toolkit] – Upgrade NSIS version to 2.45 or later (PCA complains when installer is cancelled on Windows 7) [Windows].
• Landed the MOZ_UPDATER configure changes for Bug 526333 [Toolkit:Build Config] – Having to create patches for each app’s package manifest and removed-files and then get reviews from each app is a PITA [All] to avoid requiring Makefile changes for the fix to Bug 535520 [Firefox] – Fix for bug 531703 should use #ifdef MOZ_UPDATER [Windows CE].
• Landed on trunk – Bug 485114 [Toolkit] – Add plugin for modifying file permissions and move NSIS plugins under other-licenses [Windows Vista].
• Backported and / or requested approval for 1.9.2.6 for patches on the following bugs:
  • Bug 522065 [Toolkit] – PCA complains when installer is cancelled [Windows 7].
  • Bug 536547 [Toolkit] – 3.5.6 is downloading the same version for an update [Windows XP].
  • Bug 551283 [Toolkit] – Suspicious and possibly unused code in updates.js updateListener.onProgress [All].
  • Bug 552617 [Toolkit] – A paused update can’t be resumed when closing the window using a window manager control [All].
  • Bug 569648 [Toolkit] – First async XHR without other network activity has null securityInfo for the channel when using auto-detect proxy [All].
• Submitted patch for feedback for Bug 552924 [Toolkit] – Allow distinguishing Universal ppc/i386 from Universal i386/x86_64 builds in AUS request [Mac OS X].
• Submitted patch for review for Bug 570680 [Firefox] – Remove call to check-locales.pl for Firefox [Windows 7].
• Submitted patch for review for Bug 571387 [Toolkit] – Use the official Unicode UAC and ShellLink distributions [Windows 7].
• Started working in my spare time on and submitted first patch for Bug 570689 [Toolkit] – Convert perl scripts to python [Windows 7].
• Attached mozilla-central patches for when we are ready to require NSIS 2.46 for Bug 571381 [Toolkit] – Require NSIS 2.46 Unicode and remove iconv requirement, utf16-le-bom.bin, etc. [Windows 7]. This was done earlier than necessary to verify that it is possible to remove the iconv requirement for building the NSIS installer. Still need comm-central patches but they can be submitted when we are closer to requiring NSIS 2.46 Unicode.
• Landed for SeaMonkey – Bug 569791 [SeaMonkey] – PCA complains when installer is cancelled [Windows 7].
• Landed for Thunderbird – Bug 569789 [Thunderbird] – PCA complains when installer is cancelled [Windows 7].
• Finished several reviews though less than I had wanted to.
• Started the documentation for the silent application update process for Windows.
• Discussed mozmill app update tests with Henrik for Bug 567258 [Toolkit] – [mozmill] Update the SoftwareUpdateAPI for Firefox 4.0 [All] to avoid redundant tests and to update tests for the changes made to application update.

Future targets:

---

• Focus on silent update implementation and clean up my review queue.
• As soon as feedback is provided by dveditz finish the patch for Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All].
• Hopefully land a patch for Bug 552924 [Toolkit] – Allow distinguishing Universal ppc/i386 from Universal i386/x86_64 builds in AUS request [Mac OS X] so it doesn’t block Josh’s work in Bug 571367 [mozilla.org] – turn production x86_64 builds into i386/x86_64 universal binaries [Mac OS X].
• With luck get r+ on outstanding review requests listed in the Progress section above and get them landed.

June 11, 2010 08:38 PM

As part of the "Developer Tools" we are working on for Firefox 4, the console is coming along nicely. The latest "try builds" are here for Linux, Windows and MacOS:

Windows and Mac Builds

Linux build

The UI has not been worked on at all at this point. There are several bugs on mock ups and implementation. The current UI was implemented by me, an engineer, so you will be underwhelmed.

There are several broken features like image urls not logging properly and not all exceptions and CSS errors are logged to the tab's console.

Here is the list of currently open bugs:  http://is.gd/cKswu

Here is a screen shot:


Feel free to download it and take it for a test run, file bugs. This is still at an early point, but feedback is valuable, so don't hesitate to comment here or in Bugzilla.

June 10, 2010 07:05 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

---

Status reports on current UX priorities:

Notifications

Alex Faaborg:

• (Faaborg is returning on Wednesday, updates below are from team members)
• Gavin has a patch for the new notifications, he’s hoping it’ll land later this week.
• Still unclear when the new default styling will come into play.
• The first implementation of the new notification panel style/approach is used for geolocation.

Firefox menu

Alex Faaborg:

• (Faaborg is returning on Wednesday, updates below are from team members)
• Dão is starting to implement it as a button on the toolbar, so we can start without the ability to draw in the title bar.

Site identity

Alex Faaborg:

• (Faaborg is returning on Wednesday, updates below are from team members)
• We know what the basic appearance looks like.
• We do not know what the new controls in the "identity notification panel" will look like yet.

Home tab & App tabs

Alexander Limi:

• Met with Blair and gave him a basic overview of the interactions we’re going to encounter
• There are tryserver builds available.
• Had a good discussion on the technicalities, we might be able to move the app tab from one window to another if we’re worried that having two instances of the same app tab won’t work for the user.
  • Do we want App Tabs to persist through all windows?
  • Do we expect App Tabs to be singletons or multiple instances across multiple windows?
• Still need to wireframe some of the edge cases and suggest a couple of alternate approaches to handling multiple instances of the same app tab.

Download Manager

Alexander Limi:

• This is still an opportunistic project, we’ll land independent pieces when we have resources for it.
• Mehdi Mulani (intern) has 3 interconnected bugs that need to be approved and landed, then we’ll have downloads in the Library window & icons that represent the type of file that was downloaded.
• Comment from Beltzner: The next self-contained high-value aspect could be to reflect deletion and file system state in the history.

HTML5

Alexander Limi:

• Met with Tantek Çelik to clarify priorities and overall approach.
• There’s a wiki page that is the central point for all things HTML5 — of particular interest is the Input page.
• Now unblocked, following up with main developer.

“Paper Cuts”

Alexander Limi:

Paper cut overview bug is here.

• Frank Yan (intern) has posted patches for two tab-related papercut bugs:
  • “Bounce” caused by spurious input from trackpads when scrolling the tab bar.
  • Replacing the tab arrows with smart resize/positioning of overflow tabs.
• More visibility via blog posts this week.

Main window refresh

Stephen Horlander:

• Broke out new tab bug into smaller bugs by request.
• Dão should be able to start working on the Firefox menu.
• All Windows mock-ups are updated.
• Marco is picking up bookmarks widget improvements.
• Unowned: Combined Stop/Reload/Go button.
• On Mac, all the patches looks good, and Markus should be able to land them.
• Will know more about Firefox button on Linux soon.
• If you have multiple windows, Aero Peek now has a way to show tabs within a window.
• Felipe will be starting to help on Windows API bugs, Jim was a bit resource-constrained.

In-content page design

Stephen Horlander:

• Posted In-Content UI Visual Unification, feedback was overwhelmingly positive.
• We should put together a list of the things we want to apply the new design to — Limi will help out with this.
• We’ll need to do something for the add-ons manager in any case — see below.

Jetpack & the Extension Bar

Jennifer Boriss:

• Recommending API added to jetpack to launch a panel for interactive content.
• Need to explore possibility of re-styling buttons to match theme work when add-on icons moved.
• Need to file bugs to allow add-on icons to be moved to different areas of the UI — who to talk to?
• It’s OK for us to invent new API for indicating intermediate states — e.g. active, but not visible.
• Design session on Wednesday.

Add-ons Manager

Jennifer Boriss:

• Final in-content mockups being worked on this week, want feedback in a design session on Wednesday.
• Remaining bugs being squashed, some edge cases appearing that needs handling.

Privacy

Jennifer Boriss:

• Comfortable with using Faaborg’s initial wireframes as the base.
• Dan’s sandboxed third-party cookie implementation landed, but there’s discussion around the specifics.

TabCandy

Aza Raskin:

• Not present, comments below are from Beltzner:
• Got feedback from Dão about the code.
• Removing jQuery and getting it ready for a trunk landing.
• Need to figure out how we’re going to start talking about it and setting expectations.

Post-Firefox 4 Home Tab

John Wayne Hill: (UX intern)

• Ran a Design Lunch last week, it went really well. Good ideas came out and lots of people participated.
• Will be sketching up some initial explorations this week based on the feedback.

Other topics covered

• John Wayne Hill: Speed Tests — Will be creating some charts to better understand the speed test videos that Faaborg created. Have raw data ready (shared via email).
• Alexander Limi: Ideas for the Science Fair & Summit in general — maybe do a quick brainstorm when Faaborg is back later in the week?
• Jennifer Boriss: Design session for Add-ons Manager this Wednesday? Also have a Privacy design session with Mehdi later today.
• Stephen Horlander: Bookmarks menu/panel behavior — Marco is picking it up — in-content UI: bug 425749
• Mike Beltzner: Improve shipping criteria for beta milestones. Create a list of what these are.
• Mike Beltzner: General discussion around when to get product approval for design changes: If we change the way the way the browser interacts with web content, make sure to communicate broadly first and involve the product team: Beltzner, Jay — and if they’re not available: Johnath and Shaver.

---

About the meetings

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning and dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

Is there anything that you think can be improved in these updates? How is the new project-centric format working out for you? Send feedback to limi@mozilla.com.

June 09, 2010 08:55 PM

I just wanted to post a quick note about this to a wider audience as I have been talking about it in Mozilla meetings…

Firefox 3.6.4 (get the release candidate!) has a platform version of 1.9.2.4. The version number 1.9.2.5 is currently being used by Fennec. We’ll be taking fixes above and beyond that version, so the next platform version Firefox will use will be named 1.9.2.6. We will keep the version numbers coherent by naming it Firefox 3.6.6 (essentially skipping over 3.6.5).

I will be moving the blocking flags and status flags as appropriate, so if you see activity in bugs don’t worry. Also, If you have approvals for 1.9.2.5 they are now for 1.9.2.6 (and should still be landed on mozilla-1.9.2 default).

This is nothing more than a name change, everything still refers to the same Firefox release.

June 09, 2010 07:57 PM

Progress:

---

• Landed on trunk – Bug 546595 [Toolkit] – Add mochitests for the incompatibleList and incompatibleCheck pages [All]. Now all app update UI pages and different page sequence scenarios are tested except for the pluginupdatesfound page.
• Landed on trunk – Bug 569648 [Toolkit] – First async XHR without other network activity has null securityInfo for the channel when using auto-detect proxy [All]. This fixes Bug 471889 [Toolkit] – Software update sometimes stops with “Update XML file malformed (200)” (Error: channel.securityInfo is null) [All].
• Landed on trunk for Firefox – Bug 522065 [Toolkit] – PCA complains when installer is cancelled [Windows 7].
• Received r+ from dveditz for the CertUtils.jsm portion of Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All]. Almost done with the app update patch which will include a fallback for when the cert check repeatedly fails.
• Submitted patch for review – Bug 569058 [Toolkit] – Upgrade NSIS version to 2.45 or later (PCA complains when installer is cancelled on Windows 7) [Windows]
• Submitted patch for review – Bug 569534 [mozilla.org] – Add NSIS 2.46 Unicode to Mozilla Build [Windows]
• Received r+ for SeaMonkey – Bug 569791 [SeaMonkey] – PCA complains when installer is cancelled [Windows 7]
• Received r+ for Thunderbird – Bug 569789 [Thunderbird] – PCA complains when installer is cancelled [Windows 7]

Future targets:

---

• Finish the last patch for Bug 544442 [Toolkit] – Add support for signed AUS update snippets [All].
• Focus on silent update implementation and clean up my review queue.

June 05, 2010 10:42 PM

Jetpack

• Hashing out the add-on life-cycle API
• And improvements to the object property validator
• Made the CommonJS loader UTF-8-aware and found some related JavaScript sandbox funnybusiness
• Cleaned up context menu a bit
• A byte streams improvement patch up for review

Other

• Filed a bug about showing performance stats in about:support on Johnathan’s suggestion

June 05, 2010 10:14 AM

I’ve spent some time this week transferring all the API documentation for the new add-ons manager from the Mozilla wiki to the Mozilla Developer Network. This should now be the place to go for the definitive info.

Right now it is pretty dry, for the most part just pure API info with no examples. Before I started working more on that side of things I wanted to ask what kind of examples people might like to see documented?

June 04, 2010 03:35 PM

June 04, 2010 08:32 AM

June 04, 2010 08:32 AM

As we choose priorities for the next version of Firefox’s features and development, the Firefox team has been considering the state of the web and looking for areas where online content has changed faster than browser functionality. One area of concern is the growing use of private user data, especially by advertisers. User data being silently and persistently passed between sites and advertisers is disturbing for those with an interest in user choice and transparency on the web.

Privacy vs. Security

Privacy and security are related but distinct topics. Security refers to the prevention of material harm to the user. Avoiding theft, fraud, and data loss are all security issues. Browsers have been working to improve security for decades, prompted by increasingly sophisticated viruses, malware, and other exploits.
Privacy is a broader topic than security. It refers to users’ control over what they reveal about themselves online, whether or not what they reveal might lead to material harm. All internet users reveal some information about themselves to some sites, but the user has privacy if his discretion determines what information is shared with whom.

Firefox has Local Privacy but Needs Network Privacy

The Firefox team has already done some great work on local privacy with improvements such as Private Browsing mode, Clear Recent History, and Forget about this Site. These features give users better control over when their data is exposed and hidden on their own computer. However, wider privacy issues surface when data is shared over a network.

One major problem of the modern web is the ability for private user data to be collected by advertising companies via third-party cookies.

If sites provide rich interaction, they usually require user data. The problem occurs when users willingly share data with a site they trust, but unknowingly their data is shared with other sites and companies via third-party cookies. This is common practice and a growing revenue model online. It first received national attention in November of 1999, when the Federal Trade Commission held a workshop on online profiling and reported that it presented a privacy concern to consumers. The practice has grown since then, despite some failed attempts at regulation by the US’s Federal Trade Commission, the Interactive Advertising Bureau, and Britain’s Office of Fair Trading.

Any website you visit can contain ads and other components that send cookies from your browsing session on the domain you trust to an advertising domain. These third-party cookies can be used to track information about users across multiple sites and multiple browsing sessions, allowing web habits to be profiled and tracked. This data can tell companies limitless kinds of information, such as what purchases you make, what news you read, your income, if you’ve applied for work, and what dating sites you prefer. One manifestation of this data sharing is seeing to ads targeting users based on data and actions from other sites.

The ability for advertisers to gain and use this data violates user privacy for several reasons:

• It’s nearly impossible to detect. Much of the data-sharing happens in the background during a browsing session without asking or notifying the user. Users usually only discover what has happened when they are seeing targeted ads (long after the data has been transferred).

• It occurs without user consent. Of the sites that are even aware of third-party cookie sharing, few give users control over how their data is shared with advertisers. Sites that do offer preferences sometimes phrase them in ways that disguise their purpose, such as “do you want relevant content to be shown based on your usage” rather than “do you want ads to be shown based on your personal data.”

• It contradicts the user’s reasonable expectation of privacy. Some sites that knowingly share data present a false image of being responsible with user data. They may show the user preferences that imply control, assure users that their data is “safe,” or offer to let users read a lengthy privacy policy in order to hide their actual practices. Of course there’s a very special hell set aside for sites that change privacy settings to be more permissive once users have already signed up and entrusted their data.

• It’s nearly impossible to prevent. Even a user who is privacy conscious and reads all privacy policies, keeps his privacy settings up to date, and avoids sites that don’t guarantee privacy isn’t necessarily safe. Any site he’s given data to could potentially use it without asking, and third-party cookies could be sent via ads and web bugs without the knowledge of the site’s owners. Heck, any site could be scraping identifiable information from his digital fingerprint.

• It potentially embarrasses the user. Data sharing via third-party cookies takes information given by the user at some point in time and exposes it at another time. While the user may be discrete about where he is viewing certain content and even use Private Browsing Mode for items to not appear in history, advertisers using third-party cookies can expose user actions at times out of the user’s control.

So what can Firefox do to improve its story on privacy?

1. Provide intelligent defaults for third-party cookie behavior

Simply disabling third-party cookies isn’t the solution. Third-party cookies are necessary for legitimate web functionality such as embedded content, session management, mashups, etc. Most bank websites depend on third-party cookies for functions such as bill paying. The goal should not be to outright disable third-party cookies, but to be more intelligent about what behavior is allowed.

The http-state working group is currently working to produce a specification in multiple documents to lay out how clients should behave with regard to cookies (see current drafts here). Dan Witte, the cookie module owner at Mozilla, has been in communication with them and is doing his own work to develop a modern cookie standard. The goal is to create a guideline that Mozilla can follow that aligns with our Manifesto to protect user choice on the web. Dan’s already working on one way Firefox could address the problem by enabling third-party cookies, but only temporarily. His idea is to keep third-party cookies active only for the life of one tab. When the tab is closed, the cookies are deleted – advertisers could not track users from site to site. Dan will be blogging about this later with more details on his work.

2. Give users better control over how sites can access their information in Preferences

Currently, Firefox gives users precise, fine-grained control over the many ways that sites can access user data. All the user needs to do is change their on each Preference panel that effects site privileges:

As can be seen above, the current Firefox interface gives each site privilege type – saving passwords, cookies, etc – its own separate preference window. This design is framed around the implementation model rather than the user’s mental model, meaning it’s designed in a way that corresponds with how it was built rather than how users perceive the action they want to take. Having an individual window for each permission makes sense from an implementation standpoint, because each site privilege is separate in code. From the user’s perspective, however, it’s impossible to tell what privileges a particular site has. A better design would present controls in a site-centric rather than technology-centric view. If a user decides that he doesn’t trust site X and doesn’t want it to have any access, it would be more efficient to control all of site X’s access in one – not 15 – Preference windows. Alex Faaborg made this mockup to illustrate how a site-centric UI could be achieved:

While all of Firefox’s Preferences need to be improved, including site-centric privacy controls like Alex’s above for Firefox 4.0 would go a long way towards putting users back in control of their data.

3. Give users better control of their data while they are browsing

While a site-specific Preference panel will help users have better fine-grained control of their privacy when they’re configuring Firefox, there’s some options and information that can be exposed while the user is browsing. If a site has access to geolocation, for instance, this should be constantly indicated in Firefox’s interface. If a site is storing a password, this should be easy to change or remove without opening Preferences. Firefox’s Site Identity Button, which currently gives very little information about a site, could be improved to give information about a site’s privileges and the ability to change them.

It’s our goal for Firefox 4.0 to give users more control of their data, both by literally giving them controls and, more importantly, creating intelligent defaults that protect a user’s privacy and anonymity without breaking web functionality. It’s my hope that even simply exposing what access sites have to data will be positive for the web by eroding the sense of false security that many sites try to create for their users and creating awareness of and control over how, where, and when data is being shared.

June 02, 2010 09:43 AM