November 6, 2015 § Leave a comment
In part 1, we discussed the design of time measurement within the Firefox Performance Monitor. Despite the intuition, the Performance Monitor had neither the same set of objectives as the Gecko Profiler, nor the same set of constraints, and we ended up picking a design that was not a sampling profiler. In particular, instead of capturing performance data on stacks, the Monitor captures performance data on Groups, a notion that we have not discussed yet. In this part, we will focus on bridging the gap between our low-level instrumentation and actual add-ons and webpages, as may be seen by the user.
May 29, 2015 § 9 Comments
Gerv’s recent post on the Jeeves Test got me thinking of the Firefox of my dreams. So I decided to write down a few ideas on how I would like to experience the web. Today: Firefox Agents. Let me emphasise that the features described in this blog post do not exist.
Marcel uses Firefox every day, for quite a number of things.
- He uses Firefox for fun, for watching videos and playing online games. For this purpose, he has installed a few tools for finding and downloading videos. Also, one of his main search engines is YouTube. Suggested movies? Sure, as long as they are fun.
- He uses Firefox for social networks. He follows his friends, he searches on Facebook, or Twitter, or Google+. If anything looks fun, or useful, he’d like to be informed.
- He uses Firefox for managing his bank accounts, his taxes, his health insurance. For this purpose, he has paranoid security settings – to avoid phishing, he can only browse to a few whitelisted websites – and no add-ons. He may be interested in getting information from these few websites, and in security updates, but that’s about it. Also, since Firefox handles all his passwords, it must itself be protected by a password.
- He uses Firefox to read his Gmail account. And to read his other Gmail account. And he doesn’t want to leak privacy information by doing so on the same Firefox that he’s using for browsing.
- Oh, and he may also be using Firefox for browsing websites that are sensitive for any kind of reason, whether he’s hunting for gifts for his close family, dating online, chatting with hackers, discussing politics, helping NGOs in sensitive parts of the globe, visiting BitTorrent trackers, consulting a physician through some online service, or, well, anything else that requires privacy. He’d like to perform such browsing with additional anonymity guarantees. This also means locking Firefox with a password.
- Sometimes, his children or friends borrow his computer and use Firefox, too.
Of course, since Marcel brings his own device at (or from) work, that’s the same Firefox that he’s using for all of these tasks, and he’s probably even doing several of these tasks at the same time.
So, Marcel has a set of contradictory requirements, not to mention that each of his uses of Firefox needs to pass a distinct Jeeves Test. How do we keep him happy nevertheless?
Introducing Firefox Agents
In the rest of this post, I will be calling each of these uses of Firefox an Agent (if we ever implement this feature, it will, of course, be called Persona). Each Agent matches one way you use Firefox. While Firefox may be delivered with a predefined set of Agents, users can easily create new Agents. In the example, Marcel has his “Fun Agent”, his “Social Agent”, his “Work Agent”, etc.
Each Agent is unique and separate:
- Each Agent has its own icon on Marcel’s menu/desktop/tablet/phone and task list.
- Each Agent has its own visual identity, to make sure that work-related stuff doesn’t end up accidentally in the Fun Agent.
- Each Agent has its own set of preferences, bookmarks, remembered passwords, cookies, cache, and add-ons.
- Each website may be connected to a given Agent, so that links received through Gmail or through Thunderbird, for instance, automatically open with the right Agent.
As a consequence, any technology that can come bundled with Firefox to, for instance, provide search suggestions or any other kind of website suggestions is tied to an Agent. For instance, Marcel’s browsing a dating site, or shopping for shoes, or having religious activities will not be visible to any of his colleagues looking above his shoulder at his Work Agent, nor will it be tied to either of Marcel’s Gmail accounts. This greatly increases the chances of suggestion technologies passing the Jeeves Test.
Agents are also connected:
- A menu in each Agent, as well as a keyboard shortcut, lets users quickly open/switch to other Agents.
- When an Agent follows a link to a website that belongs to another Agent, the relevant Agent opens automatically.
- Bookmarks may be pushed, on demand, from one Agent to another one.
- Passwords may be pulled, on demand, from one Agent to another one.
How far are we from Agents?
Technologically speaking, Firefox Agents almost exist. Indeed, Firefox has supported Profiles forever, since way before Firefox 1.0. I generally have three instances of Firefox opened at the same time (four when I’m doing web development), and it works nicely.
With a few add-ons, you can get almost everything, although not entirely connected together:
- Profilist helps a lot with switching between profiles, and the dev version adds distinct icons;
- Firefox Themes implement distinct appearances;
- there are add-ons implementing whitelist browsing;
- there are add-ons implementing password-protected Firefox.
A few features are missing, but as you can see, the list is actually quite short:
- Pushing/pulling passwords and bookmarks between Agents (although that’s a subset of what Firefox Accounts can do).
- Attaching specific websites to specific Agents (although this doesn’t seem too difficult to implement).
- Connecting this all together.
I would like to browse with this Firefox. Would you?
May 6, 2015 § 13 Comments
When it is at its best, Firefox is fast. Really, really fast. When things start slowing down, though, using Firefox is much less fun. So, one of main objectives of the developers of Firefox is making sure that Firefox is and remains as smooth and responsive as humanly possible. There is, however, one thing that can slow down Firefox, and that remains out of the control of the developers: add-ons. Good add-ons are extraordinary, but small coding errors – or sometimes necessary hacks – can quickly drive the performance of Firefox into the ground.
So, how can an add-on developer (or add-on reviewer) find out whether her add-on is fast? Sadly, not much. Testing certainly helps, and the Profiler is invaluable to help pinpoint a slowdown once it has been noticed, but what about the performance of add-ons in everyday use? What about the experience of users?
To solve this issue, we decided to work on a set of tools to help add-on developers and reviewers find out the performance of their add-ons. Oh, and also to let users find out quickly if an add-on is slowing down their everyday experience.
On recent Nightly builds of Firefox, you may now open about:performance to get an overview of the performance cost of add-ons and webpages :
The main resources we monitor are :
- jank, which measures how much the add-on impacts the responsiveness of Firefox. For 60fps performance, jank should always remain ≤ 4. If an add-on regularly causes jank to increase past 6, you should be worried.
- CPOW aka blocking cross-process communications, which measures how much the add-on is causing Firefox to freeze waiting for a process to respond. Anything above 0 is bad.
Note that the design of this page is far from stable. I realise it’s not very user-friendly at the moment, so don’t hesitate to file bugs to help us improve it. Also note that, when running with e10s, the page doesn’t display all the useful information. We are working on it.
Add-on developers and reviewers can now find information on the performance of their add-ons on a dedicated dashboard.
These are real-world performance data, as extracted from user’s computers. The two histograms available for the time being are:
- MISBEHAVING_ADDONS_JANK_LEVEL, which measures the jank, as detailed above;
- MISBEHAVING_ADDONS_CPOW_TIME_MS, which measure the amount of time spent in CPOW, as detailed above.
If you are an add-on developer, you should monitor regularly the performance of your add-on on this page. If you notice suspicious values, you should try and find out what causes these performance issues. Don’t hesitate and reach out to us, we will try and help you.
Slow add-on Notification
Add-on developers and reviewers, as well as end-users, are now informed when an add-on causes either jank or CPOW performance issues:
Note that this feature is not ready to ride the trains, and we do not have a specific idea of when it will be made available for users of Aurora/DeveloperEdition. This is partly because the UX is not good enough yet, partly because the thresholds will certainly change, and partly because we want to give add-on developers time to fix any issue before the users see a dialog that suggest that an add-on should be uninstalled.
Performance Stats API
By the way, we have an API for accessing performance stats. Very imaginatively, it’s called PerformanceStats.jsm [link]. While this API will still change during the coming weeks you can start playing with it if you are interested. Some add-ons may be able to throttle their performance use based on this data. Also, I hope that, in time, someone will be able to write a version of about:performance much nicer than mine 🙂
Challenges and work ahead
For the moment, we are in the process of stabilizing the API, its implementation and its performance. In parallel, we are working on making the UX of about:performance more useful. Once both are done, we are going to proceed with adding more measurements, making the code more e10s-friendly and measuring the performance of webpages.
If you are an add-on developer and if you feel that your add-on is tagged as slow by error, or if you have great ideas on how to make this data useful, feel free to ping me, preferably on IRC. You can find me on irc.mozilla.org, channel #developers, where I am Yoric.
September 22, 2008 § 1 Comment
Il y a environ un an, un de mes collègues travaillait sur un dispositif de communication pour les services d’urgence. Ce dispositif, prévu pour être utilisé lors de catastrophes naturelles ou d’attentats terroristes majeurs, devait permettre une meilleure synchronisation entre la police, les pompiers et les équipes de secouristes. Ah, et au cas où il se serait effectivement agi d’un attentat, le dispositif se devait d’être sûr. Conclusion du collègue en question : “comme Firefox est sûr, je vais faire cela sous la forme d’une extension Firefox, et ça sera sûr.”
À ce stade, j’espère que vous êtes déjà en train de vous moquer intérieurement de mon collègue. Cela dit, savez-vous effectivement quel risque vous courez en écrivant une extension ? Savez-vous quel risque vous faites courir à l’utilisateur ? Et savez-vous à quel point vous pouvez compter sur la plateforme Mozilla pour vous aider à écrire des extensions ou des applications sûres ?
À l’occasion, je tâcherai d’écrire un article détaillé sur le sujet. En attendant, pour ceux qui se posent des questions, voici les transparents (en français) de l’exposé que j’ai donné samedi dernier au Mozilla Add-Ons Workshop de Paris.
Ah, un indice : ayez peur.
August 14, 2008 § 1 Comment
A Mozilla Workshop will be held in Paris on September 20th 2008. The main topic of this workshop is add-ons development, for a technical audience of developers and beginners. I will be talking about security of add-ons. More informations here.
Un Atelier Mozilla se tiendra à Paris le 20 Septembre 2008. On y parlera des divers aspects du développement d’extensions, à l’attention d’un public plutôt technique, composé de développeurs et de débutants. J’y parlerai de sécurité des extensions. Plus d’informations ici.
December 19, 2007 § Leave a comment
October 11, 2007 § 9 Comments
Note Je mettrai en ligne sous peu une version française de ce billet.
This is a request for comments, so please don’t hesitate. I’d rather answer questions and find out about potential pitfalls now than after two years of work.