Mozilla Privacy Blog: Mozilla and Allies Say No to Surveillance Blank Check in NDAA, Yes to Strong Surveillance Protections
Today Mozilla, along with a group of builders and supporters of innovation, sent a letter calling on the US House of Representatives to pass strong surveillance reform proposals such as the Government Surveillance Reform Act (GSRA) and the Protect Liberty and End Warrantless Surveillance Act (PLEWSA).
In line with our previous call for reform, our letter also highlighted the need for codification of the scope of surveillance proposed in the Administration’s own Executive Order on “Enhancing Safeguards for United States Signals Intelligence Activities” and opposed a months-long reauthorization of Section 702 that would effectively greenlight surveillance abuses.
Both GSRA and PLEWSA take critical steps forward in protecting Americans from overbroad surveillance, such as imposing warrant requirements for queries of US person data and banning warrantless purchases of sensitive information on Americans from data brokers. We do, however, encourage Congress to examine how it can further strengthen PLEWSA.
Unfortunately, House and Senate Intelligence Committees are also considering proposals of their own, proposals that would entrench the surveillance status quo.
Those wishing to get involved can add their names to our letter and do their part to engage Congress on this important issue.
You can find the letter HERE.
The post Mozilla and Allies Say No to Surveillance Blank Check in NDAA, Yes to Strong Surveillance Protections appeared first on Open Policy & Advocacy.
Support.Mozilla.Org: What’s up with SUMO – Q4 2023
Hi everybody,
The last part of our quarterly update in 2023 come early with this post. That means, we won’t get the data from December just yet (but we’ll make sure to update the post later). Lots of updates after the last quarter so let’s just dive in!
Welcome note and shout-outs from Q4- Welcome to Philipp T, and Harry S to the Social and Mobile Store Support program.
- Thanks for everybody who helped translated our KB articles to Spanish & reviewed the revisions for the past 3 months. Thanks to Pascal, Nuke, Ángela, Pablo.carrillo, Gerardo, Fernando, Zupe, Italodeox, Silverio, Uribetxebarria, Jamj, Ff.pub.ro, Martin.chile, Vhrc99, Josmiguel92, Seresgavillar, Franjb68, Javimarsal, Priscillamdominguez, Telecoamlg, and Julioadrianortiz320.
- Congratulations for Handi S & Carlos Tomás for becoming a new locale leader for Indonesian and Catalan.
- Thanks also to everybody who helped with the localization of Pocket migration to Mozilla accounts FAQ article. Thank you to Wxie, Irvin, Mark H, Pierre, Artist, Michele, Marsf, Daisuke, Hyeon Soek, Krzysztof, Cláudio, Valery, and Lucas.
If you know anyone that we should feature here, please contact Kiki and we’ll make sure to add them in our next edition.
Community news- Kiki back from maternity leave and Sarto bid her farewell, all happened in this quarter.
- We have a new contributor policy around the use of generative AI tools. This was one of the things that Sarto initiated back then so I’d like to give the credit to her. Please take some time to read and familiarize yourself with the policy.
- Spanish contributors are pushing really hard to help localize the in-product and top articles for the Firefox Desktop. I’m so proud that at the moment, 57.65% of Firefox Desktop in-product articles have been translated & updated to Spanish (compared to 11.8% when we started) and 80% of top 50 articles are localized and updated to Spanish. Huge props to those who I mentioned in the shout-outs section above.
- We’ve got new locale leaders for Catalan and Indonesian (as I mentioned above). Please join me to congratulate Handi S & Carlos Tomás for their new role!
- The Customer Experience team is officially moved out from the Marketing org to the Strategy and Operations org led by Suba Vasudevan (more about that in our community meeting in Dec).
- We’ve migrated Pocket support platform (used to be under Help Scout) to SUMO. That means, Pocket help articles are now available on Mozilla Support, and people looking for Pocket premium support can also ask a question through SUMO.
- Firefox account is transitioned to Mozilla account in early November this year. Read this article to learn more about the background for this transition.
- We did a SUMO sprint for the Review checker feature with the release of Firefox 119, even though we couldn’t find lots of chatter about it.
- Please check out this thread to learn more about recent platform fixes and improvements (including the use of emoji! )
- We’ve also updated and moved Kitsune documentation to GitHub page recently. Check out this thread to learn more.
- Watch the monthly community call if you haven’t. Learn more about what’s new in October, November, and December! Reminder: Don’t hesitate to join the call in person if you can. We try our best to provide a safe space for everyone to contribute. You’re more than welcome to lurk in the call if you don’t feel comfortable turning on your video or speaking up. If you feel shy to ask questions during the meeting, feel free to add your questions on the contributor forum in advance, or put them in our Matrix channel, so we can answer them during the meeting. First time joining the call? Check out this article to get to know how to join.
- If you’re an NDA’ed contributor, you can watch the recording of the Customer Experience weekly scrum meeting from AirMozilla to catch up with the latest product updates.
- Consider subscribe to Firefox Daily Digest to get daily updates about Firefox from across different platforms.
Check out SUMO Engineering Board to see what the platform team is currently doing and submit a report through Bugzilla if you want to report a bug/request for improvement.
Community stats KBKB pageviews (*)
* KB pageviews number is a total of KB pageviews for /en-US/ only Month Page views Vs previous month Oct 2023 7,061,331 9.36% Nov 2023 6,502,248 -7.92% Dec 2023 TBD TBDTop 5 KB contributors in the last 90 days:
KB LocalizationTop 10 locales based on total page views
Locale Oct 2023pageviews (*)
Nov 2023 pageviews (*) Dec 2023pageviews (*)
Localization progress (per Dec, 7)(**) de 10.66% 10.97% TBD 93% fr 7.10% 7.23% TBD 80% zh-CN 6.84% 6.81% TBD 92% es 5.59% 5.49% TBD 27% ja 5.10% 4.72% TBD 33% ru 3.67% 3.8% TBD 88% pt-BR 3.30% 3.11% TBD 43% It 2.52% 2.48% TBD 96% zh-TW 2.42% 2.61% TBD 2% pl 2.13% 2.11% TBD 83% * Locale pageviews is an overall pageviews from the given locale (KB and other pages) ** Localization progress is the percentage of localized article from all KB articles per localeTop 5 localization contributors in the last 90 days:
Forum SupportForum stats
Month Total questions Answer rate within 72 hrs Solved rate within 72 hrs Forum helpfulness Oct 2023 3,897 66.33% 10.01% 59.68% Nov 2023 2,660 64.77% 9.81% 65.74% Dec 2023 TBD TBD TBD TBDTop 5 forum contributors in the last 90 days:
Social Support Channel Total tweets Total moderation by contributors Total reply by contributors Respond conversion rate Oct 2023 311 209 132 63.16% Nov 2023 245 137 87 63.50% Dec 2023 TBD TBD TBD TBDTop 5 Social Support contributors in the past 3 months:
Play Store SupportFirefox for Android only
Channel Total reviews Total conv interacted by contributors Total conv replied by contributors Oct 2023 6,334 45 18 Nov 2023 6,231 281 75 Dec 2023Top 5 Play Store contributors in the past 3 months:
Product updatesTo catch up on product releases update, please watch the recording of the Customer Experience scrum meeting from AirMozilla. You can also subscribe to the AirMozilla folder by clickling on the Subscribe button at the top right corner of the page to get notifications each time we add a new recording.
Useful links:- #SUMO Matrix group
- SUMO Discourse
- Contributor forums
- Twitter @SUMO_mozilla and @FirefoxSupport
- SUMO Blog
Niko Matsakis: Being Rusty: Discovering Rust's design axioms
To your average Joe, being “rusty” is not seen as a good thing.1 But readers of this blog know that being Rusty – with a capitol R! – is, of course, something completely different! So what is that makes Rust Rust? Our slogans articulate key parts of it, like fearless concurrency, stability without stagnation, or the epic Hack without fear. And there is of course Lindsey Kuper’s epic haiku: “A systems language / pursuing the trifecta: / fast, concurrent, safe”. But I feel like we’re still missing a unified set of axioms that we can refer back to over time and use to guide us as we make decisions. Some of you will remember the Rustacean Principles, which was my first attempt at this. I’ve been dissatisfied with them for a couple of reasons, so I decided to try again. The structure is really different, so I’m calling it Rust’s design axioms. This post documents the current state – I’m quite a bit happier with it! But it’s not quite there yet. So I’ve also got a link to a repository where I’m hoping people can help improve them by opening issues with examples, counter-examples, or other thoughts.
Axioms capture the principles you use in your decision-making processWhat I’ve noticed is that when I am trying to make some decision – whether it’s a question of language design or something else – I am implicitly bringing assumptions, intuitions, and hypotheses to bear. Oftentimes, those intutions fly by very quickly in my mind, and I barely even notice them. Ah yeah, we could do X, but if we did that, it would mean Y, and I don’t want that, scratch that idea. I’m slowly learning to be attentive to these moments – whatever Y is right there, it’s related to one of my design axioms — something I’m implicitly using to shape my thinking.
I’ve found that if I can capture those axioms and write them out, they can help me down the line when I’m facing future decisions. It can also help to bring alignment to a group of people by making those intutions explicit (and giving people a chance to refute or sharpen them). Obviously I’m not the first to observe this. I’ve found Amazon’s practice of using tenets to be quite useful2, for example, and I’ve also been inspired by things I’ve read online about the importance of making your hypotheses explicit.3
In proof systems, your axioms are the things that you assert to be true and take on faith, and from which the rest of your argument follows. I choose to call these Rust’s design axioms because that seemed like exactly what I was going for. What are the starting assumptions that, followed to their conclusion, lead you to Rust? The more clearly we can articulate those assumptions, the better we’ll be able to ensure that we continue to follow them as we evolve Rust to meet future needs.
Axioms have a hypothesis and a consequenceI’ve structured the axioms in a particular way. They begin by stating the axiom itself – the core belief that we assert to be true. That is followed by a consequence, which is something that we do as a result of that core belief. To show you what I mean, here is one of the Rust design axioms I’ve drafted:
Rust users want to surface problems as early as possible, and so Rust is designed to be reliable. We make choices that help surface bugs earlier. We don’t make guesses about what our users meant to do, we let them tell us, and we endeavor to make the meaning of code transparent to its reader. And we always, always guarantee memory safety and data-race freedom in safe Rust code.
Axioms have an ordering and earlier things take priorityEach axiom is useful on its own, but where things become interesting is when they come into conflict. Consider reliability: that is a core axiom of Rust, no doubt, but is it the most important? I would argue it is not. If it were, we wouldn’t permit unsafe code, or at least not without a safety proof. I think our core axiom is actually that Rust is is meant to be used, and used for building a particular kind of program. I articulated it like this:
Rust is meant to empower everyone to build reliable and efficient software, so above all else, Rust needs to be accessible to a broad audience. We avoid designs that will be too complex to be used in practice. We build supportive tooling that not only points out potential mistakes but helps users understand and fix them.
When it comes to safety, I think Rust’s approach is eminently practical. We’ve designed a safe type system that we believe covers 90-95% of what people need to do, and we are always working to expand that scope. We to get that last 5-10%, we fallback to unsafe code. Is this as safe and reliable as it could be? No. That would be requiring 100% proofs of correctness. There are systems that do that, but they are maintained by a small handful of experts, and that idea – that systems programming is just for “wizards” – is exactly what we are trying to get away from.
To express this in our axioms, we put accessible as the top-most axiom. It defines the mission overall. But we put reliability as the second in the list, since that takes precedence over everything else.
The design axioms I really likeWithout further ado, here is my current list design axioms. Well, part of it. These are the axioms that I feel pretty good about it. The ordering also feels right to me.
We believe that…
- Rust is meant to empower everyone to build reliable and efficient software, so above all else, Rust needs to be accessible to a broad audience. We avoid designs that will be too complex to be used in practice. We build supportive tooling that not only points out potential mistakes but helps users understand and fix them.
- Rust users want to surface problems as early as possible, and so Rust is designed to be reliable. We make choices that help surface bugs earlier. We don’t make guesses about what our users meant to do, we let them tell us, and we endeavor to make the meaning of code transparent to its reader. And we always, always guarantee memory safety and data-race freedom in safe Rust code.
- Rust users are just as obsessed with quality as we are, and so Rust is extensible. We empower our users to build their own abstractions. We prefer to let people build what they need than to try (and fail) to give them everything ourselves.
- Systems programmers need to know what is happening and where, and so system details and especially performance costs in Rust are transparent and tunable. When building systems, it’s often important to know what’s going on underneath the abstractions. Abstractions should still leave the programmer feeling like they’re in control of the underlying system, such as by making it easy to notice (or avoid) certain types of operations.
…where earlier things take precedence.
The design axioms that are still a work-in-progressThese axioms are things I am less sure of. It’s not that I don’t think they are true. It’s that I don’t know yet if they’re worded correctly. Maybe they should be combined together? And where, exactly, do they fall in the ordering?
- Rust users want to focus on solving their problem, not the fiddly details, so Rust is productive. We favor APIs that where the most convenient and high-level option is also the most efficient one. We support portability across operating systems and execution environments by default. We aren’t explicit for the sake of being explicit, but rather to surface details we believe are needed.
- N✕M is bigger than N+M, and so we design for composability and orthogonality. We are looking for features that tackle independent problems and build on one another, giving rise to N✕M possibilities.
- It’s nicer to use one language than two, so Rust is versatile. Rust can’t be the best at everything, but we can make it decent for just about anything, whether that’s low-level C code or high-level scripting.
Of these, I like the first one best. Also, it follows the axiom structure better, because it starts with a hypothesis about Rust users and what they want. The other two are a bit older and I hadn’t adopted that convention yet.
Help shape the axioms!My ultimate goal is to author an RFC endorsing these axioms for Rust. But I need help to get there. Are these the right axioms? Am I missing things? Should we change the ordering?
I’d love to know what you think! To aid in collaboration, I’ve created a nikomatsakis/rust-design-axioms github repository. It hosts the current state of the axioms and also has suggested ways to contribute.
I’ve already opened issues for some of the things I am wondering about, such as:
- nikomatsakis/rust-design-axioms#1: Maybe we need a “performant” axiom? Right now, the idea of “zero-cost abstractions” and ““the default thing is also the most efficient one” feels a bit smeared across “transparent and tunable” and “productive”.
- nikomatsakis/rust-design-axioms#2: Is “portability” sufficiently important to pull out from “productivity” into its own axiom?
- nikomatsakis/rust-design-axioms#3: Are “versatility” and “orthogonality” really expressing something different from “productivity”?
-
I have a Google alert for “Rust” and I cannot tell you how often it seems that some sports teams or another shakes off Rust. I’d never heard that expression before signing up for this Google alert. ↩︎
-
I’m perhaps a bit unusual in my love for things like Amazon’s Leadership Principles. I can totally understand why, to many people, they seem like corporate nonsense. But if there’s one theme I’ve seen consistenly over my time working on Rust, it’s that process and structure are essential. Take a look at the “People Systems” keynote that Aaron, Ashley, and I gave at RustConf 2018 and you will see that theme running throughout. So many of Rust’s greatest practices – things like the teams or RFCs or public, rfcbot-based decision making – are an attempt to take some kind of informal, unstructured process and give it shape. ↩︎
-
I really like this Learning for Action page, which I admit I found just by googling for “strategy articulate a hypotheses”. I’m less into this super corporate-sounding LinkedIn post, but I have to admit I think it’s right on the money. ↩︎
The Rust Programming Language Blog: Announcing Rust 1.74.1
The Rust team has published a new point release of Rust, 1.74.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, getting Rust 1.74.1 is as easy as:
rustup update stableIf you don't have it already, you can get rustup from the appropriate page on our website.
What's in 1.74.11.74.1 resolves a few regressions introduced in 1.74.0:
- Resolved spurious STATUS_ACCESS_VIOLATIONs in LLVM
- Clarify guarantees for std::mem::discriminant
- Fix some subtyping-related regressions
Many people came together to create Rust 1.74.1. We couldn't have done it without all of you. Thanks!
Mozilla Security Blog: Mozilla VPN Security Audit 2023
To provide transparency into our ongoing efforts to protect your privacy and security on the Internet, we are releasing a security audit of Mozilla VPN that Cure53 conducted earlier this year.
The scope of this security audit included the following products:
- Mozilla VPN Qt6 App for macOS
- Mozilla VPN Qt6 App for Linux
- Mozilla VPN Qt6 App for Windows
- Mozilla VPN Qt6 App for iOS
- Mozilla VPN Qt6 App for Android
Here’s a summary of the items discovered within this security audit that the auditors rated as medium or higher severity:
- FVP-03-003: DoS via serialized intent
-
-
- Data received via intents within the affected activity should be validated to prevent the Android app from exposing certain activities to third-party apps.
- There was a risk that a malicious application could leverage this weakness to crash the app at any time.
- This risk was addressed by Mozilla and confirmed by Cure53.
-
- FVP-03-008: Keychain access level leaks WG private key to iCloud
-
-
- Cure53 confirmed that this risk has been addressed due to an extra layer of encryption, which protects the Keychain specifically with a key from the device’s secure enclave.
-
- FVP-03-009: Lack of access controls on daemon socket
-
-
- Access controls to guarantee that the user sending commands to the daemon was permitted to initiate the intended action needs to be implemented.
- This risk has been addressed by Mozilla and confirmed by Cure53.
-
- FVP-03-010: VPN leak via captive portal detection
-
-
- Cure53 advised that the captive portal detection feature be turned off by default to prevent an opportunity for IP leakage when using maliciously set up WiFi hotspots.
- Mozilla addressed the risk by no longer pinging for a captive portal outside of the VPN tunnel.
-
- FVP-03-011: Lack of local TCP server access controls
-
-
- The VPN client exposes a local TCP interface running on port 8754, which is bound to localhost. Users on localhost can issue a request to the port and disable the VPN.
- Mozilla addressed this risk as recommended by Cure53.
-
- FVP-03-012: Rogue extension can disable VPN using mozillavpnnp (High)
-
-
- mozillavpnnp does not sufficiently restrict the application caller.
- Mozilla addressed this risk as recommended by Cure53.
-
If you’d like to read the detailed report from Cure53, including all low and informational items, you can find it here.
The post Mozilla VPN Security Audit 2023 appeared first on Mozilla Security Blog.
Mozilla Privacy Blog: Mozilla Asks US Supreme Court to Support Responsible Content Moderation
Today Mozilla Corporation joined an amicus brief in a pair of important Supreme Court cases. The cases consider Texas and Florida laws that prohibit social media platforms from removing hateful and abusive content. If upheld, these laws would make content moderation impossible and would make the internet a much less safe place for all of us. Mozilla urges the Supreme Court to find them unconstitutional.
The Texas law, known as H.B. 20, would prohibit large social media sites from blocking, removing, or demonetizing content based on the viewpoint. While it provides an exception for illegal speech, this still means that platforms would be forced to host a huge range of legal but harmful content, such as outright racism or Holocaust denial. It would mandate, for example, that a page devoted to South African history must tolerate pro-Apartheid comments, or that an online community devoted to religious practice allow comments mocking religion. It would condemn all social media to rampant trolling and abuse.
Mozilla has joined a brief filed by Internet Works and other companies including Tumblr and Pinterest. The brief sets out how content moderation works in practice, and how it can vary widely depending on the goals and community of each platform. It explains how content moderation can promote speech and free association by allowing people to choose and build online communities. In Mozilla’s own social media products, our goal is to moderate in favor of a healthy community. This goal is central to our mission, which underscores our commitment to “an internet that promotes civil discourse, human dignity, and individual expression” and “that elevates critical thinking, reasoned argument, shared knowledge, and verifiable facts.”
The laws under consideration by the Court do not serve speech, but would instead destroy online communities that rely on healthy moderation. Mozilla is standing with the community and allies to call for a better future online.
The post Mozilla Asks US Supreme Court to Support Responsible Content Moderation appeared first on Open Policy & Advocacy.
IRL (podcast): The Art of AI
From Hollywood to Hip Hop, artists are negotiating new boundaries of consent for use of AI in the creative industries. Bridget Todd speaks to artists who are pushing the boundaries.
It’s not the first time artists have been squeezed, but generative AI presents new dilemmas. In this episode: a member of the AI working group of the Hollywood writers union; a singer who licenses the use of her voice to others; an emcee and professor of Black music; and an AI music company charting a different path.
Van Robichaux is a comedy writer in Los Angeles who helped craft the Writers Guild of America’s proposals on managing AI in the entertainment industry.
Holly Herndon is a Berlin-based artist and a computer scientist who has developed “Holly +”, a series of deep fake music tools for making music with Holly’s voice.
Enongo Lumumba-Kasongo creates video games and studies the intersection between AI and Hip Hop at Brown University. Her alias as a rapper is Sammus.
Rory Kenny is co-founder and CEO of Loudly, an AI music generator platform that employs musicians to train their AI instead of scraping music from the internet.
*Thank you to Sammus for sharing her track ‘1080p.’ Visit Sammus’ Bandcamp page to hear the full track and check out more of her songs.*
Hacks.Mozilla.Org: Firefox Developer Edition and Beta: Try out Mozilla’s .deb package!
A month ago, we introduced our Nightly package for Debian-based Linux distributions. Today, we are proud to announce we made our .deb package available for Developer Edition and Beta!
We’ve set up a new APT repository for you to install Firefox as a .deb package. These packages are compatible with the same Debian and Ubuntu versions as our traditional binaries.
Your feedback is invaluable, so don’t hesitate to report any issues you encounter to help us improve the overall experience.
Adopting Mozilla’s Firefox .deb package offers multiple benefits:
- you will get better performance thanks to our advanced compiler-based optimizations,
- you will receive the latest updates as fast as possible because the .deb is integrated into Firefox’s release process,
- you will get hardened binaries with all security flags enabled during compilation,
- you can continue browsing after upgrading the package, meaning you can restart Firefox at your convenience to get the latest version.
The post Firefox Developer Edition and Beta: Try out Mozilla’s .deb package! appeared first on Mozilla Hacks - the Web developer blog.
The Rust Programming Language Blog: Announcing Rustup 1.26.0
The rustup working group is happy to announce the release of rustup version 1.26.0. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of rustup installed, getting rustup 1.26.0 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running:
rustup self updateRustup will also automatically update itself at the end of a normal toolchain update:
rustup updateIf you don't have it already, you can get rustup from the appropriate page on our website.
What's new in rustup 1.26.0This version of Rustup involves a significant number of internal cleanups, both in terms of the Rustup code and its tests. In addition to a lot of work on the codebase itself, due to the length of time since the last release this one has a record number of contributors and we thank you all for your efforts and time.
The headlines for this release are:
-
Add rust-analyzer as a proxy of rustup. Now you can call rust-analyzer and it will be proxied to the rust-analyzer component for the current toolchain.
-
Bump the clap dependency from 2.x to 3.x. It's a major version bump, so there are some help text changes, but the command line interface is unchanged.
-
Remove experimental GPG signature validation and the rustup show keys command. Due to its experimental status, validating the integrity of downloaded binaries did not rely on it, and there was no option to abort the installation if a signature mismatch happened. Multiple problems with its implementation were discovered in the recent months, which led to the decision to remove the experimental code. The team is working on the design of a new signature validation scheme, which will be implemented in the future.
Full details are available in the changelog!
Rustup's documentation is also available in the rustup book.
ThanksThanks again to all the contributors who made rustup 1.26.0 possible!
- Daniel Silverstone (kinnison)
- Sabrina Jewson (SabrinaJewson)
- Robert Collins (rbtcollins)
- chansuke (chansuke)
- Shamil (shamilsan)
- Oli Lalonde (olalonde)
- 二手掉包工程师 (hi-rustin)
- Eric Huss (ehuss)
- J Balint BIRO (jbalintbiro)
- Easton Pillay (jedieaston)
- zhaixiaojuan (zhaixiaojuan)
- Chris Denton (ChrisDenton)
- Martin Geisler (mgeisler)
- Lucio Franco (LucioFranco)
- Nicholas Bishop (nicholasbishop)
- SADIK KUZU (sadikkuzu)
- darkyshiny (darkyshiny)
- René Dudfield (illume)
- Noritada Kobayashi (noritada)
- Mohammad AlSaleh (MoSal)
- Dustin Martin (dmartin)
- Ville Skyttä (scop)
- Tshepang Mbambo (tshepang)
- Illia Bobyr (ilya-bobyr)
- Vincent Rischmann (vrischmann)
- Alexander (Alovchin91)
- Daniel Brotsky (brotskydotcom)
- zohnannor (zohnannor)
- Joshua Nelson (jyn514)
- Prikshit Gautam (gautamprikshit1)
- Dylan Thacker-Smith (dylanahsmith)
- Jan David (jdno)
- Aurora (lilith13666)
- Pietro Albini (pietroalbini)
- Renovate Bot (renovate-bot)
Tiger Oakes: Alternatives to the resize event with better performance
Cameron Kaiser: April patch set for TenFourFox
However, there is one feature update in this patchset: a CSS grid whitelist. Firefox 45, which is the heavily patched underpinning of TenFourFox FPR, has a partially working implementation of CSS grid as explained in this MDN article. CSS grid layout is a more flexible and more generalized way of putting elements on a page than the earlier tables method. Go ahead and try to read that article with the current build before you pull the changes and you'll notice that the page has weirdly scrunched up elements (before a script runs and blanks the whole page with an error). After you build with the updates, you'll notice that while the page still doesn't lay out perfectly right, you can now actually read things. That's because there's a whitelist entry now in TenFourFox that allows grid automatically on developer.mozilla.org (a new layout.css.grid.host.developer.mozilla.org preference defaults to true which is checked for by new code in the CSS parser, and there is also an entry in the problematic scripts filter to block the script that ends up blanking the page when it bugs out). The other issues on that page are unrelated to CSS grid.
This will change things for people who set the global pref layout.css.grid.enabled to true, which we have never shipped in TenFourFox because of (at times significant) bugs in the implementation. This pref is now true, but unless the URL hostname is in the whitelist, CSS grid will still be disabled dynamically and is never enabled for chrome resources. If you set the global pref to false, however, then CSS grid is disabled everywhere. If you were using this for a particular site that lays out better with grid on, post the URL to issue 659 or in the comments and I'll consider adding it to the default set (or add it yourself in about:config).
The next ESR (Firefox 115) comes out end of June-early July, and we'll do the usual root updates then.
The Rust Programming Language Blog: Announcing Rust 1.69.0
The Rust team is happy to announce a nice version of Rust, 1.69.0. Rust is a programming language empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, you can get 1.69.0 with:
rustup update stableIf you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.69.0 on GitHub.
If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!
What's in 1.69.0 stableRust 1.69.0 introduces no major new features. However, it contains many small improvements, including over 3,000 commits from over 500 contributors.
Cargo now suggests to automatically fix some warningsRust 1.29.0 added the cargo fix subcommand to automatically fix some simple compiler warnings. Since then, the number of warnings that can be fixed automatically continues to steadily increase. In addition, support for automatically fixing some simple Clippy warnings has also been added.
In order to draw more attention to these increased capabilities, Cargo will now suggest running cargo fix or cargo clippy --fix when it detects warnings that are automatically fixable:
warning: unused import: `std::hash::Hash` --> src/main.rs:1:5 | 1 | use std::hash::Hash; | ^^^^^^^^^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: `foo` (bin "foo") generated 1 warning (run `cargo fix --bin "foo"` to apply 1 suggestion)Note that the full Cargo invocation shown above is only necessary if you want to precisely apply fixes to a single crate. If you want to apply fixes to all the default members of a workspace, then a simple cargo fix (with no additional arguments) will suffice.
Debug information is not included in build scripts by default anymoreTo improve compilation speed, Cargo now avoids emitting debug information in build scripts by default. There will be no visible effect when build scripts execute successfully, but backtraces in build scripts will contain less information.
If you want to debug a build script, you can add this snippet to your Cargo.toml to emit debug information again:
[profile.dev.build-override] debug = true [profile.release.build-override] debug = true Stabilized APIsThese APIs are now stable in const contexts:
- SocketAddr::new
- SocketAddr::ip
- SocketAddr::port
- SocketAddr::is_ipv4
- SocketAddr::is_ipv6
- SocketAddrV4::new
- SocketAddrV4::ip
- SocketAddrV4::port
- SocketAddrV6::new
- SocketAddrV6::ip
- SocketAddrV6::port
- SocketAddrV6::flowinfo
- SocketAddrV6::scope_id
Check out everything that changed in Rust, Cargo, and Clippy.
Contributors to 1.69.0Many people came together to create Rust 1.69.0. We couldn't have done it without all of you. Thanks!
Mozilla Thunderbird: Meet The Team: Wolf-Martell Montwe, Android Developer
Welcome to a brand new feature called “Meet The Team!” In this ongoing series of conversations, I introduce you to the people behind the software you use every day. We kicked things off by talking to Thunderbird’s Product Design Manager Alex Castellani. Now let’s meet someone much newer to the team: Wolf-Martell Montwe.
Having recently joined us from Berlin as a full-time Android developer, Wolf brings his passion for building mobile applications to the Thunderbird team. He’ll be helping to develop new features and an updated interface for K-9 Mail as we transform it into Thunderbird for Android. I spoke with him about his first computer and early gaming memories, what he hopes to accomplish for the Thunderbird mobile app, and how our community of contributors can help.
Meet The Team: Alex Castellani, Product Design Manager <figcaption class="wp-element-caption">Catch up on the “Meet The Team” series by reading my conversation with Alex Castellani</figcaption> Wolf’s Technology Origin StoryI love a great origin story, and many people working in technology seem to have one that’s directly tied to their first computer. Wolf is no exception.
“I think I started my computer journey with playing games — the first I remember is Sid Meier’s Pirates!” Wolf remembers. “Back then I had an IBM 386. Super slow, super loud! And I hacked around a lot to get games running too, to free up memory, to free up disk space because this was super limited. I think one partition was maximum 3MB! It was a big achievement if something just was running.”
Wolf’s fascination with games eventually led to some basic programming knowledge and web page development.
“I used to develop web pages, especially for my school to build up like a little forum,” he says. “I fell in love with PHP because it had one of the first editors with code completion, and that was awesome.”
What Attracted Wolf To The Thunderbird Project?“I’m a longtime Thunderbird user, and I have used K-9 Mail from 2010 on,” Wolf says. “In my last position, my task was to build up open source software. (So we developed the software and then prepared it to be open source, because the code was readable, but people couldn’t contribute.) And over that time I fall in love with developing open source, so I was looking for opportunities to to follow up on that direction. “
The Thunderbird Android Team Just Doubled In Size. Now What?Believe it or not, for many years K-9 Mail had one full-time developer (in addition to a community of contributors). So, Wolf effectively doubles the size of the core team. The first questions that came to mind: what doors does this open to the future of Thunderbird for Android, and what can Wolf and cketti accomplish during the next few months?
“First, I want to strengthen the technology base and also open it up for using more modern tooling, especially because the whole Android ecosystem is right now under a really drastic change,” Wolf explains. “It could be pretty beneficial for the project since it’s being rebranded, and think it’s good timing to then also adapt new technology and base everything on that.”
Why We’re Rebuilding The Thunderbird Interface From Scratch(The desktop version of Thunderbird is undergoing a similar transformation, as we slowly rebuild it with more modern tooling while eliminating years of technical debt.)
Wolf continues: “I think that would also open the Android app to be a little bit easier maintain from a UI side, because right now it is hard to achieve.”
It’s certainly easier for our developers — and our global team of community contributors — to improve an application and more easily add new features when the code isn’t fighting against them.
How Can The Community Help?There’s so much we can do to contribute to open source software besides writing code. So I asked Wolf: what’s the most important thing the K-9 Mail and Thunderbird community can do to help development?
“Constructive feedback on what we’re doing,” Wolf says. “Whether it’s positive or negative, I think that’s important. But please be nice!”
We certainly encourage everyone on Android to try K-9 Mail as we continue its transformation to Thunderbird. When you’re ready to give feedback or suggest ideas, we invite you to join our Thunderbird Android Planning mailing list, which is open to the public.
Talk to Wolf on Mastodon, and follow him on GitHub.
Download K-9 Mail: F-Droid | Play Store | GitHub.
The post Meet The Team: Wolf-Martell Montwe, Android Developer appeared first on The Thunderbird Blog.
IRL (podcast): Bonus Episode
We have good news to share. IRL: Online Life is Real Life has been nominated for two Webby Awards: one for Public Service and Activism and another for Technology. We need your help. We’d love it if you could go to the links below and vote for us. It’s quick and easy! Voting ends on Thursday, April 20th at midnight PDT.
Vote for IRL in the Webby Awards: Technology and Public Service Activism
It means so much to spotlight the voices and stories of folks who are making AI more trustworthy in real life, and we love to see them celebrated!
Thanks for your vote and for listening to IRL!
Cameron Kaiser: Power Mac ransomware? Yes, but it's complicated
What caught my eye in the article was a report of PowerPC builds. I can't seem to get an alleged sample to analyse (feel free to contact me at ckaiser at floodgap dawt com if you can provide one) but the source for that assertion appears to be this tweet.
Can that file run on a Power Mac? It appears it's indeed a PowerPC binary, but the executable format is ELF and not Mach-O, so the file can only run natively on Linux or another ELF-based operating system, not PowerPC Mac OS X (or, for that matter, Mac OS 9 and earlier). Even if the raw machine code were sprayed into memory for an exploitable Mac application to be tricked into running, ELF implies System V ABI, which is similar but different from the PowerOpen ABI used for PowerPC-compatible versions of Mac OS, and we haven't even started talking about system calls. Rather than a specific build targetting Power Macs, most likely this is evidence that the LockBit builders simply ran every crosscompiler variation they could find on their source code: there are no natively little-endian 32-bit PowerPC CPUs, for example, yet there's a ppcle build visible in the screenshot. Heck, there's even an s390x build. Parents, don't let your mainframes out unsupervised.
This is probably a good time to mention that I've been working on security patches for TenFourFox and a couple minor feature adjustments, so stay tuned. It's been awhile but such are hobbies.
Support.Mozilla.Org: What’s up with SUMO – Q1 2023
Hi everybody,
I know some of you have been asking about the monthly blog post since January. We’re back today, with a summary of what happened in the past 3 months. This will be our new cadence for this kind of post. So please look out for our next edition by early July.
I hope the past 3 months have treated you well. Time surely flies so fast. We’ve done a lot of internal research for the past 3 months, but in Q2, I promise you will see more of me all around our various community channels.
Welcome note and shout-outs- Welcome to Kim Jae Woo, Henry Green, Jason Hoyle, Ifeoma, Ray Vermey, Ashfaq, Hisham, Peter, Varun, and Théo. Thanks for joining the Social and Mobile Store Support program!
- Shout-outs to Tim Maks, Christophe, for participating in FOSDEM 2023! Also to Paul for his continued support for Mozfest over the years. You are all amazing!
- Thanks to everybody for your participation in the Mozilla Support 2023 contributor survey. Your input and feedback are greatly appreciated. #MozLove to you all!
If you know anyone that we should feature here, please contact Kiki, and we’ll make sure to add them in our next edition.
Community news- What happened at FOSDEM 2023? Check out this blog post!
- Learn more about Mozilla.social initiative if you’re into the fediverse world.
- Watch the recording of our community call in March if you haven’t already to learn more about SUI (Simplified User Interface) screenshot that Lucas shared.
- It’s also highly recommended to watch our community call in April to catch up on the result of the contributor survey we’ve done in Q1.
- Watch the monthly community call if you haven’t. Learn more about what’s new in January, February and March! Reminder: Don’t hesitate to join the call in person if you can. We try our best to provide a safe space for everyone to contribute. You’re more than welcome to lurk in the call if you don’t feel comfortable turning on your video or speaking up. If you feel shy to ask questions during the meeting, feel free to add your questions on the contributor forum in advance, or put them in our Matrix channel, so we can answer them during the meeting.
- If you’re an NDA’ed contributor, you can watch the recording of the Customer Experience weekly scrum meeting from AirMozilla to catch up with the latest product updates.
- Consider subscribe to Firefox Daily Digest to get daily updates about Firefox from across different platforms.
- Check out SUMO Engineering Board to see what the platform team is currently doing.
KB pageviews (*)
* KB pageviews number is a total of KB pageviews for /en-US/ only
Month Page views Vs previous month Jan 2023 7,199,541 5.53% Feb 2023 7,288,066 2.88% Mar 2023 7,485,556 2.71%Top 5 KB contributors in the last 90 days:
KB LocalizationTop 10 locales based on total page views
Locale Jan 2023pageviews (*)
Feb 2023 pageviews (*) Mar 2023pageviews (*)
Localization progress (per Apr, 17)(**) de 11.51% 10.34% 10.59% 98% fr 7.66% 6.81% 7.81% 89% zh-CN 5.05% 6.64% 7.27% 96% es 5.91% 5.67% 6.06% 25% ja 4.22% 4.11% 4.13% 46% ru 4.09% 3.98% 3.93% 100% pt-BR 3.00% 2.84% 3.39% 52% It 2.75% 2.79% 2.65% 99% pl 2.47% 2.24% 2.25% 88% zh-TW 0.61% 0.98% 1.47% 3%* Locale pageviews is an overall pageviews from the given locale (KB and other pages)
** Localization progress is the percentage of localized article from all KB articles per locale
Top 5 localization contributors in the last 90 days:
Forum SupportForum stats
Month Total questions Answer rate within 72 hrs Solved rate within 72 hrs Forum helpfulness Jan 2023 2,888 77.77% 10.28% 47.12% Feb 2023 2,752 66.10% 9.30% 54.79% Mar 2023 3,450 66.02% 8.19% 48.91%Top 5 forum contributors in the last 90 days:
Social Support Channel Total tweets Total moderation by contributors Total reply by contributors Jan 2023 314 125 42 Feb 2023 344 140 62 Mar 2023 404 171 55Top 5 Social Support contributors in the past 3 months:
Play Store Support Channel Jan 2023 Total reviews Total moderation by contributors Total reply by contributors Firefox for Android 5,710 250 90 Firefox Focus for Android 785 63 23Channel Feb 2023 Total reviews Total moderation by contributors Total reply by contributors Firefox for Android 5,025 173 46 Firefox Focus for Android 558 17 4
Channel Mar 2023 Total reviews Total moderation by contributors Total reply by contributors Firefox for Android 5,741 270 69 Firefox Focus for Android 588 29 7
Top 5 Play Store contributors in the past 3 months:
Product updatesTo catch up on product releases update, please watch the recording of the Customer Experience scrum meeting from AirMozilla. You can also subscribe to the AirMozilla folder by clickling on the Subscribe button at the top right corner of the page to get notifications each time we add a new recording.
Useful links:Frederik Braun: Examine Firefox Inter-Process Communication using JavaScript in 2023
This is my update to the 2021 JavaScript IPC blog post from the Firefox Attack & Defense blog.
Firefox uses Inter-Process Communication (IPC) to implement privilege separation, which makes it an important cornerstone in our security architecture. A previous blog post focused on fuzzing the C++ side of IPC. This blog …
Ludovic Hirlimann: My geeking plans for this summer
During July I’ll be visiting family in Mongolia but I’ve also a few things that are very geeky that I want to do.
The first thing I want to do is plug the Ripe Atlas probes I have. It’s litle devices that look like that :
They enable anybody with a ripe atlas or ripe account to make measurements for dns queries and others. This helps making a global better internet. I have three of these probes I’d like to install. It’s good because last time I checked Mongolia didn’t have any active probe. These probes will also help Internet become better in Mongolia. I’ll need to buy some network cables before leaving because finding these in mongolia is going to be challenging. More on atlas at https://atlas.ripe.net/.
The second thing I intend to do is map Mongolia a bit better on two projects the first is related to Mozilla and maps gps coordinateswith wifi access point. Only a little part of The capital Ulaanbaatar is covered as per https://location.services.mozilla.com/map#11/47.8740/106.9485 I want this to be way more because having an open data source for this is important in the future. As mapping is my new thing I’ll probably edit Openstreetmap in order to make the urban parts of mongolia that I’ll visit way more usable on all the services that use OSM as a source of truth. There is already a project to map the capital city at http://hotosm.org/projects/mongolia_mapping_ulaanbaatar but I believe osm can server more than just 50% of mongolia’s population.
I got inspired to write this post by mu son this morning, look what he is doing at 17 months :
Andrew Sutherland: Talk Script: Firefox OS Email Performance Strategies
Last week I gave a talk at the Philly Tech Week 2015 Dev Day organized by the delightful people at technical.ly on some of the tricks/strategies we use in the Firefox OS Gaia Email app. Note that the credit for implementing most of these techniques goes to the owner of the Email app’s front-end, James Burke. Also, a special shout-out to Vivien for the initial DOM Worker patches for the email app.
I tried to avoid having slides that both I would be reading aloud as the audience read silently, so instead of slides to share, I have the talk script. Well, I also have the slides here, but there’s not much to them. The headings below are the content of the slides, except for the one time I inline some code. Note that the live presentation must have differed slightly, because I’m sure I’m much more witty and clever in person than this script would make it seem…
Cover Slide: Who!
Hi, my name is Andrew Sutherland. I work at Mozilla on the Firefox OS Email Application. I’m here to share some strategies we used to make our HTML5 app Seem faster and sometimes actually Be faster.
What’s A Firefox OS (Screenshot Slide)
But first: What is a Firefox OS? It’s a multiprocess Firefox gecko engine on an android linux kernel where all the apps including the system UI are implemented using HTML5, CSS, and JavaScript. All the apps use some combination of standard web APIs and APIs that we hope to standardize in some form.
Here are some screenshots. We’ve got the default home screen app, the clock app, and of course, the email app.
It’s an entirely client-side offline email application, supporting IMAP4, POP3, and ActiveSync. The goal, like all Firefox OS apps shipped with the phone, is to give native apps on other platforms a run for their money.
And that begins with starting up fast.
Fast Startup: The Problems
But that’s frequently easier said than done. Slow-loading websites are still very much a thing.
The good news for the email application is that a slow network isn’t one of its problems. It’s pre-loaded on the phone. And even if it wasn’t, because of the security implications of the TCP Web API and the difficulty of explaining this risk to users in a way they won’t just click through, any TCP-using app needs to be a cryptographically signed zip file approved by a marketplace. So we do load directly from flash.
However, it’s not like flash on cellphones is equivalent to an infinitely fast, zero-latency network connection. And even if it was, in a naive app you’d still try and load all of your HTML, CSS, and JavaScript at the same time because the HTML file would reference them all. And that adds up.
It adds up in the form of event loop activity and competition with other threads and processes. With the exception of Promises which get their own micro-task queue fast-lane, the web execution model is the same as all other UI event loops; events get scheduled and then executed in the same order they are scheduled. Loading data from an asynchronous API like IndexedDB means that your read result gets in line behind everything else that’s scheduled. And in the case of the bulk of shipped Firefox OS devices, we only have a single processor core so the thread and process contention do come into play.
So we try not to be a naive.
Seeming Fast at Startup: The HTML Cache
If we’re going to optimize startup, it’s good to start with what the user sees. Once an account exists for the email app, at startup we display the default account’s inbox folder.
What is the least amount of work that we can do to show that? Cache a screenshot of the Inbox. The problem with that, of course, is that a static screenshot is indistinguishable from an unresponsive application.
So we did the next best thing, (which is) we cache the actual HTML we display. At startup we load a minimal HTML file, our concatenated CSS, and just enough Javascript to figure out if we should use the HTML cache and then actually use it if appropriate. It’s not always appropriate, like if our application is being triggered to display a compose UI or from a new mail notification that wants to show a specific message or a different folder. But this is a decision we can make synchronously so it doesn’t slow us down.
Local Storage: Okay in small doses
We implement this by storing the HTML in localStorage.
Important Disclaimer! LocalStorage is a bad API. It’s a bad API because it’s synchronous. You can read any value stored in it at any time, without waiting for a callback. Which means if the data is not in memory the browser needs to block its event loop or spin a nested event loop until the data has been read from disk. Browsers avoid this now by trying to preload the Entire contents of local storage for your origin into memory as soon as they know your page is being loaded. And then they keep that information, ALL of it, in memory until your page is gone.
So if you store a megabyte of data in local storage, that’s a megabyte of data that needs to be loaded in its entirety before you can use any of it, and that hangs around in scarce phone memory.
To really make the point: do not use local storage, at least not directly. Use a library like localForage that will use IndexedDB when available, and then fails over to WebSQLDatabase and local storage in that order.
Now, having sufficiently warned you of the terrible evils of local storage, I can say with a sorta-clear conscience… there are upsides in this very specific case.
The synchronous nature of the API means that once we get our turn in the event loop we can act immediately. There’s no waiting around for an IndexedDB read result to gets its turn on the event loop.
This matters because although the concept of loading is simple from a User Experience perspective, there’s no standard to back it up right now. Firefox OS’s UX desires are very straightforward. When you tap on an app, we zoom it in. Until the app is loaded we display the app’s icon in the center of the screen. Unfortunately the standards are still assuming that the content is right there in the HTML. This works well for document-based web pages or server-powered web apps where the contents of the page are baked in. They work less well for client-only web apps where the content lives in a database and has to be dynamically retrieved.
The two events that exist are:
“DOMContentLoaded” fires when the document has been fully parsed and all scripts not tagged as “async” have run. If there were stylesheets referenced prior to the script tags, the script tags will wait for the stylesheet loads.
“load” fires when the document has been fully loaded; stylesheets, images, everything.
But none of these have anything to do with the content in the page saying it’s actually done. This matters because these standards also say nothing about IndexedDB reads or the like. We tried to create a standards consensus around this, but it’s not there yet. So Firefox OS just uses the “load” event to decide an app or page has finished loading and it can stop showing your app icon. This largely avoids the dreaded “flash of unstyled content” problem, but it also means that your webpage or app needs to deal with this period of time by displaying a loading UI or just accepting a potentially awkward transient UI state.
(Trivial HTML slide)
<link rel=”stylesheet” ...> <script ...></script> DOMContentLoaded!This is the important summary of our index.html.
We reference our stylesheet first. It includes all of our styles. We never dynamically load stylesheets because that compels a style recalculation for all nodes and potentially a reflow. We would have to have an awful lot of style declarations before considering that.
Then we have our single script file. Because the stylesheet precedes the script, our script will not execute until the stylesheet has been loaded. Then our script runs and we synchronously insert our HTML from local storage. Then DOMContentLoaded can fire. At this point the layout engine has enough information to perform a style recalculation and determine what CSS-referenced image resources need to be loaded for buttons and icons, then those load, and then we’re good to be displayed as the “load” event can fire.
After that, we’re displaying an interactive-ish HTML document. You can scroll, you can press on buttons and the :active state will apply. So things seem real.
Being Fast: Lazy Loading and Optimized Layers
But now we need to try and get some logic in place as quickly as possible that will actually cash the checks that real-looking HTML UI is writing. And the key to that is only loading what you need when you need it, and trying to get it to load as quickly as possible.
There are many module loading and build optimizing tools out there, and most frameworks have a preferred or required way of handling this. We used the RequireJS family of Asynchronous Module Definition loaders, specifically the alameda loader and the r-dot-js optimizer.
One of the niceties of the loader plugin model is that we are able to express resource dependencies as well as code dependencies.
RequireJS Loader Plugins
var fooModule = require('./foo'); var htmlString = require('text!./foo.html'); var localizedDomNode = require('tmpl!./foo.html');The standard Common JS loader semantics used by node.js and io.js are the first one you see here. Load the module, return its exports.
But RequireJS loader plugins also allow us to do things like the second line where the exclamation point indicates that the load should occur using a loader plugin, which is itself a module that conforms to the loader plugin contract. In this case it’s saying load the file foo.html as raw text and return it as a string.
But, wait, there’s more! loader plugins can do more than that. The third example uses a loader that loads the HTML file using the ‘text’ plugin under the hood, creates an HTML document fragment, and pre-localizes it using our localization library. And this works un-optimized in a browser, no compilation step needed, but it can also be optimized.
So when our optimizer runs, it bundles up the core modules we use, plus, the modules for our “message list” card that displays the inbox. And the message list card loads its HTML snippets using the template loader plugin. The r-dot-js optimizer then locates these dependencies and the loader plugins also have optimizer logic that results in the HTML strings being inlined in the resulting optimized file. So there’s just one single javascript file to load with no extra HTML file dependencies or other loads.
We then also run the optimizer against our other important cards like the “compose” card and the “message reader” card. We don’t do this for all cards because it can be hard to carve up the module dependency graph for optimization without starting to run into cases of overlap where many optimized files redundantly include files loaded by other optimized files.
Plus, we have another trick up our sleeve:
Seeming Fast: Preloading
Preloading. Our cards optionally know the other cards they can load. So once we display a card, we can kick off a preload of the cards that might potentially be displayed. For example, the message list card can trigger the compose card and the message reader card, so we can trigger a preload of both of those.
But we don’t go overboard with preloading in the frontend because we still haven’t actually loaded the back-end that actually does all the emaily email stuff. The back-end is also chopped up into optimized layers along account type lines and online/offline needs, but the main optimized JS file still weighs in at something like 17 thousand lines of code with newlines retained.
So once our UI logic is loaded, it’s time to kick-off loading the back-end. And in order to avoid impacting the responsiveness of the UI both while it loads and when we’re doing steady-state processing, we run it in a DOM Worker.
Being Responsive: Workers and SharedWorkers
DOM Workers are background JS threads that lack access to the page’s DOM, communicating with their owning page via message passing with postMessage. Normal workers are owned by a single page. SharedWorkers can be accessed via multiple pages from the same document origin.
By doing this, we stay out of the way of the main thread. This is getting less important as browser engines support Asynchronous Panning & Zooming or “APZ” with hardware-accelerated composition, tile-based rendering, and all that good stuff. (Some might even call it magic.)
When Firefox OS started, we didn’t have APZ, so any main-thread logic had the serious potential to result in janky scrolling and the impossibility of rendering at 60 frames per second. It’s a lot easier to get 60 frames-per-second now, but even asynchronous pan and zoom potentially has to wait on dispatching an event to the main thread to figure out if the user’s tap is going to be consumed by app logic and preventDefault called on it. APZ does this because it needs to know whether it should start scrolling or not.
And speaking of 60 frames-per-second…
Being Fast: Virtual List Widgets
…the heart of a mail application is the message list. The expected UX is to be able to fling your way through the entire list of what the email app knows about and see the messages there, just like you would on a native app.
This is admittedly one of the areas where native apps have it easier. There are usually list widgets that explicitly have a contract that says they request data on an as-needed basis. They potentially even include data bindings so you can just point them at a data-store.
But HTML doesn’t yet have a concept of instantiate-on-demand for the DOM, although it’s being discussed by Firefox layout engine developers. For app purposes, the DOM is a scene graph. An extremely capable scene graph that can handle huge documents, but there are footguns and it’s arguably better to err on the side of fewer DOM nodes.
So what the email app does is we create a scroll-region div and explicitly size it based on the number of messages in the mail folder we’re displaying. We create and render enough message summary nodes to cover the current screen, 3 screens worth of messages in the direction we’re scrolling, and then we also retain up to 3 screens worth in the direction we scrolled from. We also pre-fetch 2 more screens worth of messages from the database. These constants were arrived at experimentally on prototype devices.
We listen to “scroll” events and issue database requests and move DOM nodes around and update them as the user scrolls. For any potentially jarring or expensive transitions such as coordinate space changes from new messages being added above the current scroll position, we wait for scrolling to stop.
Nodes are absolutely positioned within the scroll area using their ‘top’ style but translation transforms also work. We remove nodes from the DOM, then update their position and their state before re-appending them. We do this because the browser APZ logic tries to be clever and figure out how to create an efficient series of layers so that it can pre-paint as much of the DOM as possible in graphic buffers, AKA layers, that can be efficiently composited by the GPU. Its goal is that when the user is scrolling, or something is being animated, that it can just move the layers around the screen or adjust their opacity or other transforms without having to ask the layout engine to re-render portions of the DOM.
When our message elements are added to the DOM with an already-initialized absolute position, the APZ logic lumps them together as something it can paint in a single layer along with the other elements in the scrolling region. But if we start moving them around while they’re still in the DOM, the layerization logic decides that they might want to independently move around more in the future and so each message item ends up in its own layer. This slows things down. But by removing them and re-adding them it sees them as new with static positions and decides that it can lump them all together in a single layer. Really, we could just create new DOM nodes, but we produce slightly less garbage this way and in the event there’s a bug, it’s nicer to mess up with 30 DOM nodes displayed incorrectly rather than 3 million.
But as neat as the layerization stuff is to know about on its own, I really mention it to underscore 2 suggestions:
1, Use a library when possible. Getting on and staying on APZ fast-paths is not trivial, especially across browser engines. So it’s a very good idea to use a library rather than rolling your own.
2, Use developer tools. APZ is tricky to reason about and even the developers who write the Async pan & zoom logic can be surprised by what happens in complex real-world situations. And there ARE developer tools available that help you avoid needing to reason about this. Firefox OS has easy on-device developer tools that can help diagnose what’s going on or at least help tell you whether you’re making things faster or slower:
– it’s got a frames-per-second overlay; you do need to scroll like mad to get the system to want to render 60 frames-per-second, but it makes it clear what the net result is
– it has paint flashing that overlays random colors every time it paints the DOM into a layer. If the screen is flashing like a discotheque or has a lot of smeared rainbows, you know something’s wrong because the APZ logic is not able to to just reuse its layers.
– devtools can enable drawing cool colored borders around the layers APZ has created so you can see if layerization is doing something crazy
There’s also fancier and more complicated tools in Firefox and other browsers like Google Chrome to let you see what got painted, what the layer tree looks like, et cetera.
And that’s my spiel.
Links
The source code to Gaia can be found at https://github.com/mozilla-b2g/gaia
The email app in particular can be found at https://github.com/mozilla-b2g/gaia/tree/master/apps/email
(I also asked for questions here.)
Joshua Cranmer: Breaking news
The primary fear, it seems, is that knowledge that the largest open-source email client was still receiving regular updates would impel its userbase to agitate for increased funding and maintenance of the client to help forestall potential threats to the open nature of email as well as to innovate in the space of providing usable and private communication channels. Such funding, however, would be an unaffordable luxury and would only distract Mozilla from its central goal of building developer productivity tooling. Persistent rumors that Mozilla would be willing to fund Thunderbird were it renamed Firefox Email were finally addressed with the comment, "such a renaming would violate our current policy that all projects be named Persona."