13 Sep 2024

feedPlanet Mozilla

Firefox Nightly: Fantastic Firefox Fixes – These Weeks in Firefox: Issue 167

Highlights

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

New contributors (🌟 = first patch)

Project Updates

Add-ons / Web Extensions

WebExtensions Framework
WebExtension APIs
Addon Manager & about:addons

DevTools

DevTools Toolbox
WebDriver BiDi

Fluent

Lint, Docs and Workflow

Migration Improvements

New Tab Page

Privacy & Security

Profile Management

Search and Navigation

13 Sep 2024 9:25pm GMT

Mozilla Thunderbird: Thunderbird for Android/ K-9 Mail: July and August 2024 Progress Report

We're back for an update on Thunderbird for Android/K-9 Mail, combining progress reports for July and August. Did you miss our June update? Check it out! The focus over these two months has been on quality over quantity-behind each improvement is significant groundwork that reduces our technical debt and makes future feature work easier to tackle.

Material 3 Update

As we head towards the release of Thunderbird for Android, we want you to feel like you are using Thunderbird, and not just any email client. As part of that, we've made significant strides toward compatibility with Material 3 to better control coloring and give you a native feel. What do you think so far?

The final missing piece is the navigation drawer, which we believe will land in September. We've heard your feedback that the unread emails have been a bit hard to see, especially in dark mode, and have made a few other color tweaks to accompany it.

Feature Modules

If you've considered contributing as a developer to Thunderbird for Android, you may have noticed many intertwined code modules that are hard to tackle without intricate knowledge of the application. To lower the barrier of entry, we're continuing the move to a feature module system and have been refactoring code to use them. This shift improves maintainability and opens the door for unique features specific to Thunderbird for Android.

Ready to Play

Having a separate Thunderbird for Android app requires some setup in various app-stores, as well as changes to how apps are signed. While this isn't the fun feature work you'd be excited to hear about, it is foundational to getting Thunderbird for Android out of the door. We're almost ready to play, just a few legal checkboxes we need to tick.

Documentation

K-9 Mail user documentation has become outdated, still referencing older versions like K-9 Mail 6.4. Given our current resources, we've paused updates to the guide, but if you're passionate about improving documentation, we'd love your help to bring it back online! If you are interested in maintaining our user documentation, please reach out on the K-9 Forums.

Community Contributions

We've had a bunch of great contributions come in! Do you want to see your name here next time? Learn how to contribute.

The post Thunderbird for Android/ K-9 Mail: July and August 2024 Progress Report appeared first on The Thunderbird Blog.

13 Sep 2024 1:05pm GMT

12 Sep 2024

feedPlanet Mozilla

Spidermonkey Development Blog: SpiderMonkey Newsletter (Firefox 130-131)

SpiderMonkey Newsletter 130-131

Hello everyone!

I'm Bryan Thrall, just passing two and a half years on the SpiderMonkey team, and taking a try at newsletter writing.

This is our opportunity to highlight what's happened in the world of SpiderMonkey over Firefox releases 130 and 131.

I'd love to hear any feedback on the newsletter you have, positive or negative (you won't hurt my feelings). Send it to my email!

🚀 Performance

Though Speedometer 3 has shipped, we cannot allow that to let us get lax with our performance. It's important that SpiderMonkey be fast so Firefox can be fast!

⚡ Wasm

* Disabled by default while they are tested and refined.

🕸️ Web Features Work
👷🏽‍♀️ SpiderMonkey Platform Improvements

12 Sep 2024 8:33pm GMT

Will Kahn-Greene: Switching from pyenv to uv

Premise

The 0.4.0 release of uv does everything I currently do with pip, pyenv, pipx, pip-tools, and pipdeptree. Because of that, I'm in the process of switching to uv.

This blog post covers switching from pyenv to uv.

History

  • 2024-08-29: Initial writing.

  • 2024-09-12: Minor updates and publishing.

Start state

I'm running Ubuntu Linux 24.04. I have pyenv installed using the the automatic installer. pyenv is located in $HOME/.pyenv/bin/.

I have the following Pythons installed with pyenv:

$ pyenv versions
  system
  3.7.17
  3.8.19
  3.9.19
* 3.10.14 (set by /home/willkg/mozilla/everett/.python-version)
  3.11.9
  3.12.3

I'm not sure why I have 3.7 still installed. I don't think I use that for anything.

My default version is 3.10.14 for some reason. I'm not sure why I haven't updated that to 3.12, yet.

In my 3.10.14, I have the following Python packages installed:

$ pip freeze
appdirs==1.4.4
argcomplete==3.1.1
attrs==22.2.0
cffi==1.15.1
click==8.1.3
colorama==0.4.6
diskcache==5.4.0
distlib==0.3.8
distro==1.8.0
filelock==3.14.0
glean-parser==6.1.1
glean-sdk==50.1.4
Jinja2==3.1.2
jsonschema==4.17.3
MarkupSafe==2.0.1
MozPhab==1.5.1
packaging==24.0
pathspec==0.11.0
pbr==6.0.0
pipx==1.5.0
platformdirs==4.2.1
pycparser==2.21
pyrsistent==0.19.3
python-hglib==2.6.2
PyYAML==6.0
sentry-sdk==1.16.0
stevedore==5.2.0
tomli==2.0.1
userpath==1.8.0
virtualenv==20.26.2
virtualenv-clone==0.5.7
virtualenvwrapper==6.1.0
yamllint==1.29.0

That probably means I installed the following in the Python 3.10.14 Python environment:

  • MozPhab

  • pipx

  • virtualenvwrapper

Maybe I installed some other things for some reason lost in the sands of time.

Then I had a whole bunch of things installed with pipx.

I have many open source projects all of which have a .python-version file listing the Python versions the project uses.

I think that covers the start state.

Steps

First, I made a list of things I had.

  • I listed all the versions of Python I have installed so I know what I need to reinstall with uv.

    $ pyenv versions

  • I listed all the packages I have installed in my 3.10.14 environment (the default one).

    $ pip freeze

  • I listed all the packages I installed with pipx.

    $ pipx list

I uninstalled all the packages I installed with pipx.

$ pipx uninstall PACKAGE

Then I uninstalled pyenv and everything it uses. I followed the pyenv uninstall instructions:

$ rm -rf $(pyenv root)

Then I removed the bits in my shell that add to the PATH and set up pyenv and virtualenvwrapper.

Then I started a new shell that didn't have all the pyenv and virtualenvwrapper stuff in it.

Then I installed uv using the uv standalone installer.

Then I ran uv --version to make sure it was installed.

Then I installed the shell autocompletion.

$ echo 'eval "$(uv generate-shell-completion bash)"' >> ~/dotfiles/bash.d/20-uv.bash

Then I started a new shell to pick up those changes.

Then I installed Python versions:

