Revisiting how we build Firefox

Chris Hofmann chofmann at
Sat Jul 11 20:33:37 UTC 2015

On Sat, Jul 11, 2015 at 11:33 AM, Mike Hoye <mhoye at> wrote:

>  On 2015-07-11 1:06 PM, Chris Hofmann wrote:
>   On Sat, Jul 11, 2015 at 1:52 AM, Gijs Kruitbosch <
> gijskruitbosch at> wrote:
> > 1) adding a single button to the toolbar of the main Firefox UI slows
> down startup and new window openings (talos!)
> > by a few milliseconds spent in XUL layout / XBL construction alone.
>  In its own very odd way this might be considered a benefit.  It actually
> forces hard decisions and discussion on adding more buttons to the UI and
> removing/replacing things if something more important needs to be added.
> I think we should trust our colleagues in UX to make good decisions for
> our users and defer to their decisions instead.

20 years of experience working on browsers tells me that features don't
always get added or removed based on our colleagues in able to or in charge
of such decisions.

> This would take more humility than discipline, but it seems like a better
> approach overall than having our UI design somehow bottlenecked

Not saying that its not worthwhile to try and address performance
problems.  I did call this particular one a "crutch" for making sure good
UI decisions were considered.

So the technical question becomes how many buttons do we plan on adding to
make the browser better?  Then we could calculate the cost/benefit of
working this particular performance problem.

on dead-end tech throwing up perf-regression errors in automation.
Adding more buttons and complexity to the UI is not just an automation
error problem.  There's plenty of bugs where adding buttons and elements to
the Main UI have impacted users in real use cases.


> - mhoye
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list