There’s been a project that’s been going on for several years to move Firefox’s bookmarks processing off the main thread and to happen in the background – to help reduce possible jerkiness when dealing with bookmarks.
One part of this (Places Transactions) has been enabled in Nightly for about 4-5 weeks. We think we’ve fixed all the regressions for this, and we’d now like more people testing.
So, when you’re checking out the improved performance of Firefox Nightly, please also keep an eye on Bookmarks – if you’re moving/copying/editing them, and you undo/redo actions, check that everything behaves as it should.
If it doesn’t, please file a bug with how to reproduce and we’ll take a look. If you can also test with the preference browser.places.useAsyncTransactions set to false (after a restart) to know if it happens with the old style transactions – that will help us finding the issue.
We know there’s still some performance issues with the new async transactions which we’re currently working on and hope to be landing fixes for those soon.
I’ve created an example repository for how you might set up tools to help development of a WebExtension. Whilst there are others around, I’ve not heard of one that includes examples of tools for testing and auditing your extension.
It is based on various ideas from projects I’ve been working alongside recently.
The repository is intended to either be used as a starting point for constructing a new WebExtension, or you can take the various components and integrate them into your own repository.
It is based around node/npm and the web-ext command line tool to keep it simple as possible. In addition it contains setup for:
This is the third of some posts I’m writing about how we implement and work on the desktop and standalone parts of Firefox Hello. You can find the previous posts here.
So what we do is to put almost all our views onto a single html page at representative sizes. The screen-shot below shows just one view from the page, but those buttons at the top give easy access, and in reality there’s lots of them (about 55 at the time of writing).
The showcase has various advantages that help us develop faster:
Since it is a web page, we have all the developer tools available to us – inspector, css layout etc.
We don’t have to restart Firefox to pick up changes to the layout, nor do we have to recompile – a simple reload of the page is enough to pick up changes.
We also don’t have to go through the flow each time, e.g. if we’re changing some of the views which show the media (like the one above), we avoid needing to go through the conversation setup routines for each code/css change until we’re pretty sure its going to work the way we expect.
Almost all the views are shown – if the css is broken for one view its much easier to detect it than having to go through the user flow to get to the view you want.
We’ve recently added an RTL mode so that we can easily see what the views look like in RTL languages. Hence no awkward forcing of Firefox into RTL mode to check the views.
There’s one other “feature” of the showcase as we’ve got it today – we don’t pick up the translated strings, but rather the raw string label. This tends to give us longer strings than are used normally for English, which it turns out is an excellent way of being able to detect some of the potential issues for locales which need longer strings.
Structure of the showcase
The showcase is a series of iframes. We load individual react components into each iframe, sometimes loading the same component multiple times with different parameters or stores to get the different views. The rest of the page is basically just structure around display of the views.
The iframes does have some downsides – you can’t live edit css in the inspector and have it applied across all the views, but that’s minor compared to the advantages we get from this one page.
We’re always looking for ways we can improve how we work on Hello. We’ve recently improved the UI showcase quite a bit, so I don’t think we have too much on our outstanding list at the moment.
The only thing I’ve just remembered is that we’ve commented it would be nice to have some sort of screen-shot comparison, so that we can make changes and automatically check for side-effects on other views.
We’d also certainly be interested in hearing about similar tools which could do a similar job – sharing and re-using code is definitely a win for everyone involved.