$ uv python install 3.8 3.9 3.10 3.11 3.12
Searching for Python versions matching: Python 3.10
Searching for Python versions matching: Python 3.11
Searching for Python versions matching: Python 3.12
Searching for Python versions matching: Python 3.8
Searching for Python versions matching: Python 3.9
Installed 5 versions in 8.14s
 + cpython-3.8.19-linux-x86_64-gnu
 + cpython-3.9.19-linux-x86_64-gnu
 + cpython-3.10.14-linux-x86_64-gnu
 + cpython-3.11.9-linux-x86_64-gnu
 + cpython-3.12.5-linux-x86_64-gnu

When I type "python", I want it to be a Python managed by uv. Also, I like having "pythonX.Y" symlinks, so I created a uv-sync script which creates symlinks to uv-managed Python versions:

https://github.com/willkg/dotfiles/blob/main/dotfiles/bin/uv-sync

Then I installed all my tools using uv tool install.

$ uv tool install PACKAGE

For tox, I had to install the tox-uv package in the tox environment:

$ uv tool install --with tox-uv tox

Now I've got everything I do mostly working.

So what does that give me?

I installed uv and I can upgrade uv using uv self update.

Python interpreters are managed using uv python. I can create symlinks to interpreters using uv-sync script. Adding new interpreters and removing old ones is pretty straight-forward.

When I type python, it opens up a Python shell with the latest uv-managed Python version. I can type pythonX.Y and get specific shells.

I can use tools written in Python and manage them with uv tool including ones where I want to install them in an "editable" mode.

I can write scripts that require dependencies and it's a lot easier to run them now.

I can create and manage virtual environments with uv venv.

Next steps

Delete all the .python-version files I've got.

Update documentation for my projects and add a uv tool install PACKAGE option to installation instructions.

Probably discover some additional things to add to this doc.

12 Sep 2024 4:00pm GMT

11 Sep 2024

feedPlanet Mozilla

This Week In Rust: This Week in Rust 564

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @ThisWeekInRust on X (formerly Twitter) or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official
Foundation
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs

Crate of the Week

This week's crate is cargo-override, a cargo plugin for quick overriding of dependencies.

Thanks to Ajith for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

RFCs
Rust
Rustup

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

Updates from the Rust Project

399 pull requests were merged in the last week

Rust Compiler Performance Triage

A relatively quiet week with a majority of regressions coming in rollups which makes investigation more difficult. Luckily the regressions are relatively small and overall the week was a slight improvement in compiler performance.

Triage done by @rylev. Revision range: 6199b69c..263a3aee

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 0.6% [0.2%, 1.4%] 57
Regressions ❌
(secondary)		 0.7% [0.2%, 1.5%] 23
Improvements ✅
(primary)		 -2.2% [-4.0%, -0.4%] 23
Improvements ✅
(secondary)		 -0.3% [-0.3%, -0.2%] 10
All ❌✅ (primary) -0.2% [-4.0%, 1.4%] 80

3 Regressions, 1 Improvement, 2 Mixed; 3 of them in rollups 26 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs
Tracking Issues & PRs

Rust

Cargo

Language Team

Language Reference

Unsafe Code Guidelines

New and Updated RFCs

Upcoming Events

Rusty Events between 2024-09-11 - 2024-10-09 🦀

Virtual
Africa
Asia
Europe
North America

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Alas! We are once more bereft
of a quote to elate or explain
so this editor merely has left
the option in rhyme to complain.

- llogiq

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

11 Sep 2024 4:00am GMT

The Servo Blog: Building a browser using Servo as a web engine!

As a web engine, Servo primarily handles everything around scripting and layout. For embedding use cases, the Tauri community experimented with adding a new Servo backend, but Servo can also be used to build a browser.

We have a reference browser in the form of servoshell, which has historically been used as a minimal example and as a test harness for the Web Platform Tests. Nevertheless, the Servo community has steadily worked towards making it a browser in its own right, starting with our new browser UI based on egui last year.

This year, @wusyong, a member of Servo TSC, created the Verso project as a way to explore the features Servo needs to power a robust web browser. In this post, we'll explain what we tried to achieve, what we found, and what's next for building a browser using Servo as a web engine.

Multi-view

Of course, the first major feature we want to achieve is multiple webviews. A webview is a term abstracted from the top-level browsing context. This is what people refer to as a web page. With multi-view support, we can create multiple web pages as tabs in a single window. Most importantly, we can draw our UI with additional webviews. The main reason we want to write UI using Servo itself is that we can dogfood our own stack and verify that it can meet practical requirements, such as prompt windows, context menus, file selectors, and more.

