| title | layout | description | mailinglist |
|---|---|---|---|
Browser Architecture Newsletter 2 |
text |
A follow-up with updates on XBL Conversion, Storage and Sync and Workflow Improvements |
[Link to mailing-list archive]({{ page.mailinglist }})
Welcome to the second Browser Architecture Newsletter! Since our last update, we have a new website which includes posts about some of the problems with XUL, extracting Necko as a standalone component, and comparing XBL with Web Components.
The website is built from this GitHub repository of Markdown files, and we’re using pull requests to review and revise our research proposals and analyses. Do you have ideas for improvements? File an issue on the repo or contact us in #browser-arch!
We'd like to reduce or even remove XBL and XUL from the tree. It's becoming clear that replacing XBL is more important and easier than replacing XUL, so there are a few projects ongoing to learn more about it.
A conversion of the behavioral <preference> binding is in progress at Bug 1379338. Although this work started as a prototype, it resulted in a more straightforward implementation than we currently have, so is on the path to being landed.
As mentioned above, there’s some new documentation comparing XBL with Web Components. There’s also a visual tree of the bindings we use in Firefox and what features each uses.
A prototype of replacing some XBL UI components in about:preferences with Custom Elements is attached to Bug 1392367. This relies on a forked version of the custom elements polyfill made to work in XUL documents.
A prototype of converting <tabbrowser> to a JS class is in progress at Bug 1392352. This would cause gBrowser to become a JS object instead of a DOM Node. This conversion is semi-automated by a script converting the binding to a JS class.
We're in the process of cataloging and analyzing some of Firefox's sprawling storage technologies (45+ different data stores and dozens of formats on desktop alone), and how they relate to Sync and across platforms. We're hoping to find ways to make this situation simpler, more reliable, and easier to extend.
You can see the beginnings of our knowledge capture here (PRs welcome!), and a spreadsheet showing how data types interact with Sync and mobile platforms.
Huge thanks to the Sync team and data and product folks across the org for helping with our research.
Lately I've been paying extra attention to development papercuts when working on bugs, especially issues when using ./mach run without passing a profile. Here’s a list of recent changes on that front:
- You can open the Browser Toolbox in a local build without flipping prefs.
- The default browser prompt and about:config warning screen no longer show up for the scratch_user (the profile used when you do ./mach run without a profile).
- You can flip any pref for the scratch_user with the --setpref option, or by adding them in your machrc file. For example, to make sure I always see dump output I added this to my ~/.mozbuild/machrc file:
[runprefs] browser.dom.window.dump.enabled=true - There’s a new keyboard shortcut to do a restart + session restore in local builds.
- The Browser Console is now part of session store, so it will reopen after using the above keyboard shortcut.