Basic multi-view support was reviewed and merged into Servo earlier this year thanks to @delan (#30840, #30841, #30842). Verso refined that into a specific type called WebView. From there, any function that owns webviews can decide how to present them depending on their IDs. In a Verso window, two webviews are created at the moment-one for handling regular web pages and the other for handling the UI, which is currently called the Panel. The result of the showcase in Verso's README.md looks like this:

Verso displaying ASCII text in a CRT style <figcaption>Figure 1: Verso window displaying two different webviews. One for the UI, the other for the web page.</figcaption>

For now, the inter-process communication is done via Servo's existing channel messages like EmbedderMsg and EmbedderEvent. We are looking to improve the IPC mechanism with more granular control over DOM elements. So, the panel UI can be updated based on the status of web pages. One example is when the page URL is changed and the navigation bar needs to be updated. There are some candidates for this, such as WebDriverCommandMsg. @webbeef also started a discussion about defining custom elements like <webview> for better ergonomics. Overall, improving IPC will be the next target to research after initial multi-view support. We will also define more specific webview types to satisfy different purposes in the future.

Multi-window

The other prominent feature after multi-view is the ability to support multiple windows. This one wasn't planned at first, but because it affects too many components, we ended up resolving them together from the ground up.

Servo uses WebRender, based on OpenGL, to render its layout. To support multiple windows, we need to support multiple OpenGL surfaces. One approach would be to create separate OpenGL contexts for each window. But since our implementations of WebGL, WebGPU, and WebXR are all tied to a single WebRender instance, which in turn only supports a single OpenGL context for now, we chose to use a single context with multiple surfaces. This alternative approach could potentially use less memory and spawn fewer threads. For more details, see this series of blog posts by @wusyong.

Verso displaying two windows <figcaption>Figure 2: Verso creates two separate windows with the same OpenGL context.</figcaption>

There is still room for improvement. For example, WebRender currently only supports rendering a single "document". Unless we create multiple WebRender instances, like Firefox does, we have one WebRender document that has to constantly update all of its display lists to show on all of our windows. This could potentially lead to race conditions where a webview may draw to the wrong window for a split second.

There are also different OpenGL versions across multiple platforms, which can be challenging to configure and link. Verso is experimenting with using Glutin for better configuration and attempting to get closer to the general Rust ecosystem.

What's next?

With multi-view and multi-window support as the fundamental building blocks, we could create more UI elements to keep pushing the envelope of our browser and embedding research. At the same time, Servo is a huge project, with many potential improvements still to come, so we want to reflect on our progress and decide on our priorities. Here are some directions that are worth pursuing.

Benchmarking and metrics

We want to gather the strength of the community to help us track the statistics of supported CSS properties and web APIs in Servo by popularity order and benchmark results such as jetstream2 and speedometer3. @sagudev already started a subset of speedometer3 to experiment. We hope this will eventually give newcomers a better overview of Servo.

Script triage

There's a Servo triage meeting every two weeks to triage any issues around the script crate and more. Once we get the statistics of supported web APIs, we can find the most popular ones that haven't been implemented or fixed yet. We are already fixing some issues around loading the order and re-implementing ReadableStream in Rust. If you are interested in implementing web APIs in Servo, feel free to join the next meeting.

Multi-process and sandboxing

Some features are crucial to the browser but not visible to users. Multi-process architecture and sandboxing belong to this category. Both of these are implemented in Servo to some extent, but only on Linux and macOS right now, and neither of the features are enabled by default.

We would like to improve these features and validate them in CI workflows. In the meantime, we are looking for people who can extend our sandbox to Windows via Named Pipes and AppContainer Isolation.

Acknowledgments

This work was sponsored by NLNet and the Next Generation Internet initiative. We are grateful the European Commission shares the same vision for a better and more open browser ecosystem.

NLNet Logo NGI Logo

11 Sep 2024 12:00am GMT

10 Sep 2024

feedPlanet Mozilla

Mozilla Thunderbird: Why Use a Mail Client vs Webmail

Many of us Thunderbird users often forget just how convenient using a mail client can be. But as webmail has become more popular over the last decade, some new users might not know the difference between the two, and why you would want to swap your browser for a dedicated app.

In today's digital world, email remains a cornerstone of personal and professional communication. Managing emails, however, can be a daunting task especially when you have multiple email accounts with multiple service providers to check and keep track of. Thankfully, decades ago someone invented the email client application. While web-based solutions have taken off in recent years, they can't quite replace the need for managing emails in one dedicated place.

Let's go back to the basics: What is the difference between an email service provider and an email client application? And more importantly, can we make a compelling case for why an email client like Thunderbird is not just relevant in today's world, but essential in maintaining productivity and sanity in our fast-paced lives?

An email service provider (ESP) is a company that offers services for sending, receiving, and storing emails. Popular examples include Gmail, Yahoo Mail, Hotmail and Proton Mail. These services offer web-based interfaces, allowing users to access their emails from any device with an internet connection.

On the other hand, an email client application is software installed on your device that allows you to manage any or all of those email accounts in one dedicated app. Examples include Thunderbird, Microsoft Outlook, and Apple Mail. Email clients offer a unified platform to access multiple email accounts, calendars, tasks, and contacts, all in one place. They retrieve emails from your ESP using protocols like IMAP or POP3 and provide advanced features for organizing, searching, and composing emails.

Despite the convenience of web-based email services, email client applications play a huge role in enhancing productivity and efficiency. Webmail is a juggling game of switching tabs, logins, and sometimes wildly different interfaces. This fragmented approach can steal your time and your focus.

So, how can an email client help with all of that?

One Inbox - All Your Accounts

As already mentioned, an email client eliminates the need to switch between different browser tabs or sign in and out of accounts. Combine your Gmail, Yahoo, and other accounts so you can read, reply to, and search through the emails using a single application. For even greater convenience, you can opt for a unified inbox view, where emails from all your different accounts are combined into a single inbox.

Work Offline - Anywhere

Email clients store your emails locally on your device, so you can access and compose emails even without an internet connection. This is really useful when you're travelling or in areas with poor connectivity. You can draft responses, organize your inbox, and synchronize your changes once you're back online.

Thunderbird email client

Enhanced Productivity

Email clients come packed with features designed to boost productivity. These include advanced search capabilities across multiple accounts, customizable filters and rules, as well as integration with calendar and task management tools. Features like email templates and delayed sending can streamline your workflow even more.

Care About Privacy?

Email clients offer enhanced security features, such as encryption and digital signatures, to protect your sensitive information. With local storage, you have more control over your data compared to relying solely on a web-based ESP.

No More Clutter and Distractions

Web-based email services often come with ads, sometimes disguised as emails, and other distractions. Email clients, on the other hand, provide a cleaner ad-free experience. It's just easier to focus with a dedicated application just for email. Not having to reply on a browser for this purpose means less chance of getting sidetracked by latest news, social media, and random Google searches.

All Your Calendars in One Place

Last but not least, managing your calendar, or multiple calendars, is easier with an email client. You can sync calendars from various accounts, set reminders, and schedule meetings all in one place. This is particularly useful when handling calendar invites from different accounts, as it allows you to easily shift meetings between calendars or maintain one main calendar to avoid double booking.

Calendar view in Thunderbird


So, if you're not already using an email client, perhaps this post has given you a few good reasons to at least try it out. An email client can help you organize your busy digital life, keep all your email and calendar accounts in one place, and even draft emails during your next transatlantic flight with non-existent or questionable Wi-Fi.

And just as email itself has evolved over the past decades, so have email client applications. They'll adapt to modern trends and get enhanced with the latest features and integrations to keep everyone organized and productive - in 2024 and beyond.

The post Why Use a Mail Client vs Webmail appeared first on The Thunderbird Blog.

10 Sep 2024 1:27pm GMT

07 Sep 2024

feedPlanet Mozilla

Don Marti: AI legal links

part 1: copyright

Generative AI's Illusory Case for Fair Use by Jacqueline Charlesworth :: SSRN The exploitation of copied works for their intrinsic expressive value sharply distinguishes AI copying from that at issue in the technological fair use cases relied upon by AI's fair use advocates. In these earlier cases, the determination of fair use turned on the fact that the alleged infringer was not seeking to capitalize on expressive content-exactly the opposite of generative AI.

Urheberrecht und Training generativer KI-Modelle - technologische und juristische Grundlagen by Tim W. Dornis, Sebastian Stober :: SSRN Even if AI training occurs outside Europe, developers cannot fully avoid European copyright laws. If works are replicated inside an AI model, making the model available in Europe could infringe the right of making available under Article 3 of the InfoSoc Directive. (while the US tech industry plays with the IT equivalent of shoplifting comic books, the EU has grown-up problems to worry about.)

Case Tracker: Artificial Intelligence, Copyrights and Class Actions is a useful page maintained by attorneys at Baker & Hostetler LLP. Good for keeping track of what's where in the court system.

Copyright lawsuits pose a serious threat to generative AI The core question in fair use analysis is whether a new product acts as a substitute for the product being copied, or whether it transforms the old product into something new and distinctive. In the Google Books case, for example, the courts had no trouble finding that a book search engine was a new, transformative product that didn't in any way compete with the books it was indexing. Google wasn't making new books. Stable Diffusion is creating new images. And while Google could guarantee that its search engine would never display more than three lines of text from any page in a book. Stability AI can't make a similar promise. To the contrary, we know that Stable Diffusion occasionally generates near-perfect copies of images from its training data.

part 2: defamation

KI-Chat macht Tübinger Journalisten zum Kinderschänder - SWR Aktuell

OpenAI, ChatGPT facing defamation case in Gwinnett County Georgia | 11alive.com

part 3: antitrust

Hausfeld files globally significant antitrust class action against Google for abusive use of digital media content Publishers have no economically viable or practical way to stop [Google Search Generative Experience] SGE from plagiarizing their content and siphoning away referral traffic and ad revenue. SGE uses the same web crawler as Google's general search service: GoogleBot. This means the only way to block SGE from plagiarizing content is to block GoogleBot completely-and disappear from Google Search.

The Case for Vigilance in AI Markets - ProMarket (competition regulators in the USA, EU, and UK are getting involved)

part 4: false advertising

(case in which a generative AI ad system outputs an ad that misrepresents product features TK)

part 3: misc

Meta AI Keeps Telling Strangers It Owns My Phone Number - Business Insider

Related

AI models are being blocked from fresh data - except the trash - Pivot to AI We knew LLMs were running out of data as they had indexed pretty much the entire public Web and they still sucked. But increasingly AI company crawlers are being blocked from collecting more - especially data of any quality

NaNoWriMo Shits The Bed On Artificial Intelligence (imho they'll figure this out before November, either the old org will reform or a new one will launch. Recording artist POVs on Napster were varied, writer POVs on generative AI, not so much.)

Is AI a Silver Bullet? - Ian Cooper - Staccato Signals TDD becomes a powerful tool when you ask the AI to implement code for your tests (TDD is already a powerful tool, and LLMs could be a good force multiplier. Not just writing code that you can filter the bullshit out of by adding tests, but also by suggesting tests that your code should be able to pass. If the LLM outputs a test that obviously shouldn't pass but does, then you can fix your code sooner. If I had to guess I would say that programming language advocacy scenes are going to figure out the licensing for training sets first. If the coding assistant in the IDE can train on zillions of lines of a certain language because of a programmer co-op agreement, that's an advantage for the language.)

Why A.I. Isn't Going to Make Art

Have we stopped to think about what LLMs actually model? Big corporations like Meta and Google tend to exaggerate and make misleading claims that do not stand up to scrutiny. Obviously, as a cognitive scientist who has the expertise and understanding of human language, it's disheartening to see a lot of these claims made without proper evidence to back them up. But they also have downstream impacts in various domains. If you start treating these massive complex engineering systems as language understanding machines, it has implications in how policymakers and regulators think about them.

Slop is Good Search engines you can't trust because they are cesspools of slop is hard to imagine. But that end feels inevitable at this point. We will need a new web. (I tend to agree with this. Search engine company management tends to be so ideologically committed to busting the search quality raters union, and other labor organizing by indirect employees, or TVCs, that they will destroy the value of the search engine to do it.)

07 Sep 2024 12:00am GMT

05 Sep 2024

feedPlanet Mozilla

The Rust Programming Language Blog: Announcing Rust 1.81.0

The Rust team is happy to announce a new version of Rust, 1.81.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.81.0 with:

$ rustup update stable

If 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.81.0.

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.81.0 stable

core::error::Error

1.81 stabilizes the Error trait in core, allowing usage of the trait in #![no_std] libraries. This primarily enables the wider Rust ecosystem to standardize on the same Error trait, regardless of what environments the library targets.

New sort implementations

Both the stable and unstable sort implementations in the standard library have been updated to new algorithms, improving their runtime performance and compilation time.

Additionally, both of the new sort algorithms try to detect incorrect implementations of Ord that prevent them from being able to produce a meaningfully sorted result, and will now panic on such cases rather than returning effectively randomly arranged data. Users encountering these panics should audit their ordering implementations to ensure they satisfy the requirements documented in PartialOrd and Ord.

#[expect(lint)]

1.81 stabilizes a new lint level, expect, which allows explicitly noting that a particular lint should occur, and warning if it doesn't. The intended use case for this is temporarily silencing a lint, whether due to lint implementation bugs or ongoing refactoring, while wanting to know when the lint is no longer required.

For example, if you're moving a code base to comply with a new restriction enforced via a Clippy lint like undocumented_unsafe_blocks, you can use #[expect(clippy::undocumented_unsafe_blocks)] as you transition, ensuring that once all unsafe blocks are documented you can opt into denying the lint to enforce it.

Clippy also has two lints to enforce the usage of this feature and help with migrating existing attributes:

Lint reasons

Changing the lint level is often done for some particular reason. For example, if code runs in an environment without floating point support, you could use Clippy to lint on such usage with #![deny(clippy::float_arithmetic)]. However, if a new developer to the project sees this lint fire, they need to look for (hopefully) a comment on the deny explaining why it was added. With Rust 1.81, they can be informed directly in the compiler message:

error: floating-point arithmetic detected
 --> src/lib.rs:4:5
  |
4 |     a + b
  |     ^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#float_arithmetic
  = note: no hardware float support
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(clippy::float_arithmetic, reason = "no hardware float support")]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^

Stabilized APIs

These APIs are now stable in const contexts:

Compatibility notes

Split panic hook and panic handler arguments

We have renamed std::panic::PanicInfo to std::panic::PanicHookInfo. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0.

core::panic::PanicInfo will remain unchanged, however, as this is now a different type.

The reason is that these types have different roles: std::panic::PanicHookInfo is the argument to the panic hook in std context (where panics can have an arbitrary payload), while core::panic::PanicInfo is the argument to the #[panic_handler] in #![no_std] context (where panics always carry a formatted message). Separating these types allows us to add more useful methods to these types, such as std::panic::PanicHookInfo::payload_as_str() and core::panic::PanicInfo::message().

Abort on uncaught panics in extern "C" functions

This completes the transition started in 1.71, which added dedicated "C-unwind" (amongst other -unwind variants) ABIs for when unwinding across the ABI boundary is expected. As of 1.81, the non-unwind ABIs (e.g., "C") will now abort on uncaught unwinds, closing the longstanding soundness problem.

Programs relying on unwinding should transition to using -unwind suffixed ABI variants.

WASI 0.1 target naming changed

Usage of the wasm32-wasi target (which targets WASI 0.1) will now issue a compiler warning and request users switch to the wasm32-wasip1 target instead. Both targets are the same, wasm32-wasi is only being renamed, and this change to the WASI target is being done to enable removing wasm32-wasi in January 2025.

Fixes CVE-2024-43402

std::process::Command now correctly escapes arguments when invoking batch files on Windows in the presence of trailing whitespace or periods (which are ignored and stripped by Windows).

See more details in the previous announcement of this change.

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.81.0

Many people came together to create Rust 1.81.0. We couldn't have done it without all of you. Thanks!

05 Sep 2024 12:00am GMT

The Rust Programming Language Blog: Changes to `impl Trait` in Rust 2024

The default way impl Trait works in return position is changing in Rust 2024. These changes are meant to simplify impl Trait to better match what people want most of the time. We're also adding a flexible syntax that gives you full control when you need it.

TL;DR

Starting in Rust 2024, we are changing the rules for when a generic parameter can be used in the hidden type of a return-position impl Trait:

The new explicit syntax is called a "use bound": impl Trait + use<'x, T>, for example, would indicate that the hidden type is allowed to use 'x and T (but not any other generic parameters in scope).

Read on for the details!

Background: return-position impl Trait

This blog post concerns return-position impl Trait, such as the following example:

fn process_data(
    data: &[Datum]
) -> impl Iterator<Item = ProcessedDatum> {
    data
        .iter()
        .map(|datum| datum.process())
}

The use of -> impl Iterator in return position here means that the function returns "some kind of iterator". The actual type will be determined by the compiler based on the function body. It is called the "hidden type" because callers do not get to know exactly what it is; they have to code against the Iterator trait. However, at code generation time, the compiler will generate code based on the actual precise type, which ensures that callers are fully optimized.

Although callers don't know the exact type, they do need to know that it will continue to borrow the data argument so that they can ensure that the data reference remains valid while iteration occurs. Further, callers must be able to figure this out based solely on the type signature, without looking at the function body.

Rust's current rules are that a return-position impl Trait value can only use a reference if the lifetime of that reference appears in the impl Trait itself. In this example, impl Iterator<Item = ProcessedDatum> does not reference any lifetimes, and therefore capturing data is illegal. You can see this for yourself on the playground.

The error message ("hidden type captures lifetime") you get in this scenario is not the most intuitive, but it does come with a useful suggestion for how to fix it:

help: to declare that
      `impl Iterator<Item = ProcessedDatum>`
      captures `'_`, you can add an
      explicit `'_` lifetime bound
  |
5 | ) -> impl Iterator<Item = ProcessedDatum> + '_ {
  |                                           ++++

Following a slightly more explicit version of this advice, the function signature becomes:

fn process_data<'d>(
    data: &'d [Datum]
) -> impl Iterator<Item = ProcessedDatum> + 'd {
    data
        .iter()
        .map(|datum| datum.process())
}

In this version, the lifetime 'd of the data is explicitly referenced in the impl Trait type, and so it is allowed to be used. This is also a signal to the caller that the borrow for data must last as long as the iterator is in use, which means that it (correctly) flags an error in an example like this (try it on the playground):

let mut data: Vec<Datum> = vec![Datum::default()];
let iter = process_data(&data);
data.push(Datum::default()); // <-- Error!
iter.next();

Usability problems with this design

The rules for what generic parameters can be used in an impl Trait were decided early on based on a limited set of examples. Over time we have noticed a number of problems with them.

not the right default

Surveys of major codebases (both the compiler and crates on crates.io) found that the vast majority of return-position impl trait values need to use lifetimes, so the default behavior of not capturing is not helpful.

not sufficiently flexible

The current rule is that return-position impl trait always allows using type parameters and sometimes allows using lifetime parameters (if they appear in the bounds). As noted above, this default is wrong because most functions actually DO want their return type to be allowed to use lifetime parameters: that at least has a workaround (modulo some details we'll note below). But the default is also wrong because some functions want to explicitly state that they do NOT use type parameters in the return type, and there is no way to override that right now. The original intention was that type alias impl trait would solve this use case, but that would be a very non-ergonomic solution (and stabilizing type alias impl trait is taking longer than anticipated due to other complications).

hard to explain

Because the defaults are wrong, these errors are encountered by users fairly regularly, and yet they are also subtle and hard to explain (as evidenced by this post!). Adding the compiler hint to suggest + '_ helps, but it's not great that users have to follow a hint they don't fully understand.

incorrect suggestion

Adding a + '_ argument to impl Trait may be confusing, but it's not terribly difficult. Unfortunately, it's often the wrong annotation, leading to unnecessary compiler errors -- and the right fix is either complex or sometimes not even possible. Consider an example like this:

fn process<'c, T> {
    context: &'c Context,
    data: Vec<T>,
) -> impl Iterator<Item = ()> + 'c {
    data
        .into_iter()
        .map(|datum| context.process(datum))
}

Here the process function applies context.process to each of the elements in data (of type T). Because the return value uses context, it is declared as + 'c. Our real goal here is to allow the return type to use 'c; writing + 'c achieves that goal because 'c now appears in the bound listing. However, while writing + 'c is a convenient way to make 'c appear in the bounds, also means that the hidden type must outlive 'c. This requirement is not needed and will in fact lead to a compilation error in this example (try it on the playground).

The reason that this error occurs is a bit subtle. The hidden type is an iterator type based on the result of data.into_iter(), which will include the type T. Because of the + 'c bound, the hidden type must outlive 'c, which in turn means that T must outlive 'c. But T is a generic parameter, so the compiler requires a where-clause like where T: 'c. This where-clause means "it is safe to create a reference with lifetime 'c to the type T". But in fact we don't create any such reference, so the where-clause should not be needed. It is only needed because we used the convenient-but-sometimes-incorrect workaround of adding + 'c to the bounds of our impl Trait.

Just as before, this error is obscure, touching on the more complex aspects of Rust's type system. Unlike before, there is no easy fix! This problem in fact occurred frequently in the compiler, leading to an obscure workaround called the Captures trait. Gross!

We surveyed crates on crates.io and found that the vast majority of cases involving return-position impl trait and generics had bounds that were too strong and which could lead to unnecessary errors (though often they were used in simple ways that didn't trigger an error).

inconsistencies with other parts of Rust

The current design was also introducing inconsistencies with other parts of Rust.

async fn desugaring

Rust defines an async fn as desugaring to a normal fn that returns -> impl Future. You might therefore expect that a function like process:

async fn process(data: &Data) { .. }

...would be (roughly) desugared to:

fn process(
    data: &Data
) -> impl Future<Output = ()> {
    async move {
        ..
    }
}

In practice, because of the problems with the rules around which lifetimes can be used, this is not the actual desugaring. The actual desugaring is to a special kind of impl Trait that is allowed to use all lifetimes. But that form of impl Trait was not exposed to end-users.

impl trait in traits

As we pursued the design for impl trait in traits (RFC 3425), we encountered a number of challenges related to the capturing of lifetimes. In order to get the symmetries that we wanted to work (e.g., that one can write -> impl Future in a trait and impl with the expected effect), we had to change the rules to allow hidden types to use all generic parameters (type and lifetime) uniformly.

Rust 2024 design

The above problems motivated us to take a new approach in Rust 2024. The approach is a combination of two things:

The new explicit syntax is called a "use bound": impl Trait + use<'x, T>, for example, would indicate that the hidden type is allowed to use 'x and T (but not any other generic parameters in scope).

Lifetimes can now be used by default

In Rust 2024, the default is that the hidden type for a return-position impl Trait values use any generic parameter that is in scope, whether it is a type or a lifetime. This means that the initial example of this blog post will compile just fine in Rust 2024 (try it yourself by setting the Edition in the Playground to 2024):

fn process_data(
    data: &[Datum]
) -> impl Iterator<Item = ProcessedDatum> {
    data
        .iter()
        .map(|datum| datum.process())
}

Yay!

Impl Traits can include a use<> bound to specify precisely which generic types and lifetimes they use

As a side-effect of this change, if you move code to Rust 2024 by hand (without cargo fix), you may start getting errors in the callers of functions with an impl Trait return type. This is because those impl Trait types are now assumed to potentially use input lifetimes and not only types. To control this, you can use the new use<> bound syntax that explicitly declares what generic parameters can be used by the hidden type. Our experience porting the compiler suggests that it is very rare to need changes -- most code actually works better with the new default.

The exception to the above is when the function takes in a reference parameter that is only used to read values and doesn't get included in the return value. One such example is the following function indices(): it takes in a slice of type &[T] but the only thing it does is read the length, which is used to create an iterator. The slice itself is not needed in the return value:

fn indices<'s, T>(
    slice: &'s [T],
) -> impl Iterator<Item = usize> {
    0 .. slice.len()
}

In Rust 2021, this declaration implicitly says that slice is not used in the return type. But in Rust 2024, the default is the opposite. That means that callers like this will stop compiling in Rust 2024, since they now assume that data is borrowed until iteration completes:

fn main() {
    let mut data = vec![1, 2, 3];
    let i = indices(&data);
    data.push(4); // <-- Error!
    i.next(); // <-- assumed to access `&data`
}

This may actually be what you want! It means you can modify the definition of indices() later so that it actually does include slice in the result. Put another way, the new default continues the impl Trait tradition of retaining flexibility for the function to change its implementation without breaking callers.

But what if it's not what you want? What if you want to guarantee that indices() will not retain a reference to its argument slice in its return value? You now do that by including a use<> bound in the return type to say explicitly which generic parameters may be included in the return type.

In the case of indices(), the return type actually uses none of the generics, so we would ideally write use<>:

fn indices<'s, T>(
    slice: &'s [T],
) -> impl Iterator<Item = usize> + use<> {
    //                             -----
    //             Return type does not use `'s` or `T`
    0 .. slice.len()
}

Implementation limitation. Unfortunately, if you actually try the above example on nightly today, you'll see that it doesn't compile (try it for yourself). That's because use<> bounds have only partially been implemented: currently, they must always include at least the type parameters. This corresponds to the limitations of impl Trait in earlier editions, which always must capture type parameters. In this case, that means we can write the following, which also avoids the compilation error, but is still more conservative than necessary (try it yourself):

fn indices<T>(
    slice: &[T],
) -> impl Iterator<Item = usize> + use<T> {
    0 .. slice.len()
}

This implementation limitation is only temporary and will hopefully be lifted soon! You can follow the current status at tracking issue #130031.

Alternative: 'static bounds. For the special case of capturing no references at all, it is also possible to use a 'static bound, like so (try it yourself):

fn indices<'s, T>(
    slice: &'s [T],
) -> impl Iterator<Item = usize> + 'static {
    //                             -------
    //             Return type does not capture references.
    0 .. slice.len()
}

'static bounds are convenient in this case, particularly given the current implementation limitations around use<> bounds, but use<> bound are more flexible overall, and so we expect them to be used more often. (As an example, the compiler has a variant of indices that returns newtype'd indices I instead of usize values, and it therefore includes a use<I> declaration.)

Conclusion

This example demonstrates the way that editions can help us to remove complexity from Rust. In Rust 2021, the default rules for when lifetime parameters can be used in impl Trait had not aged well. They frequently didn't express what users needed and led to obscure workarounds being required. They led to other inconsistencies, such as between -> impl Future and async fn, or between the semantics of return-position impl Trait in top-level functions and trait functions.

Thanks to editions, we are able to address that without breaking existing code. With the newer rules coming in Rust 2024,

Appendix: Relevant links

05 Sep 2024 12:00am GMT

04 Sep 2024

feedPlanet Mozilla

Frédéric Wang: My recent contributions to Gecko (3/3)

Note: This blog post was written on June 2024. As of September 2024, final work to ship the feature is still in progress. Please follow bug 1797715 for the latest updates.

Introduction

This is the final blog post in a series about new web platform features implemented in Gecko, as part as an effort at Igalia to increase browser interoperability.

Let's take a look at fetch priority attributes, which enable web developers to optimize resource loading by specifying the relative priority of resources to be fetched by the browser.

Fetch priority

The web.dev article on fetch priority explains in more detail how web developers can use fetch priority to optimize resource loading, but here's a quick overview.

fetchpriority is a new attribute with the value auto (default behavior), high, or low. Setting the attribute on a script, link or img element indicates whether the corresponding resource should be loaded with normal, higher, or lower priority 1:

<head>
  <script src="high.js" fetchpriority="high"></script>
  <link rel="stylesheet" href="auto.css" fetchpriority="auto">
</head>
<body>
  <img src="low.png" alt="low" fetchpriority="low">
</body>

The priority can also be set in the RequestInit parameter of the fetch() method:

await fetch("high.txt", {priority: "high"});

The <link> element has some interesting features. One of them is combining rel=preload and as to fetch a resource with a particular destination 2:

<link rel="preload" as="font" href="high.woff2" fetchpriority="high">

You can even use Link in HTTP response headers and in particular early hints sent before the final response:

103 Early Hint
Link: <high.js>; rel=preload; as=script; fetchpriority=high

These are basically all the places where a fetch priority attribute can be used.

Note that other parameters are also taken into account when deciding the priority to use for resources, such as the position of the element in the page (e.g. blocking resources in <head>), other attributes on the element (<script async>, <script defer>, <link media>, <link rel>…) or the resource's destination.

Finally, some browsers implement speculative HTML parsing, allowing them to continue fetching resources declared in the HTML markup while the parser is blocked. As far as I understand, Firefox has its own separate HTML parsing code for that purpose, which also has to take fetch priority attributes into account.

Implementation-defined prioritization

If you have not run away after reading the complexity described in the previous section, let's talk a bit more about how fetch priority attributes are interpreted. The spec contains the following step when fetching a resource (emphasis mine):

If request's internal priority is null, then use request's priority, initiator, destination, and render-blocking in an implementation-defined manner to set request's internal priority to an implementation-defined object.

So browsers would use the high/low/auto hints as well as the destination in order to calculate an internal priority value 3, but the details of this value are not provided in the specification, and it's up to the browser to decide what to do. This is a bit unfortunate for our interoperability goal, but that's probably the best we can do, given that each browser already has its own stategies to optimize resource loading. I think this also gives browsers some flexibility to experiment with optimizations… which can be hard to predict when you realize that web devs also try to adapt their content to the behavior of (the most popular) browsers!

In any case, the spec authors were kind enough to provide a note with more suggestions (emphasis mine):

The implementation-defined object could encompass stream weight and dependency for HTTP/2, priorities used in Extensible Prioritization Scheme for HTTP for transports where it applies (including HTTP/3), and equivalent information used to prioritize dispatch and processing of HTTP/1 fetches. [RFC9218]

OK, so what does that mean? I'm not a networking expert, but this is what I could gather after discussing with the Necko team and reading some HTTP specs:

Note that various parts of Firefox rely on NS_NewChannel to load resources, including the fetching algorithm above, which Firefox uses to implement the fetch() method. However, other cases mentioned in the first section have their own code paths with their own calls to NS_NewChannel, so these places must also be adjusted to take the fetch priority and destination into account.

Finishing the implementation work

Summarizing a bit, implementing fetch priority is a matter of:

  1. Adding fetchpriority to DOM objects for HTMLImageElement, HTMLLinkElement, HTMLScriptElement, and RequestInit.
  2. Parsing the fetch priority attribute into an auto/low/high enum.
  3. Passing the information to the callers of NS_NewChannel.
  4. Using that information to set the internal priority.
  5. Using that internal priority for HTTP requests.

Mirko Brodesser started this work in June 2023, and had already implemented almost all of the features discussed above. fetch(), <img>, and <link rel=preload as=image> were handled by Ziran Sun and I, while Valentin Gosu from Mozilla made HTTP requests use the internal priority.

The main blocker was due to that "implementation-defined" use of fetch priority. Mirko's approach was to align Firefox with the behavior described in the web.dev article, which reflects Chromium's implementation. But doing so would mean changing Firefox's default behavior when fetchpriority is not specified (or explicitly set to auto), and it was not clear whether Chromium's prioritization choices were the best fit for Firefox's own implementation of resource loading.

After meeting with Mozilla, we agreed on a safer approach:

  1. Introduce runtime preferences to control how Firefox adjusts internal priorities when low, high, or auto is specified. By default, auto does not affect the internal priority so current behavior is preserved.
  2. Ask Mozilla's performance team to run an experiment, so we can decide the best values for these preferences.
  3. Ship fetch priority with the chosen values, probably cleaning things up a bit. Any other ideas, including the ones described in the web.dev article, could be handled in future enhancements.

We recently entered phase 2 of this plan, so fingers crossed it works as expected!

Internal WPT tests

This project is part of the interoperability effort, but again, the "implementation-defined" part meant that we had very few WPT tests for that feature, really only those checking fetchpriority attributes for the DOM part.

Fortunately Mirko, who is a proponent of Test-driven development, had written quite a lot of internal WPT tests that use internal APIs to retrieve the internal priority. To test Link headers, he used the handy wptserve pipes. The only thing he missed was checking support in Early hints, but some WPT tests for early hints using WPT Python Handlers were available, so integrating them into Mirko's tests was not too difficult.

It was also straightforward for Ziran and I to extend Mirko's tests to cover fetch, img, and <link rel=preload as=image>, with one exception: when the fetch() method uses a non-default destination. In most of these code paths, we call NS_NewChannel to perform a fetch. But fetch() is tricky, because if the fetch event is intercepted, the event handler might call the fetch() method again using the same destination (e.g. image).

Handling this correctly involves multiple processes and IPC communication, which ended up not working well with the internal APIs used by Mirko's tests. It took me a while to understand what was happening in bug 1881040, and in the end I came up with a new approach.

Upstreamable WPT tests

First, let's pause for a moment: all the tests we have so far use an internal API to verify the internal priority, but they don't actually check how that internal priority is used by Firefox when it sends HTTP requests. Valentin mentioned we should probably have some tests covering that, and not only would it solve the problem with fetch() calls in fetch event handlers, it would also remove the use of an internal API, making the tests potentially reusable by other browsers.

To make this kind of test possible, I added a WPT Python Handler that parses the urgency from a HTTP request and responds with an urgency-dependent resource, such as a stylesheet with different property values, an image of a different size, or an audio or video file of a different duration.

When a test uses resources with different fetch priorities, this influences the urgency values of their HTTP requests, which in turn influences the response in a way that the test can check for in JavaScript. This is a bit complicated, but it works!

Conclusion

Fetch priority has been enabled in Firefox Nightly for a while, and experiments started recently to determine the optimal priority adjustments. If everything goes well, we will be able to push this feature to the finish line after the (northern) summer.

Helping implement this feature also gave me the opportunity to work a bit on the Firefox networking code, which I had not touched since the collaboration with IPFS, and I learned a lot about resource loading and WPT features for HTTP requests.

To me, the "implementation-defined" part was still a bit awkward for the web platform. We had to write our own internal WPT tests and do extra effort to prepare the feature for shipping. But in the end, I believe things went relatively smoothly.

Acknowledgments

To conclude this series of blog posts, I'd also like to thank Alexander Surkov, Cathie Chen, Jihye Hong, Martin Robinson, Mirko Brodesser, Oriol Brufau, Ziran Sun, and others at Igalia who helped on implementing these features in Firefox. Thank you to Emilio Cobos, Olli Pettay, Valentin Gosu, Zach Hoffman, and others from the Mozilla community who helped with the implementation, reviews, tests and discussions. Finally, our spelling and grammar expert Delan Azabani deserves special thanks for reviewing this series of blog post and providing useful feedback.

  1. Other elements have been or are being considered (e.g. <iframe>, SVG <image> or SVG <script>), but these are the only ones listed in the HTML spec at the time of writing. ↩

  2. As mentioned below, the browser needs to know about the actual destination in order to properly calculate the priority. ↩

  3. As far as I know, Firefox does not take initiator into account, nor does it support render-blocking yet. ↩

04 Sep 2024 10:00pm GMT

Mozilla Thunderbird: Thunderbird Monthly Development Digest: August 2024

Hello Thunderbird Community! It's August, where did our summer go? (or winter for the folks on the other hemisphere).

Our August has been packed with ESR fixes, team conferences, and some personal time off, so this is gonna be a bit of a shorter update, tackling more upcoming efforts than what recently landed on daily. Miss our last update? Find it here.

More Rust

If you've been looking at our monthly metrics you might have noticed that the % of Rust code in our code base is slowly increasing.

We're planning to push forward this effort in the near future with more protocol reworks and clean up of low level code.

Stay tuned for more updates on this matter and some dedicated posts from the engineers that are driving this effort.

Pushing forward with Exchange

Nothing new to report here, other than that we're continuing with this implementation and we hope to be able to enable this feature by default in a not so far off Beta.

The general objective before next ESR is to have complete email support and start tapping into Calendar and Address Book integration to offer the full experience out of the box.

Global database

This is also one of the most important pieces of work that we've been planning for a while. Bringing this to completion will drastically reduce our most common data loss problems as well as drastically speeding up the performance of Thunderbird when it comes to internal message search and archiving.

Calendar rebuild

Another very large initiative we're kicking off during this new ESR cycle is a complete rebuild of our Calendar.

Not only are we going to clean up and improve our back-end code handling protocols and synchronization, but we're also taking a hard look at our UI and UX, in order to provide a more flexible and intuitive experience, reducing the amount of dialogs, and implementing those features that users have come to expect from any calendaring application.

As usual, if you want to see things as they land you can always check the pushlog and try running daily, which would be immensely helpful for catching bugs early.

See ya next month.

Alessandro Castellani (he, him)
Director, Desktop and Mobile Apps

If you're interested in joining the technical discussion around Thunderbird development, consider joining one or several of our mailing list groups here.

The post Thunderbird Monthly Development Digest: August 2024 appeared first on The Thunderbird Blog.

04 Sep 2024 12:00pm GMT

This Week In Rust: This Week in Rust 563

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @ThisWeekInRust on X (formerly Twitter) or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Miscellaneous

Crate of the Week

This week's crate is vimania-uri-rs, a VIM plugin for file and URI handling.

Thanks to sysid for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

RFCs
Rust
Rustup

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

Updates from the Rust Project

416 pull requests were merged in the last week

Rust Compiler Performance Triage

This week we had some trouble with our performance bot, but luckily the issue has been resolved. In the end, we saw much more improvements than regressions.

Triage done by @kobzol. Revision range: acb4e8b6..6199b69c

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 0.3% [0.2%, 0.4%] 8
Regressions ❌
(secondary)		 0.7% [0.2%, 1.5%] 9
Improvements ✅
(primary)		 -0.8% [-3.4%, -0.2%] 158
Improvements ✅
(secondary)		 -0.7% [-2.3%, -0.2%] 96
All ❌✅ (primary) -0.7% [-3.4%, 0.4%] 166

2 Regressions, 3 Improvements, 1 Mixed; 3 of them in rollups 19 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs
Tracking Issues & PRs

Rust

Cargo

Language Team

Language Reference

Unsafe Code Guidelines

New and Updated RFCs

Upcoming Events

Rusty Events between 2024-09-04 - 2024-10-02 🦀

Virtual
Africa
Asia
Europe
North America

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.

Because I wrote it in Rust.

- Asahi Lina on vt.social

Thanks to Ludwig Stecher for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

04 Sep 2024 4:00am GMT

The Rust Programming Language Blog: Security advisory for the standard library (CVE-2024-43402)

On April 9th, 2024, the Rust Security Response WG disclosed CVE-2024-24576, where std::process::Command incorrectly escaped arguments when invoking batch files on Windows. We were notified that our fix for the vulnerability was incomplete, and it was possible to bypass the fix when the batch file name had trailing whitespace or periods (which are ignored and stripped by Windows).

The severity of the incomplete fix is low, due to the niche conditions needed to trigger it. Note that calculating the CVSS score might assign a higher severity to this, but that doesn't take into account what is required to trigger the incomplete fix.

The incomplete fix is identified by CVE-2024-43402.

Overview

Refer to the advisory for CVE-2024-24576 for details on the original vulnerability.

To determine whether to apply the cmd.exe escaping rules, the original fix for the vulnerability checked whether the command name ended with .bat or .cmd. At the time that seemed enough, as we refuse to invoke batch scripts with no file extension.

Unfortunately, Windows removes trailing whitespace and periods when parsing file paths. For example, .bat. . is interpreted by Windows as .bat, but our original fix didn't check for that.

Mitigations

If you are affected by this, and you are using Rust 1.77.2 or greater, you can remove the trailing whitespace (ASCII 0x20) and trailing periods (ASCII 0x2E) from the batch file name to bypass the incomplete fix and enable the mitigations.

Rust 1.81.0, due to be released on September 5th 2024, will update the standard library to apply the CVE-2024-24576 mitigations to all batch files invocations, regardless of the trailing chars in the file name.

Affected versions

All Rust versions before 1.81.0 are affected, if your code or one of your dependencies invoke a batch script on Windows with trailing whitespace or trailing periods in the name, and pass untrusted arguments to it.

Acknowledgements

We want to thank Kainan Zhang (@4xpl0r3r) for responsibly disclosing this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us disclose the incomplete fix: Chris Denton for developing the fix, Amanieu D'Antras for reviewing the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish Goregaokar and Josh Stone for coordinating this disclosure.

04 Sep 2024 12:00am GMT

03 Sep 2024

feedPlanet Mozilla

Mozilla Addons Blog: Developer Spotlight: AudD® Music Recognition

AudD identifies an obscure song in a DJ set.

We've all been there. You're streaming music on Firefox and a great song plays but you have no idea what it's called or who the artist is. If your phone is handy you could install a music recognition app, but that's a clunky experience involving two devices. It would be a lot better to just click a button on Firefox and have the AudD® Music Recognition extension fetch you song details.

"And if you're listening on headphones," adds Mikhail Samin, CEO of AudD, "using a phone app is a nightmare. We tried to make learning what's playing as uncomplicated as possible for users." Furthermore, Samin claims browser based music recognition is more accurate than mobile apps because audio doesn't get distorted by speakers or a microphone.

Of course, making things amazing and simple for users often requires complex engineering.

"It's one thing for the browser to play audio from a source, such as an audio or video file on a webpage, to a destination connected to the device, like speakers," explains Samin. "It's another thing if a new and external part of the browser wants to add itself to the list of destinations. It isn't straightforward to make an extension that successfully does that… Fortunately, we got some help from the awesome add-ons developer community. We went to the Matrix room."

AudD is built to recognize any song from anywhere so long as it's been properly published on digital streaming platforms. Samin says one of his team's main motivations for developing AudD is simply the joy of connecting music fans with new artists, so install AudD to make sure you never miss another great musical discovery. If you've got any new ideas or feedback for the AudD team, they're always eager to hear from users.

Do you have an intriguing extension development story? Do tell! Maybe your story should appear on this blog. Contact us at amo-featured [at] mozilla [dot] org and let us know a bit about your extension development journey.

The post Developer Spotlight: AudD® Music Recognition appeared first on Mozilla Add-ons Community Blog.

03 Sep 2024 5:30pm GMT

Firefox Developer Experience: Firefox WebDriver Newsletter 130

WebDriver is a remote control interface that enables introspection and control of user agents. As such it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional).

This newsletter gives an overview of the work we've done as part of the Firefox 130 release cycle.

Contributions

Firefox - including our WebDriver implementation - is developed as an open source project, and everyone is welcome to contribute. If you ever wanted to contribute to an open source project used by millions of users, or are interested in some experience in software development, jump in.

We are always grateful to receive external contributions, here are the ones which made it in Firefox 130:

WebDriver code is written in JavaScript, Python, and Rust so any web developer can contribute! Read how to setup the work environment and check the list of mentored issues for Marionette.

General

Bug fixes

WebDriver BiDi

New: Support for the "browsingContext.navigationFailed" event

When automating websites, navigation is a common scenario that requires careful handling, especially when it comes to notifying clients if the navigation fails. The new "browsingContext.navigationFailed" event is designed to assist with this by allowing clients to register for and receive events when a navigation attempt is unsuccessful. The payload of the event is similar to all the other already available navigation specific events.

Bug fixes

Marionette (WebDriver classic)

Bug fixes

03 Sep 2024 1:24pm GMT