mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - https://planet.mozilla.org/
Bijgewerkt: 2 weken 17 uur geleden

Mozilla Thunderbird: Help Keep Thunderbird Alive and Thriving In 2023

di, 22/11/2022 - 17:35

Roc, the Thunderbird mascot

A few short years ago Thunderbird was on the verge of extinction. But you saved us! This year we began work on an Android version of Thunderbird, made excellent progress toward next year’s “Supernova” release, and hired more talented software engineers, developers, and designers to help us make Thunderbird better than ever in 2023.

Putting YOU In Control — Not A Corporation

Since 2003, part of our mission has been giving you a customizable communication experience full of powerful features. The other part of Thunderbird’s mission is more personal: Respecting your privacy and putting you in control – not a corporation. 

We never show advertisements, and we never sell your data. That’s because Thunderbird is completely funded by gifts from generous people just like you. You keep this great software free, and you keep us thriving! 

But accomplishing this mission is expensive. Consistently improving Thunderbird and keeping it competitive means ensuring your security in a constantly changing landscape of mail providers. It means maintaining complex server infrastructure. It means fixing bugs and updating old code. It means striving for full accessibility and a refreshing, modern design. 

Help Thunderbird Thrive In 2023

So today, we’re asking for your help. Did you know that development of Thunderbird is funded by less than 1% of the people who use and enjoy it? 

If you find value in using Thunderbird, please consider giving a gift to support it. Your contributions make a huge difference. And if you’ve already donated this year, THANK YOU!

Thank you for using Thunderbird, and thank you for trusting us with your important daily communications. 

The post Help Keep Thunderbird Alive and Thriving In 2023 appeared first on The Thunderbird Blog.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Improving Firefox stability with this one weird trick

di, 22/11/2022 - 15:16

The first computer I owned shipped with 128 KiB of RAM and to this day I’m still jarred by the idea that applications can run out of memory given that even 15-year-old machines often shipped with 4 GiB of memory. And yet it’s one of the most common causes of instability experienced by users and in the case of Firefox the biggest source of crashes on Windows.

As such, at Mozilla, we spend significant resources trimming down Firefox memory consumption and carefully monitoring the changes. Some extra efforts have been spent on the Windows platform because Firefox was more likely to run out of memory there than on macOS or Linux. And yet none of those efforts had the impact of a cool trick we deployed in Firefox 105.

But first things first, to understand why applications running on Windows are more prone to running out of memory compared to other operating systems it’s important to understand how Windows handles memory.

All modern operating systems allow applications to allocate chunks of the address space. Initially these chunks only represent address ranges that aren’t backed by physical memory unless data is stored in them. When an application starts using a bit of address space it has reserved, the OS will dedicate a chunk of physical memory to back it, possibly swapping out some existing data if need be. Both Linux and macOS work this way, and so does Windows except that it requires an extra step compared to the other OSes.

After an application has requested a chunk of address space it needs to commit it before being able to use it. Committing a range requires Windows to guarantee it can always find some physical memory to back it. Afterwards, it behaves just like Linux and macOS. As such Windows limits how much memory can be committed to the sum of the machine’s physical memory plus the size of the swap file.

This resource – known as commit space – is a hard limit for applications. Memory allocations will start to fail once the limit is reached. In operating system speech this means that Windows does not allow applications to overcommit memory.

One interesting aspect of this system is that an application can commit memory that it won’t use. The committed amount will still count against the limit even if no data is stored in the corresponding areas and thus no physical memory has been used to back the committed region. When we started analyzing out of memory crashes we discovered that many users still had plenty of physical memory available – sometimes gigabytes of it – but were running out of commit space instead.

Why was that happening? We don’t really know but we made some educated guesses: Firefox tracks all the memory it uses and we could account for all the memory that we committed directly.

However, we have no control over Windows system libraries and in particular graphics drivers. One thing we noticed is that graphics drivers commit memory to make room for textures in system memory. This allows them to swap textures out of the GPU memory if there isn’t enough and keep them in system memory instead. A mechanism that is similar to how regular memory can be swapped out to disk when there is not enough RAM available. In practice, this rarely happens, but these areas still count against the limit.

We had no way of fixing this issue directly but we still had an ace up our sleeve: when an application runs out of memory on Windows it’s not outright killed by the OS, its allocation simply fails and it can then decide what it does by itself.

In some cases, Firefox could handle the failed allocation, but in most cases, there is no sensible or safe way to handle the error and it would need to crash in a controlled way… but what if we could recover from this situation instead? Windows automatically resizes the swap file when it’s almost full, increasing the amount of commit space available. Could we use this to our advantage?

It turns out that the answer is yes, we can. So we adjusted Firefox to wait for a bit instead of crashing and then retry the failed memory allocation. This leads to a bit of jank as the browser can be stuck for a fraction of a second, but it’s a lot better than crashing.

There’s also another angle to this: Firefox is made up of several processes and can survive losing all of them but the main one. Delaying a main process crash might lead to another process dying if memory is tight. This is good because it would free up memory and let us resume execution, for example by getting rid of a web page with runaway memory consumption.

If a content process died we would need to reload it if it was the GPU process instead the browser would briefly flash while we relaunched it; either way, the result is less disruptive than a full browser crash. We used a similar trick in Firefox for Android and Firefox OS before that and it worked well on both platforms.

This little trick shipped in Firefox 105 and had an enormous impact on Firefox stability on Windows. The chart below shows how many out-of-memory browser crashes were experienced by users per active usage hours:

Firefox trick

You’re looking at a >70% reduction in crashes, far more than our rosiest predictions.

And we’re not done yet! Stalling the main process led to a smaller increase in tab crashes – which are also unpleasant for the user even if not nearly as annoying as a full browser crash – so we’re cutting those down too.

Last but not least we want to improve Firefox behavior in low-memory scenarios by responding differently to cases where we’re low on commit space and cases where we’re low on physical memory, this will reduce swapping and help shrink Firefox footprint to make room for other applications.

I’d like to send special thanks to my colleague Raymond Kraesig who implemented this “trick”, carefully monitored its impact and is working on the aforementioned improvements.

The post Improving Firefox stability with this one weird trick appeared first on Mozilla Hacks - the Web developer blog.

Categorieën: Mozilla-nl planet

The Mozilla Blog: The best gift for anyone who wants to feel safer when they go online: Mozilla privacy products

ma, 21/11/2022 - 15:00

The holidays are a wonderful time of the year where we are happily shopping for unique gifts for loved ones online. It also means we’re sharing our personal information online like giving out email addresses or phone numbers to sign up for discount programs or creating new accounts. Whenever we go online, we are asked to give our personal information, which can end up in the wrong hands. Once our information is out there and publicly available it’s even tougher to get it back. 

Here at Mozilla, a mission-driven company with a 20-year track record of fighting for online privacy and a healthier internet, we get that. Our privacy products, Firefox Relay and Mozilla VPN, have helped people feel safer when they go online and have blocked more than 1.5 million unwanted emails from people’s inboxes while keeping their real email addresses safe from trackers across the web. So, wherever you go online with Mozilla’s trusted products and services, your information is safer. 

Mozilla’s privacy products include Firefox Relay which hides your real email address and masks your phone number, and Mozilla VPN, our fast and easy-to-use VPN service, that helps protect the privacy of your network traffic. Together they help you keep what you do online private. And now, we are making it easier to get both Firefox Relay and Mozilla VPN together — for $6.99 a month when you sign up for an annual subscription. Whether you currently use one or none of these products, here’s more information on what makes these products a must-have whenever you go online. 

Mozilla privacy product #1: Firefox Relay

Since the launch of Firefox Relay, thousands of users have signed up for our smart, easy solution that hides their real email address to help protect their identity. This year, we continued to look to our users to improve and shape their Firefox Relay experience. In 2022, we added user-requested features which included increasing the email limit size to 10 MB and making Firefox Relay available as a Chrome extension. For Firefox Relay Premium users, we added a phone number mask feature to protect personal phone numbers. Whether you are signing up for loyalty programs, booking a restaurant reservation, or making purchases that require your phone number, now you can feel confident that your personal phone number won’t fall in the wrong hands. You can read more about the phone number mask feature here. Firefox Relay has helped keep thousands of people’s information safe. Check out the great coverage in The Verge, Popular Science, Consumer Reports and PCMag

Mozilla privacy product  #2: Mozilla VPN 

This year, Mozilla VPN, our fast and easy-to-use Virtual Private Network service, integrated with one of our users’ favorite Firefox Add-ons, Multi-Account Containers, to offer a unique, privacy solution that is only available in Firefox. We also included the ability to multi-hop, which means that you can use two VPN servers instead of one for extra protection. You can read more about this feature here. To date, thousands of people have signed up to Mozilla VPN, which provides device-level network traffic protection as you go on the web. Besides our loyal users, there are numerous news articles (Consumer Reports, Washington Post, KTLA-TV and The Verge) that can tell you more about how a VPN can help whenever you use the web. 

Better Together: Firefox Relay and Mozilla VPN

If there’s one person you shouldn’t forget on your list, it’s giving yourself the gift of privacy with Mozilla’s products. And now we’re offering Firefox Relay and Mozilla VPN together at $6.99 a month, when you sign up for an annual subscription. 

Developed by Mozilla, we are committed to innovate and deliver new products like Mozilla VPN and Firefox Relay. We know that it’s more important than ever for you to be safe, and for you to know that what you do online is your own business. By subscribing to our products, users support both Mozilla’s product development and our mission to build a better web for all. 

Subscribe today either from the Mozilla VPN or Firefox Relay site.

The post The best gift for anyone who wants to feel safer when they go online: Mozilla privacy products  appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Talospace Project: Firefox 107 on POWER

vr, 18/11/2022 - 02:50
Firefox 107 is out, a modest update, though there are some developer-facing changes. As before linking still requires Dan Horák's patch from bug 1775202 or the browser won't link on 64-bit Power ISA (alternatively put --disable-webrtc in your .mozconfig if you don't need WebRTC). Otherwise the build works with the .mozconfigs from Firefox 105 and the PGO-LTO patch from Firefox 101.
Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox Regional feedback: Let's start with Europe

vr, 18/11/2022 - 01:00

We work hard as an organization to ship the best browser possible every 4 weeks with about 1000 new patches per release.

We ship new features to make our browser useful and easy to use. We also do platform work to be able to render new sites and web applications while remaining compatible with millions of websites created a decade (or more) ago.

This ongoing work also includes updating our translations in more than 100 languages thanks to our impressive community of localizers.

Yes, we want to make sure that Firefox can be used everywhere by everybody.

But could we maybe do better with a tighter feedback loop from our local communities?

Let’s give a few examples from our bug tracker:

Usually, major issues that may impact users in a specific country are fixed before we ship the final release, but occasionally we discover them after shipping and have to ship a fix in a dot release.

We talked about significant breakage with a regional impact, but what about papercuts?

Web compatibility, incorrect translations, internationalization issues, PiP subtitles support, certificates… The list of potential problems in a region that may affect our users is long and we may not know about them.

Maybe these issues are discussed in places we don’t know about, in languages we don’t speak. Maybe these issues are already filed in our bug tracker but don’t get prioritized correctly because we don’t know about their regional impact. Maybe a handful of specific regional issues are making Firefox hard to use in a specific country and the information is out there. Maybe all we need is somebody who understands these issues to surface these bugs in Bugzilla to our developers.

In a nutshell, we don’t know what we don’t know.

That is why I intend to work on studying and setting up basic feedback mechanisms to evaluate the health of Firefox in a few European countries so as to help my team (Release Management) prioritize product fixes for existing bugs which have the highest impact on our users and also to get help identifying regressions on our pre-release channels (Nightly, Beta, Developer Edition).

My very first goal is to make contacts with Mozillians in a handful of European countries (France, Germany, Italy, Poland, Spain) 1 that could help me identify issues that affect them locally, identify their top web compatibility issues, and maybe relay a general message for community feedback on pre-release channels.

To that effect, I created a Local Firefox room on the Mozilla Matrix instance. If you are interested in collaborating with me on this project, you are very welcome to join it and say hello (my nick is Pascal). I can speak with you in French and Spanish as well if you don’t feel comfortable speaking in English.

Thanks!

Pascal

  1. I am focusing on a few European countries for timezone and bandwidth reasons since I’ll do that alongside my role as a Firefox Release Manager, but I am open to feedback from other regions as well of course. 

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Manifest v3 signing available November 21 on Firefox Nightly

do, 17/11/2022 - 15:00

Starting November 21, 2022 add-on developers are welcome to upload their Firefox Manifest version 3 (MV3) compatible extensions to addons.mozilla.org (AMO) and have them signed as MV3 extensions. Getting an early jump on MV3 signing enables you to begin testing your extension’s future functionality on Nightly to ensure a smooth eventual transition to MV3 in Firefox.

To be clear, Firefox will continue to support MV2 extensions for the foreseeable future, even as we welcome MV3 extensions in the release to general availability in Firefox 109 (January 17, 2023). Our goal has been to ensure a seamless transition from MV2 to MV3 for extension developers. Taking a gradual approach and gathering feedback as MV3 matures, we anticipate opportunities will emerge over time to modify our initial MV3 offering. In these instances, we intend to take the time necessary to make informed decisions about our approach.

Towards the end of 2023 — once we’ve had time to evaluate and assess MV3’s rollout (including identifying important MV2 use cases that will persist into MV3) — we’ll decide on an appropriate timeframe to deprecate MV2. Once this timeframe is established, we’ll communicate MV2’s closure process with advance notice. For now, please see this guide for supporting both MV2 and MV3 versions of your extension on AMO.

Mozilla’s vision for Firefox MV3

Firefox MV3 offers simplified and consolidated APIs, enhanced security and privacy mechanisms, and functionality to better support mobile platforms. As we continue to collaborate with other browser vendors and the developer community to shape MV3, we recognize cross-browser compatibility as a fundamental consideration. That said, we’re also implementing distinct elements to suit Firefox’s product and community needs. We want to give extension developers creative flexibility and choice, while ensuring users maintain access to the highest standards of extension customization and security. Firefox MV3 stands apart from other iterations of MV3 in two critical ways:

  1. While other browser vendors introduced declarativeNetRequest (DNR) in favor of blocking Web Request in MV3, Firefox MV3 continues to support blocking Web Request and will support a compatible version of DNR in the future. We believe blocking Web Request is more flexible than DNR, thus allowing for more creative use cases in content blockers and other privacy and security extensions. However, DNR also has important performance and compatibility characteristics we want to support.
  2. Firefox MV3 offers Event Pages as the background script in lieu of service workers, though we plan to support service workers in the future for compatibility. Event Pages offer benefits like DOM and Web APIs that aren’t available to service workers, while also generally providing a simpler migration path.

Over subsequent releases next year, we’ll continue to expand Firefox MV3 compatibility.

MV3 also ushers an exciting user interface change in the form of the new extensions button (already available on Firefox Nightly). This will give users direct control over which extensions can access specific web sites.

The extensions button will give Firefox users direct control over website specific extension permissions.

Users are able to review, grant, or revoke MV3 extension access to any website. MV2 extensions will display in the button interface, but permissions access is unavailable. Please see this post for more information about the new extensions button.

If you’re planning to migrate your MV2 extension to MV3, there are steps you can take today to get started. We always encourage feedback from our developer community, so don’t hesitate to get in touch:

The post Manifest v3 signing available November 21 on Firefox Nightly appeared first on Mozilla Add-ons Community Blog.

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Extensions button and how to handle permissions in Manifest V3

do, 17/11/2022 - 12:46

Manifest V3 (MV3) is bringing new user-facing changes to Firefox, including an extensions button to manage installed and enabled browser extension permissions (origin controls), providing Firefox users control over extension access to their browsers. The first building blocks of this button were added to Nightly in Firefox 107 and will become available with the general release of MV3 in Firefox 109.

Extensions button

The extensions button will give Firefox users direct control over website specific extension permissions.

In MV2, host permissions are granted by the user at the time of install and there’s no elegant way for the user to change this setting (short of uninstalling/reinstalling and choosing different permissions). But with the new extensions button in MV3 in Firefox, users will have easy access and persistent control over which extensions can access any web page, at any time. Users are free to grant ongoing access to a website, or make a choice per visit. To enable this, MV3 treats host permissions (listed in the extension manifest) as opt-in.

The button panel will display the user’s installed and enabled extensions and their current permission state. In addition to managing host permissions, the panel also allows the user to manage, remove, or report the extension. Extensions with browser actions will behave similarly in the toolbar as in the panel.

Manifest V2 (MV2) extensions will also display in the panel; however users can’t take actions for MV2 host permissions since those were granted at installation and this choice cannot be reversed in MV2 without uninstalling the extension and starting again.

You can also find more information about the extensions button from support.mozilla.org

How to deal with opt-in permissions in extension code

The Permissions API provides a way for developers to read and request permissions.

With permissions.request(), you can request specific permissions that have been defined as optional permissions in the manifest:

const permissionsToRequest = { permissions: ["bookmarks", "history"], origins: ["https://developer.mozilla.org/"] } async function requestPermissions() { function onResponse(response) { if (response) { console.log("Permission was granted"); } else { console.log("Permission was refused"); } return browser.permissions.getAll(); } const response = await browser.permissions.request(permissionsToRequest); const currentPermissions = await onResponse(response); console.log(`Current permissions:`, currentPermissions); }

This is handy when the request for permissions is tied to a user action like selecting a context menu item. Note that you cannot request for a permission that is not defined in the manifest.

Other times, you’ll want to react to a permission being granted or removed. This can be done with permissions.onAdded and permissions.onRemoved respectively.

function handleAdded(permissions) { console.log(`New API permissions: ${permissions.permissions}`); console.log(`New host permissions: ${permissions.origins}`); } browser.permissions.onAdded.addListener(handleAdded);

Finally, you can check for already existing permissions in two different ways: permissions.getAll() returns a list of all granted permissions and permissions.contains(permissionsToCheck) checks for specific permissions and resolves to true if, and only if, all checked permissions are granted.

// Extension permissions are: // "webRequest", "tabs", "*://*.mozilla.org/*" let testPermissions1 = { origins: ["*://mozilla.org/"], permissions: ["tabs"] }; const testResult1 = await browser.permissions.contains(testPermissions1); console.log(testResult1); // true

We always encourage feedback from our developer community, so don’t hesitate to get in touch:

The post Extensions button and how to handle permissions in Manifest V3 appeared first on Mozilla Add-ons Community Blog.

Categorieën: Mozilla-nl planet

Mozilla Privacy Blog: Mozilla Comments on FTC’s “Commercial Surveillance and Data Security” Advance Notice of Proposed Rulemaking

di, 15/11/2022 - 23:32

Like regulators around the world, the US Federal Trade Commission (FTC) is exploring the possibility of new rules to protect consumer privacy online. We’re excited to see the FTC take this important step and ask key questions surrounding commercial surveillance and data security practices, from advertising and transparency to data collection and deceptive design practices.

Mozilla has a long track record on privacy. It’s an integral aspect of our Manifesto, where we state that individuals’ security and privacy on the internet are fundamental and must not be treated as optional. It’s evidenced in our products and in our collaboration with others in industry to forge solutions to create a better, more private online experience.

But we can’t do it alone. Without rules of the road, sufficient incentive won’t exist to shift the rest of the industry to more privacy preserving practices. To meet that need, we’ve called for comprehensive privacy legislation like the American Data Privacy and Protection Act (ADPPA), greater ad transparency, and strong enforcement around the world. In our latest submission to the FTC, we detail the urgent need for US regulators and policymakers to take action to create a healthier internet.

At a high level, our comments focus on:

Privacy Practices Online: Everyone should have control over their personal data, understand how it’s obtained and used, and be able to access, modify, or delete it. To that end, Mozilla has long advocated for companies to adopt better privacy practices through our Lean Data Practices methodology. It’s also important that rules govern not just the collection of data, but the uses of that data in order to limit harmful effects – from the impact of addictive user interfaces on kids to the use of recommendation systems to discrimination in housing and jobs.

Privacy Preserving Advertising: The way in which advertising is conducted today is broken and causes more harm than good.  At the same time, we believe there’s nothing inherently wrong with digital advertising. It supports a large section of services provided on the web and it is here to stay, in some form. A combination of new research, technical solutions, increased public awareness, and effective regulatory enforcement can reform advertising for the future of the web.

Deceptive Design Practices: Consumers are being tricked into handing over their data with deceptive patterns, then that data is used to manipulate them. The use of deceptive design patterns results in consumer harms including limited or frustrated choice, lower quality, lower innovation, poor privacy, and unfair contracts. This is bread-and-butter deception – the online manifestation of what the FTC was established to address – and it is critical that the FTC has the authority to take action against such deception.

Automated Decision Making Systems (ADMS): For years, research and investigative reporting have uncovered instances of ADMS that cause or enable discrimination, surveillance, or other harms to individuals and communities. The risks stemming from ADMS are particularly grave where these systems affect, for example, people’s livelihoods, safety, and liberties. We need enforceable rules that hold developers and deployers of ADMS to a higher standard, built on the pillars of transparency, accountability, and redress.

Systemic Transparency and Data Sharing: We encourage the FTC to strengthen the mechanisms that empower policymakers and trusted experts to better understand what is happening on major internet platforms. To achieve this, we need greater access to platform data (subject to strong user privacy protections), greater research tooling, and greater protections for researchers.

Practices surrounding consumer data on the internet today, and the resulting societal harms, have put people and trust at risk. The future of privacy online requires industry to step up to protect and empower people online, and demands that lawmakers and regulators implement frameworks that create the ecosystem and incentive for a better internet ahead.

To read Mozilla’s full submission, click here.

The post Mozilla Comments on FTC’s “Commercial Surveillance and Data Security” Advance Notice of Proposed Rulemaking appeared first on Open Policy & Advocacy.

Categorieën: Mozilla-nl planet

Mozilla Accessibility: Significant Improvements for Screen Readers Now in Nightly Firefox

di, 15/11/2022 - 17:00

A couple of months ago, we shared an update on our Cache the World project, covering the ongoing re-write of the Firefox accessibility engine. The project aims to improve Firefox’s overall performance for users of assistive technologies (ATs) like screen readers and to reduce crashes and hangs. It will also make the accessibility engine easier to maintain and simplify adding new features going forward.

In our last post, we provided instructions for enabling the new engine in Firefox Nightly by changing an experimental setting and encouraged adventurous Windows OS users to opt in and try it out. Thanks to your testing and feedback, and further work by the engineering team, the new Firefox accessibility engine is now solid enough that we have enabled it for all Firefox Nightly users, starting with the Nightly build on November 15th (id: 20221115095444 or newer). Unless you’ve changed Firefox’s update settings, it will attempt to automatically update twice per day, but you can perhaps speed that up by manually checking for updates. To do that, navigate to the Firefox menu, then to Help, and then to About Nightly. Alternatively, open the Help menu from the Windows menu bar and choose About Nightly. That will do an update check; if an update is available Firefox will download it. After a restart to finish the update, Firefox will be using the new accessibility engine.

We’ve enabled this in Nightly so that we can gather more feedback, both from AT users, as well as from non-AT users or users who may not know Firefox’s accessibility engine has been activated due to an OS feature or third party application. We believe that the experience for most Nightly screen reader users will be a significant improvement over the old engine, as many of you have told us after opting in to the Nightly preview. As well as direct feedback we receive, enabling it by default in Nightly will allow us to gather automatic feedback via crash reports. We will also be receiving feedback from a larger group of users with more diverse use cases which will help us move closer to a beta release and an eventual release to the full Firefox audience.

If you experience slow-downs, more frequent crashes, or missing capabilities that prevent you from using Firefox Nightly as you normally would, you can revert to the old accessibility engine by going to Firefox Settings, entering accessibility cache into the search box, tabbing to the Accessibility cache check box and turning it off. After a restart, you’ll be back on the old engine. If this does become necessary or you have any other feedback to offer, please file a Bugzilla report or stop in at our Matrix chat and let us know.

The post Significant Improvements for Screen Readers Now in Nightly Firefox appeared first on Mozilla Accessibility.

Categorieën: Mozilla-nl planet

Mozilla Thunderbird: Important Message For Microsoft Office 365 Enterprise Users

do, 10/11/2022 - 14:05

Welcome to Thunderbird 102

In a coming release of the Thunderbird 102.x series, we will be making some changes to the way we handle OAuth2 authorization with Microsoft accounts, and this may involve some extra work for users currently using Microsoft-hosted accounts through their employer or educational institution.

In order to meet Microsoft’s requirements for publisher verification, it is necessary for us to switch to a new Azure application and application ID. However, some of these accounts are configured to require administrators to approve any applications accessing email.

We have already made the necessary changes in the current Thunderbird beta series.

If you are using a hosted Microsoft account, please temporarily launch Thunderbird 107.0b3 or later (download here) and attempt to log in, making sure to select “OAuth2” as your authentication method.

If you encounter a screen saying “Need admin approval” during the login process, please contact your IT administrators to approve the client ID 9e5f94bc-e8a4-4e73-b8be-63364c29d753 for Mozilla Thunderbird (it may appear to admins as “Mzla Technologies Corporation”).

We request the following permissions:

  • IMAP.AccessAsUser.All
  • POP.AccessAsUser.All
  • SMTP.Send
  • offline_access

After doing this, you may return to using the version you were using previously.

The post Important Message For Microsoft Office 365 Enterprise Users appeared first on The Thunderbird Blog.

Categorieën: Mozilla-nl planet

Andrew Sutherland: Andrew’s Searchfox Roadmap 2022

do, 10/11/2022 - 06:49

Searchfox (source, config source) is Mozilla’s primary code searching tool for Firefox introduced by Bill McCloskey in 2016 which built upon prior work on DXR. This roadmap post is the second of two posts attempting to lay out where my personal efforts to enhance searchfox are headed and the decision making framework that guides them. The first post was a more abstract product vision document and can be found here.

Discoverable, Extensible, Powerful Queries

Searchfox has a new “query” endpoint introduced in bug 1762817 which is intended to enable more powerful queries. Queries are parsed using :katsquery-parser crate which allows us to support our existing (secret) key:value syntax in a more rigorous way (and with automatic parse correction for the inevitable typos). In order to have a sane execution model, these key/value pairs are mapped through an extensible configuration file into a pipeline / graph execution model whose clap-based commands form the basis of our testing mechanism and can also be manually built and run from the command-line via searchfox-tool.

 "file-search", "semantic-search", and "text-search".  Those 3 pipelines feed into "compile-results" which then passes its output to the 2nd phase which contains the "display" job.  If you're interested in more details, see below for the "check output for the query" link which links the backing JSON which is the basis for the graph.

Above you will find a diagram rendering the execution pipeline of searching for foo manually created from the JSON insta crate check output for the query. Bug 1763005 will add automatically generated diagrams as well as further expanding on the existing capability to produce markdown explanations of what is happening in each stage of the pipeline and the values at each stage.

While a new query syntax isn’t exciting on its own, what is exciting is that this infrastructure makes it easier to add functionality with confidence (and tests!). Some particular details worth discussing:

Customizable, Shareable Queries

Bug 1799796: Do you really wish that you could issue a query like webidl:CacheStorage to search just our WebIDL files for “CacheStorage”? Does your team have terminology that’s specific to your team and it would be great to have special search terms/aliases but it would feel wrong to use up all the cool short prefixes for your team? The new query mechanism has plans for these situations!

The new searchfox query endpoint looks like /mozilla-central/query/default. You’ll note that default looks like something that implies there are non-default options. And indeed, the plan is to allow files like this example “preset” dom.toml file to layer additional “terms” and “aliases” onto the base query_core.toml file as well as any other presets you want to build off of. You will need to add your preset to the mozsearch-mozilla repository for the tree in question, but the upside is that any query links you share will work for other people as well!

Faceting in Search Results with Shareable URLs

Bug 1799802: The basic idea of faceted search/filtering is:

  • You start with a basic search query.
  • Your results come back, potentially quite a lot of them. Too many, even!
  • The faceting logic looks at the various attributes of the results and classifies or “facets” them. Does that sound too circular? We just throw things in bins. If a bin ends up having a lot of things in it and there’s some hierarchy to its contents, we recursively bin those contents.
  • The UI presents these facets (bins), giving you a high level overview of the shape of your results, and letting you limit your results to only include certain attribute values, or to exclude based on others.
  • The UI is able to react quickly because it already knows about the result set
 bugzilla product, bugzilla component, bug status, bug resolution, assignee, whiteboard flags, keywords, patch count, priority, target milestone, version, QA contact, OS, Votes.  Follow the related link below for a list of blog posts with more details on this.

The cool screenshot above is of a SIMILE Exhibit-based faceting UI I created for bugzilla a while back which may help provide a more immediate concept of how faceting works. See my exhibit blog tag for more in the space.

Here are some example facets that search can soon support:

  • Individual result paths: Categorize results by the path in which they happen. Do you not want to look at any results under devtools/? Push a button and filter out all those devtool results in an instant! Do you only care about layout/? Push a button and only see layout results!
  • Subsystem facets: moz.build files labels every file in mozilla-central so that it has an associated Bugzilla Component. As of Bug 1783761 searchfox now also derives a subsystem mapping from the bugzilla components, which really just means that if you have a component that looks like “Core :: Storage: IndexedDB”, searchfox transforms that first colon into a slash so we get “Core/Storage/IndexedDB”. This would let you restrict your results to “Core/Storage” without having to manually select every Storage bugzilla component or path by hand.
  • Symbol relationships: Did you search for a base class or virtual method which has a number of subclasses/overrides? Do you only care about some subset of the class hierarchy? Then restrict your results to whatever the portion of the set you care about.
  • Recency of changes: Do you only care about seeing results whose blame history indicates it happened recently? Can do! Or maybe you only want to see code that hasn’t been touched in a long time? Uh, that might work less well until we improve the blame situation in Bug 1517978, but it’s always nice to have something to dream about.
  • Code coverage: Only want to see results that runs a lot under our tests? Sure thing! Only want to see results that seem like we don’t have test coverage for? By looking at the result you’re now morally obligated to add test coverage!

Key to this enhancement is that the faceting state will be reflected in the URL (likely the hash) so that you can share it or navigate forward and back and the state will be the same. It’s all too common on the web for state like this to be local to the page, but key to my searchfox vision is that URLs are key. If you do a lot of faceting, the URL may become large an unwieldy, but continuing in the style of :arai‘s fantastic work on Bug 1769936 and follow-ups to make it easy to get usable markdown out of searchfox, we can help wrap your URL in markdown link syntax so that when you paste it somewhere markdown-aware, it looks nice.

Additional Query Constraints

A bunch of those facets mentioned above sound like things that it would be neat to query on, right? Maybe even put them in a preset that you can share with others? Yes, we would add explicit query constraints for those as well, as well as to provide a way to convert faceted query results into a specific query that does not need to be faceted in Bug 1799805.

A variety of other additional queries become possible as well:

  • Searching for lines of text that are near each other, or not near each other, or maybe both inside the same argument list.
  • Locating member fields by type (Bug 1733217), like if you wanted to find all member fields that are smart or raw pointer references to nsILoadInfo.
  • Bug 1779340: Function/method argument list magic.
Result Context Lines For All Result Types, Including Automatic Context <figcaption>Current query results for C:4 AddOrPut</figcaption>

A major limitation for searchfox searches has been a lack of support for context lines. (Disclaimer: in Bug 1414954 I added secret support for fulltext-only queries by prefixing a search with context:4 or similar, but you would then want to force a fulltext query like context:4 text:my actual search or context:4 re:my.*regexp[y]?.*search.) The query mechanism already supports full context, as the above screenshot is taken from the query for C:4 AddOrPut but note that the UX needs more passes and the gathering mechanism currently needs optimization which I have a WIP for in Bug 1794177

Diagrams :loadInSameDocument' calls-between:'dispatchWindowEvent'` which is linked below.

The above is a live diagram I just generated with the query calls-between:'FrameLoader::loadInSameDocument' calls-between:'dispatchWindowEvent' against our searchfox index of webkit.

:Focus' calls-between:'WindowClient_Binding::focus' depth:10`

This next diagram is a live diagram from mozilla-central I just generated with the query calls-between:'ClientSource::Focus' calls-between:'WindowClient_Binding::focus' depth:10 and which demonstrates searchfox’s understanding of our IPDL bindings, as each of the SendP*/RecvP* pairs is capturing the IPC semantics that are only possible because of searchfox’s understanding of both C++ and IPDL.

The next steps in diagramming will happen in Bug 1773165 with a focus on making the graphs interactive and applying heuristics related to graph clustering based on work on the “fancy branch” prototype and my recent work to derive the sub-component mapping for files that can in turn be propagated to classes/methods so that we can automatically collapse edges that cross sub-component boundaries (but which can be interactively expanded). This has involved a bit of yak-shaving on Bug 1776522 and Bug 1783761 and others.

Note that we also support calls-to:'Identifier' in the query endpoint as well, but the graphs look a lot messier without the clustering heuristics, so I’m not including any in this post.

Most of my work on searchfox is motivated by my desire to use diagrams in system understanding, with much of the other work being necessary because to make useful diagrams, you need to have useful and deep models of the underlying data. I’ll try and write more about this in the future, but this is definitely a case where:

  1. A picture is worth a thousand words and iterations on the diagrams are more useful than the relevant prose.
  2. Providing screen-reader accessible versions of the underlying data is fundamental. I have not yet ported the tree-dual version of the diagram logic from the “fancy” branch and I think this is a precondition to an initial release that’s more than just a proof-of-sorta-works.
Documentation Integration

Our in-tree docs rendered at https://firefox-source-docs.mozilla.org/ are fantastic. Searchfox cannot replace human-authored documentation, but it can help you find them! Have you spent hours understanding code only to find that there was documentation that would help clarify what was going on only after the fact? Bug 1763532 will teach searchfox to index markdown so that documentation definitions and references show up in search and that we can potentially expose those in context menus. Subsequent steps could also index comment contents.

Bug 1458882 will teach searchfox how to link to the rendered documentation.

Improved Language Support New Language Support via SCIP

With the advent of LSIF and SCIP and in particular the work by the team at sourcegraph to add language indexing built on existing analysis tools, there is now a tremendous amount of low hanging fruit in terms of off-the-shelf language indexing that searchfox can potentially ingest. Thanks to Emilio‘s initial work in Bug 1761287 we know that it’s reasonably straightforward to ingest SCIP data from these indexers.

For each additional language we want to index, we expect the primary effort required will be to make the indexer available in a taskcluster task and appropriately configure it to index the potentially many component roots within the mozilla-central mono-repo. There will also be some searchfox-specific effort required to map the symbols into searchfox’s symbol namespace.

Specific languages we can support (better):

  • Javascript / Typescript via scip-typescript (Bug 1740290): scip-typescript potentially allows us to expose the same enhanced understanding of JS code, especially module-based JS code, that you experience in VS code, including type inference/extraction from JSDoc. Additionally, in Bug 1775130 we can leverage the amazing eslint work already done to bring enhanced analysis to more confusing situations like our mochitests which deal with more complex global situations. Overall, this can allow us to move away from searchfox’s current “soupy” understanding of JS code where it assumes that all the JS it ever sees is running in a single global.
  • Python via scip-python (Bug 1426456)
  • Java / Kotlin via scip-java (Bug 1490144)
Improved C++ Support

Searchfox’s strongest support is for C++ (and its interactions with XPIDL and IPDL), but there is still more to do here. Thankfully Botond is working to improve C++ template handling in Bug 1781178 and related bugs.

Other enhancements:

Improved Mozilla-Specific Language Support

mozilla-central contains a number of Mozilla-specific Interface Definition Languages (IDLs) and Domain Specific Languages (DSLs). Searchfox has existing support for:

  • XPIDL .idl files: Our C++ support here is pretty good because XPIDL files are not preprocessed (beyond in-language support of #include and the ability to put pass-through C++ code including preprocessor directives inside %{C++ and %}demarcated blocks. Bug 1761689 tracks adding support for constants/enums which is not currently supported, and I have WIPs for this. Bug 1800008 tracks adding awareness of the rust bindings.
  • IPDL .ipdl and .ipdlh files: Our C++ support here is good as long as the file is not pre-processed and the rust IPDL parser hasn’t fallen behind the Python parser. Unfortunately a lot of critical files like PContent.ipdl are pre-processed so this currently creates massive blind-spots in searchfox’s understanding of the system. Bug 1661067 will move us to having the Python parser/code generator emit data searchfox can ingest

Searchfox has planned support for:

Pernosco Integration A timeline visualization of data extracted from a pernosco session using pernosco-bridge.  The specific data is showing IndexedDB database transaction lifetimes happening under the chrome origin with specific calls to AddOrPutRequestOp and CommitOp occurring.<figcaption>pernosco-bridge IDB timeline visualization</figcaption>

Searchfox’s language indexing is inherently a form of static analysis. Consistent with the searchfox vision saying that “searchfox is not the only tool”, it makes sense to attempt to integrate with and build upon the tools that Firefox engineers are already using. Mozilla’s code-coverage data is already integrated with searchfox, and the next logical step is to integrate with pernosco, why not. I created pernosco-bridge as an experimental means of extracting data from pernosco and allowing for interactive visualizations.

The screenshot above is an example of a timeline graph automatically extracted from a config file to show data relevant to IndexedDB. IndexedDB transactions were hierarchically related to their corresponding database and the origin that opened those databases. Within each transaction, ObjectStoreAddOrPutRequestOp and CommitOp operations are graphed. Clicking on the timeline would direct the pernosco tab to jump to those instants in time.

A pernosco-bridge visualization of the sequence of events for DocumentLoadListener handling a redirect.<figcaption>pernosco-bridge DocumentChannel visualization</figcaption>

The above is a different visualization based on a config file for DocumentChannel to help group what’s going on in a pernosco trace and surface the relevant information. If you check out the config file, you will probably find it inscrutable, but with searchfox’s structured understanding of C++ classes landed last year in Bug 1641372 we can imagine leveraging searchfox’s understanding of the codebase to make this process friendly. More importantly, there is the potential to collaboratively build a shared knowledge base of what’s most relevant for classes, so everyone doesn’t need to re-do the same work.

Object graph expressing parent relationships amongst windowGlobalParent and canonicalBrowsingContext, with URI values extracted for the canonicalBrowsingContext.  More detail in the paragraph below.

Using the same information pernosco-bridge used to build the hierarchically organized timelines above with extracted values like URIs, it can also build graphs of the live objects at any moment in time in the trace. Above we can see the relationship between windowGlobalParent instances and their corresponding canonicalBrowsingContexts, plus the URIs of the canonicalBrowsingContexts. We can imagine using this to help visualize representative object graphs in searchfox.

Old screenshot of pecobro source listing with a function `checkIfInRange` with a sparkline showing activity in a trace that is interleaved with source code lines

We can also imagine doing something like the above screenshot from my prior experiment pecobro where we interleave graphs of function activity into source listings.

Token-Centric Blame / “hyperannotate” Support via Microannotate //clicky.visophyte.org/files/microannotate/nsWebBrowserPersist.cpp.html around the call to SaveURIInternal in nsWebBrowserPersist::SerializeNextFile that demonstrates blame tracking occurring on a per-token basis.<figcaption>A demonstration of microannotate’s output</figcaption>

Quoting my dev-platform post about the unfortunate removal of searchfox’s first attempt at blame-skipping: “Revision history and the “annotate” / “blame” UIs for revision control are tricky because they’re built on a sequential, line-centric data-model where moving a function above another function in a file results in a destructive representational decision to treat one function as continuing through history and the other function as removed and then re-added as new code. Reformatting that maintains the overall sequence of tokens but changes how they are distributed across multiple lines also looks like removal of all of the old code and the addition of new code. Tools frequently perform heuristic-based post-passes to help identify intra-line changes which are reflected in diff UIs, as well as (entire) lines of code that are copied/moved in a revision (ex: Phabricator does this).”

The plan to move forward is to move to a token-centric approach using :marco‘s microannotate project as tracked in Bug 1517978. We would also likely want to combine this with heuristics that skip over backout pairs. The screenshot at the top of this section is of example output for nsWebBrowserPersist.cpp where colors distinguish between different blame revision origins. Note that the addition of specific arguments can be seen as well as changes to comments.

Source Listings
  • Bug 1781179: Improved syntax and semantic highlighting in C++ for the tip/head indexed revision.
  • Bug 1583635: Show expansion of C++ macros. Do you ever look at our XPCOM macrology and wish you weren’t about to spend several minutes clicking through those macros to understand what’s happening? This bug, my friend, this bug.
  • Bug 1796870: Adopt use of tree-sitter as a tokenizer which can improve syntax highlighting for other languages as well as position: sticky context for both the tip/head indexed revision but also for historical revisions!
  • Bug 1799557: Improved handling of links to source files that no longer exist by offering to show the last version of the file that existed or try and direct the user to the successor code.
  • Bug 1697671: Link resource:// and chrome:// URLs in source listings to the underlying source files
  • Test Info Boxes
    • Bug 1785129: Add an info box mechanism to indicate the need for data collection review (“data review”) in info boxes on searchfox source listing pages
    • Bug 1797855: Joel Maher and friends have been adding all kinds of great test metadata for searchfox to expose, and soon, this bug shall expose that information. Unfortunately there’s some yak shaving related to logging that remains underway.
  • Bug 1797857: Extend the “Go to header file”/”Go to source file” mechanism to support WPT `.headers` files and xpcshell/mochitest `^headers^` files.
Alternate Views of Data :dom::FragmentOrElement, and mozilla::dom::Element across the 4 supported platforms (win64, macosx64, linux64, and android-armv7), showing field offsets and sizes.

Searchfox is able to provide more than source listings. The above screenshot shows searchfox’s understanding of the field layouts of C++ classes across all the platforms searchfox indexes on as rendered by the “fancy” branch prototype. Bug 1468445 tracks implementing a production quality version of this, noting that the data is already available, so this is straightforward. Bug 1799517 is a variation on this which would help us explicitly capture the destructor order of C++ fields.

Bug 1672307 tracks showing the binary size impact of a given file, class, etc.

Source Directory Listings

In the recently landed Bug 1783761 I moved our directory listings into rust after shaving a whole bunch of yaks. Now we can do a bunch of queries on data about files. Would you like to see all the tests that are disabled in your components? We could do this! Would you like to see all the files in your components that have been modified in the last month but have bad coverage? We could also do that! There are many possibilities here but I haven’t filed bugs for them.

Mozilla Development Workflow Improvements
  • Bug 1732585: Provide a way to search related (phabricator revision) review/bugzilla comments related to the current file
  • Bug 1657786: Create searchfox taskcluster mode/variant that can run the C++ indexer only against changed files for try builds / phabricator requests
  • Bug 1778802: Consider storing m-c analysis data in a git repo artifact with a bounded history via `git checkout –orphan` to enable try branch/code review features and recent semantic history support
Easier Contributions

The largest hurdle new contributors have faced is standing up a virtual machine. In Bug 1612525 we’ve added core support for docker, and we have additional work to do in that bug to document using docker and add additional support for using docker under WSL2 on Windows. Please feel free to drop by https://chat.mozilla.org/#/room/#searchfox:mozilla.org if you need help getting started.

Deeper Integration with Mozilla Infrastructure

Currently much of searchfox runs as EC2 jobs that exists outside of taskcluster, although C++ and rust indexing artifacts as well as all coverage data and test info data comes from taskcluster. Bug 1598502 tracks moving more of searchfox into taskcluster, although presumably the web-servers will still need to exist outside of taskcluster.

Categorieën: Mozilla-nl planet

Frederik Braun: Neue Methoden für Cross-Origin Isolation: Resource, Opener & Embedding Policies mit COOP, COEP, CORP und CORB

do, 10/11/2022 - 00:00

This document sat in my archives. I originally created this so I have notes for my participation in the Working Draft podcast - a German podcast for web developers. That's why this article is in German as well. The podcast episode 452 was published in 2020, but I never published this …

Categorieën: Mozilla-nl planet

Mozilla Thunderbird: Thunderbird Supernova Preview: The New Calendar Design

wo, 09/11/2022 - 10:15

 Monthly View

Auf Deutsch übersetzen Traducir al español Traduire en français Traduci in italiano 日本語に翻訳 Przetłumacz na polski Översätt till svenska

In 2023, Thunderbird will reinvent itself with the “Supernova” release, featuring a modernized interface and brand new features like Firefox Sync. One of the major improvements you can look forward to is an overhaul to our calendar UI (user interface). Today we’re excited to give you a preview of what it looks like!

Since this is a work-in-progress, bear with us for a few disclaimers. The most important one is that these screenshots are mock-ups which guide the direction of the new calendar interface. Here are a few other things to consider:

  • We’ve intentionally made this calendar pretty busy to demonstrate how the cleaner UI makes the calendar more visually digestible, even when dealing with many events.
  • Dialogs, popups, tool-tips, and all the companion calendar elements are also being redesigned.
  • Many of the visual changes will be user-customizable.
  • Any inconsistent font sizes you see are only present in the mock-up.
  • Right now we’re showing Light Mode. Dark and High Contrast mode will both be designed and shared in the near future.
  • These current mock-ups were done with the “Relaxed” Density setting in mind, but of course a tighter interface with scalable font-size will be possible.
Thunderbird Supernova Calendar: Monthly, Weekly, Daily Views  Monthly View<figcaption>Thunderbird Supernova Calendar: Monthly View</figcaption>

The first thing you may notice is that Saturday and Sunday are only partially visible. You can choose to visually collapse the weekends to save space.

But wait, we don’t all work Monday through Friday! That’s why you’ll be able to define what your weekend is, and collapse those days instead.

And do you see that empty toolbar at the top? Don’t worry, all the calendar actions will be reachable in context, and the toolbar will be customizable. Flexibility and customization is what you’ve come to expect from Thunderbird, and we’ll continue to provide that.

Thunderbird Supernova 115 Calendar Weekly View<figcaption>Thunderbird Supernova Calendar: Weekly View</figcaption>

Speaking of customization, visual customization options for the calendar will be available via a menu popup. Some (but not all) of the options you’ll see here are:

  • Hide calendar color
  • Hide calendar icons
  • Swap calendar color with category color
  • Collapse weekends
  • Completely remove your weekend days
Thunderbird Supernova 115 Calendar Daily View<figcaption>Thunderbird Supernova Calendar: Daily View</figcaption>

You’ll also see some new hotkey hints in the Search boxes (top middle, top right).

Speaking of Search, we’re moving the “Find Events” area into the side pane. A drop-down will allow choosing which information (such as title, location, and date) you want each event to show.

Thunderbird Supernova Calendar: Event View  Event View<figcaption>Thunderbird Supernova Calendar: Event View</figcaption>

The Event view also gets a decidedly modernized look. The important details have a lot more breathing room, yet subheadings like Location, Organizer and Attendees are easier to spot at a glance. Plus, you’ll be able to easily sort and identify the list of attendees by their current RSVP status.

By default, getting to this event preview screen requires only 1 click. And it’s 2 clicks to open the edit view (which you can do either in a new tab or a separate floating window). Because you love customization, you can control the click behavior. Do you want to skip the event preview screen and open the edit screen with just 1 click? We’ll have an option for that in preferences.

Feedback? Questions?

Life gets busy, so we want our new calendar design to look and feel comfortable. It will help you more efficiently sift, sort, and digest all the crucial details of your day.

Do you have questions or feedback about the new calendar in Thunderbird Supernova? We have a public mailing list specifically for User Interface and User Experience in Thunderbird, and it’s very easy to join.

Just head over to this link on TopicBox and click the “Join The Conversation” button!

Need Help With Thunderbird? Here’s How To Get Support

The post Thunderbird Supernova Preview: The New Calendar Design appeared first on The Thunderbird Blog.

Categorieën: Mozilla-nl planet

Aki Sasaki: blue sky: a federation of automation platforms

di, 08/11/2022 - 19:24
Premise (Tl;dr)

A federated protocol for automation platforms could usher in a new era of collaboration between open-source projects, corporations, NGOs, and governments. This collaboration could happen, not at the latency of human handoffs, but at the speed of automation.

(I had decided to revive this idea in a blog post before the renewed interest in Mastodon, but the timing is good. I had also debated whether to post this on US election day, but it may be a welcome distraction?)

Background

Once upon a time, an excited computer lab assistant showed my class the world wide web. Left-aligned black text with blue, underlined hypertext on a grey background, interspersed with low-resolution GIFs. Sites, hosted on other people's computers across the country, transferred across analog phone lines at over a thousand baud. "This," he said. "This will change everything."

Some two decades later, I blogged about blue sky, next-gen Release Engineering infrastructure without knowing how we'd get there. Stars aligned, and many teams put in hard work. Today, most of our best ideas made it into taskcluster, the massively scalable, cloud-agnostic automation platform that runs Mozilla's CI and Release Pipelines.

Firefox CI in January 2019: 7,139,432 tasks; 259.0 compute years; 1,071,533 unique workers; 383,411 maximum concurrent tasks #Mozilla #ContinuousIntegration #Taskcluster

— Chris Cooper (@ccooper) February 6, 2019

The still-unimplemented idea that's stuck with me the longest is something I referred to as cross-cluster communication.

Simple cases

In the simplest case, what if you could spin up two Taskcluster instances, and one cluster's tasks could depend on the other cluster's tasks and artifacts? Task 2 on Cluster B could remain unscheduled until Task 1 on Cluster A finished. At that point, Task 2 could move to `pending`, then `running`, and use Task 1's artifacts as input.

We might have an upstream dependency that tends to break everything in our pipeline whenever a new release of that dependency ships. Our current solution might involve pinning this dependency and periodically bumping the pin, debugging and bisecting any bustage at that time. But what if we could fire a set of unit and integration tests, not just when the dependency ships a new release, but whenever their CI runs a build off of trunk? We could detect the breaking change much more easily and quickly. Cross-cluster communication would allow for this cross-cluster dependency while leaving the security, billing, and configuration decisions in the hands of the individual cluster owners.

Or we could split up the FirefoxCI cluster. The release pipeline could move to a locked-down cluster for enhanced security monitoring. In contrast, the CI pipeline could remain accessible for easier debugging. We wouldn't want to split the hardware test pools. We have a limited number of those machines. Instead, we could create a third cluster with the hardware test pools, triggering tests against builds generated by both upstream clusters.

Of course, we wouldn't need this layer if we only wanted to connect to one or two upstreams. This concept starts to shine when we scale up. Many-to-many.

Many-to-many

Open source projects could collaborate in ways we haven't yet seen. But this isn't limited to just open source.

If the US were using Taskcluster, municipal offices could collaborate, each owning their own cluster but federating with the others. The state could aggregate each and generate state-wide numbers and reports. The federal government could aggregate the states' data and federate with other nations. NGOs and corporations could also access public data. Traffic. Carbon. The disappearance and migration of wildlife. The spread of disease outbreaks.

A graph of cluster interdependencies. A matrix. A web, if you will. But instead of connecting machines or individuals, we're connecting automation platforms. Instead of cell-to-cell communication this is organ-to-organ communication.

(As I mentioned in the Tl;dr): A federated protocol for automation platforms could usher in a new era of collaboration between open-source projects, corporations, NGOs, and governments. This collaboration could happen, not at the latency of human handoffs, but at the speed of automation.



comment count unavailable comments
Categorieën: Mozilla-nl planet

Mozilla Performance Blog: Understanding Performance Impact

ma, 07/11/2022 - 13:39

A few years ago, a small group of engineers at Mozilla introduced a process to identify the tasks that would have the greatest impact on the performance of Firefox. They would gather each week to look over user submitted profiles, and discuss bugs reports. Each bug would then be assigned a category and a score to reflect its impact on performance. This would help teams to prioritise their work for performance, and proved crucial in delivering the significant speed improvements that were present in Firefox Quantum.

Fast forward to today, and this performance triage process has continued, but you’d be forgiven for not knowing about it. This year we have been making improvements to the way bugs are nominated for triage, how the impact and keywords are determined, and getting more people involved. I’d like to share some of these changes with you, starting with how to request a performance impact review for a bug.

How performance impact reviews are requested

If you believe a bug may have an impact on the performance of our products, you can nominate it for triage. You can do this by editing the bug and setting the “Performance Impact” flag to “?”.

Screenshot of Bugzilla showing the Performance Impact flag with the values expanded.

Performance Impact in Bugzilla

This will cause the bug to show up in the queries used by our triage sheriffs, who will attempt to determine the performance impact at the next meeting. If you have any additional details that may help, we encourage you to mention these as a comment in the bug. If you’re interested in joining the discussion, you can reach out to the lead of the next triage meeting published here.

How performance impact is determined

In the past we relied on the knowledge and experience of the triage sheriffs attending the meeting to determine the performance impact. Whilst efficient, this approach wasn’t great for onboarding new members to the triage rotation, and could also be inconsistent. We resolved this by building a tool to calculate the impact from a series of simple prompts.

Screenshot of the performance impact calculator

Performance Impact Calculator

Starting with a base impact score of zero, each answer in the calculator either increases the base impact score or applies a multiplier. For example:

  • Causes noticeable jank: +2
  • Severe page load impact: +10
  • Affects major websites: ×5
  • Reproduces in Chrome: ×0.3
  • Total impact score = (2+10)×5×0.3 = 18

For insight into how each of the options affects the score, you can check the “Debug” button to display a breakdown next to the labels.

Screenshot showing debug information next to some of the calculator options.

Calculator with debug enabled

If the score is greater than zero then the bug is considered to have an impact on performance. The scores relate to the impact flag values as follows:

  • 0: none
  • 0-40: medium
  • 40+: high

Note that the calculator is being adjusted regularly to ensure it gives an accurate reflection of the performance impact, therefore the values above may at some point be out of date. If you disagree with a performance impact result, please add a comment on the bug with your concerns and either needinfo the triage sheriff or re-nominate the bug for triage. Feel free to try the calculator out for yourself, and if you have any suggestions for improvements, please open an issue.

How performance impact affects you

It’s important to note that the performance team does not directly interfere with the priorities of bugs outside of their own components. During triage, bugs will be reassigned wherever possible to the most appropriate component, and it is the responsibility of the triage owners for those components to set a priority. The goal of the performance impact flag is to provide additional context that may assist the triage owners in their role. That said, a bug with a high performance impact on the product quality and experience could reasonably be expected to cause a Firefox user to switch browsers, and therefore should be considered S2 in severity.

How to get help

The performance triage wiki serves as a guide for running the triage, and goes into some detail on the Bugzilla fields and queries used. Please note that the impact calculator is constantly being tweaked, and your feedback is essential for helping us to improve the formula. If you notice a bug with a performance impact that doesn’t feel quite right, please let us know. You can do this by changing the “performance impact” flag to “?” and adding a comment, or by reaching out in #perf-help on Matrix or Slack.

Categorieën: Mozilla-nl planet

Mark Surman: Mozilla Ventures: Investing in Responsible Tech

zo, 06/11/2022 - 05:19

Early next year, we will launch Mozilla Ventures, a first-of-its-kind impact venture fund to invest in startups that push the internet — and the tech industry — in a better direction 

___

Many people complain about today’s tech industry. Some say the internet has lost its soul. And some even say it’s impossible to make it better. 

My response: we won’t know unless we try, together. 

Personally, I think it is possible to build successful companies — and great internet products — that put people before profits. Mozilla proves this. But so do WordPress, Hugging Face, ProtonMail, Kickstarter, and a good number of others. All are creating products and technology that respect users — and that are making the internet a healthier place.

I believe that, if we have A LOT more founders creating companies like these, we have a real chance to push the tech industry — and the internet — in a better direction. 

The thing is, the system is stacked against founders like this. It is really, really hard. This struck us when Mozilla briefly piloted a startup support program a couple of years ago. Hundreds of young founders and teams showed up with ideas for products and tech that were ‘very Mozilla’. Yet, we’ve also heard it’s hard to find mission aligned investors, or mentors and incubators who shared their vision for products that put people first.  

Through this pilot, Mozilla found the kinds of mentors these founders were looking for. And, we offered pre-seed investments to dozens of companies. But we also saw the huge need to do more, and to do it systematically over time. Mozilla Ventures will be our first step in filling this need. 

Launching officially in early 2023, Mozilla Ventures will start with an initial $35M, and grow through partnerships with other investors.

The fund will focus on early stage startups whose products are designed to delight users or empower developers — but with the sort of values outlined in the Mozilla Manifesto baked in from day one. Imagine a social network that feels like a truly safe place to connect with your closest family and friends. Or an AI tooling company that makes it easier for developers to detect and mitigate bias when developing digital products and services. Or a company offering a personal digital assistant that is both a joy to use and hyper focused on protecting your privacy. We know there are founders out there who want to build products and companies like these, and that want to do so in a way that looks and feels different than the tech industry of today. 

Processwise, Mozilla Ventures will look for founders with a compelling product vision and alignment with Mozilla’s values. From there, it will look at their team, their product and their business, just as other investors do. And, where all these things add up, we’ll invest. 

The fund will be led by Managing Partner Mohamed Nanabhay. Mohamed brings a decade of experience investing in digital media businesses designed to advance democracy and free speech where those things are hard to come by. Which perfectly sets him up for the job ahead — finding and funding founders who have the odds stacked against them, and then helping them succeed. 

Over the past few months, Mohamed and I have spent a good amount of time thinking about the basic thesis behind the fund (find great startups that align with the Mozilla Manifesto) — and testing this thesis out through conversations with founders. 

Even before we publicly announced Mozilla Ventures in November 2022, we’d already found three companies that validate our belief that companies like this are out there — Secure AI Labs, Block Party and HeyLogin. They are all companies driven by the idea that the digital world can be private, secure, respectful, and that there are businesses to be built creating this world. We’re honored that these companies saw the same alignment we did. They all opened up space on their cap table for Mozilla. And we invested.

Our first few months of conversations with founders (and other investors) have also underlined this: we have more questions than answers. Almost everyone we’ve talked to is excited by the idea of pushing the tech industry in a different direction, especially younger founders. On the flipside, everyone sees huge challenges — existing tech monopolies, venture funding growth at all costs, public cynicism. It’s important to be honest, we don’t have all the answers. We will (collectively) need to work through these challenges as we go. So, that’s what we will do. Our plan is to continue talking to founders — and making select investments — in the months leading up to the launch of the fund. We will also keep talking to fellow travelers like Lucid Capitalism, Startups and Society and Responsible Innovation Labs, who have already started asking some of the tough questions. And, we will continue speaking with a select group of potential co-investors (LPs) who share our values. We believe that, together, we have a chance of putting the tech industry on a truly different course in the years ahead.

The post Mozilla Ventures: Investing in Responsible Tech appeared first on Mark Surman.

Categorieën: Mozilla-nl planet

The Rust Programming Language Blog: Announcing Rust 1.65.0

do, 03/11/2022 - 01:00

The Rust team is happy to announce a new version of Rust, 1.65.0. Rust is a programming language empowering everyone to build reliable and efficient software.

Before going into the details of the new Rust release, we'd like to draw attention to the tragic death of Mahsa Amini and the death and violent suppression of many others, by the religious morality police of Iran. See https://en.wikipedia.org/wiki/Mahsa_Amini_protests for more details. We stand in solidarity with the people in Iran struggling for human rights.

If you have a previous version of Rust installed via rustup, you can get 1.65.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.65.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.65.0 stable Generic associated types (GATs)

Lifetime, type, and const generics can now be defined on associated types, like so:

trait Foo { type Bar<'x>; }

It's hard to put into few words just how useful these can be, so here are a few example traits, to get a sense of their power:

/// An `Iterator`-like trait that can borrow from `Self` trait LendingIterator { type Item<'a> where Self: 'a; fn next<'a>(&'a mut self) -> Option<Self::Item<'a>>; } /// Can be implemented over smart pointers, like `Rc` or `Arc`, /// in order to allow being generic over the pointer type trait PointerFamily { type Pointer<T>: Deref<Target = T>; fn new<T>(value: T) -> Self::Pointer<T>; } /// Allows borrowing an array of items. Useful for /// `NdArray`-like types that don't necessarily store /// data contiguously. trait BorrowArray<T> { type Array<'x, const N: usize> where Self: 'x; fn borrow_array<'a, const N: usize>(&'a self) -> Self::Array<'a, N>; }

As you can see, GATs are quite versatile and enable a number of patterns that are not currently able to be written. For more information, check out the post announcing the push for stabilization published last year or the stabilization announcement post published last week. The former goes into a bit more depth of a couple of the examples above, while the latter talks about some of the known limitations of this stabilization.

More in depth reading can be found in the associated types section of the nightly reference or the original RFC (which was initially opened over 6.5 years ago!).

let-else statements

This introduces a new type of let statement with a refutable pattern and a diverging else block that executes when that pattern doesn't match.

let PATTERN: TYPE = EXPRESSION else { DIVERGING_CODE; };

Normal let statements can only use irrefutable patterns, statically known to always match. That pattern is often just a single variable binding, but may also unpack compound types like structs, tuples, and arrays. However, that was not usable for conditional matches, like pulling out a variant of an enum -- until now! With let-else, a refutable pattern can match and bind variables in the surrounding scope like a normal let, or else diverge (e.g. break, return, panic!) when the pattern doesn't match.

fn get_count_item(s: &str) -> (u64, &str) { let mut it = s.split(' '); let (Some(count_str), Some(item)) = (it.next(), it.next()) else { panic!("Can't segment count item pair: '{s}'"); }; let Ok(count) = u64::from_str(count_str) else { panic!("Can't parse integer: '{count_str}'"); }; (count, item) } assert_eq!(get_count_item("3 chairs"), (3, "chairs"));

The scope of name bindings is the main thing that makes this different from match or if let-else expressions. You could previously approximate these patterns with an unfortunate bit of repetition and an outer let:

let (count_str, item) = match (it.next(), it.next()) { (Some(count_str), Some(item)) => (count_str, item), _ => panic!("Can't segment count item pair: '{s}'"), }; let count = if let Ok(count) = u64::from_str(count_str) { count } else { panic!("Can't parse integer: '{count_str}'"); }; break from labeled blocks

Plain block expressions can now be labeled as a break target, terminating that block early. This may sound a little like a goto statement, but it's not an arbitrary jump, only from within a block to its end. This was already possible with loop blocks, and you may have seen people write loops that always execute only once, just to get a labeled break.

Now there's a language feature specifically for that! Labeled break may also include an expression value, just as with loops, letting a multi-statement block have an early "return" value.

let result = 'block: { do_thing(); if condition_not_met() { break 'block 1; } do_next_thing(); if condition_not_met() { break 'block 2; } do_last_thing(); 3 }; Splitting Linux debuginfo

Back in Rust 1.51, the compiler team added support for split debug information on macOS, and now this option is stable for use on Linux as well.

  • -Csplit-debuginfo=unpacked will split debuginfo out into multiple .dwo DWARF object files.
  • -Csplit-debuginfo=packed will produce a single .dwp DWARF package alongside your output binary with all the debuginfo packaged together.
  • -Csplit-debuginfo=off is still the default behavior, which includes DWARF data in .debug_* ELF sections of the objects and final binary.

Split DWARF lets the linker avoid processing the debuginfo (because it isn't in the object files being linked anymore), which can speed up link times!

Other targets now also accept -Csplit-debuginfo as a stable option with their platform-specific default value, but specifying other values is still unstable.

Stabilized APIs

The following methods and trait implementations are now stabilized:

Of particular note, the Backtrace API allows capturing a stack backtrace at any time, using the same platform-specific implementation that usually serves panic backtraces. This may be useful for adding runtime context to error types, for example.

These APIs are now usable in const contexts:

Compatibility notes
  • As the final step of the RLS deprecation, this release has replaced RLS with a small LSP server showing a deprecation warning, advising users to migrate to rust-analyzer.
Other changes

There are other changes in the Rust 1.65 release, including:

  • MIR inlining is now enabled for optimized compilations. This provides a 3-10% improvement in compiletimes for real world crates.
  • When scheduling builds, Cargo now sorts the queue of pending jobs to improve performance.

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

Contributors to 1.65.0

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

Categorieën: Mozilla-nl planet

Support.Mozilla.Org: How to contribute to Mozilla through user support

wo, 02/11/2022 - 17:34

SUMO contributors posing in front of whistler inukshuk statue in Whistler

It is with great pleasure that I am announcing the launch of our new contribute page in SUMO a.k.a SUpport.Mozilla.Org. SUMO is one of the oldest contribution areas in Mozilla, and we want to show you just how easy it is to contribute!

There are many ways you can get involved with SUMO, so getting started can be confusing. However, our new contribute page should help with that, since the pages are now updated with simpler steps to follow and a refreshed design.

We also added two new contribution areas, so now we have five ways to contribute:

  1. Answer questions in the support forum
  2. Write help articles
  3. Localize help articles
  4. Provide support on social media channels (newly added)
  5. Respond to mobile store reviews (newly added)

The first 3 areas are nothing new for SUMO contributors. You can contribute by replying to forum posts, writing help articles (or Knowledge Base articles as we call them here), or translating the help article’s content to your respective locales.

Providing support on social media channels is also nothing new to SUMO. But with the ease of tools that we have now, we are able to invite more contributors to the program. In 2020, we started the @FirefoxSupport account on Twitter and as of now, we have posted 4115 tweets and gained 3336 followers. If you’re a social media enthusiast, the Social Support program is a perfect contribution area for you.

Responding to user reviews on the mobile store is something relatively new that we started a couple of years ago to support the Firefox for Android transition from Fennec to Fenix. We realize that the mobile ecosystem is a different territory with different behavior. We wanted to make sure that we serve people where they need us the most, which means providing support for those who leave us app reviews. If this sounds more like your thing, you should definitely join the Mobile Store Support program.

And if you still can’t decide, you can always start by saying hi to us in our Matrix room or contributor forums.

 

Keep on rocking the helpful web,

Kiki

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Begin your MV3 migration by implementing new features today

ma, 31/10/2022 - 22:59

Early next year, Firefox will release Mozilla’s Manifest V3 (MV3). Therefore, it’s an ideal time to consider migrating your Manifest V2 extensions. One of our goals throughout our approach to MV3 has been to gradually release new WebExtensions features that enable you to begin implementing APIs that are compatible with MV3. To this end, we recently released some exciting new features you should know about…

 

MV3 changes you can make to your extension right now

 

Event Pages

In Firefox MV3, we’re providing Event Pages as the background script. Event Pages retain several important features, including access to DOM and WebAPIs that are not available with the new service worker backgrounds used in Google Chrome.

We enabled Event Pages for MV2 (aka non-persistent background pages that can be closed and respawned based on browser events) in Firefox 106. This update is a major step toward MV3 because all extensions must adopt Event Pages in MV3. But you can make this change today and use new Event Pages benefits such as:

  • Resiliency against unexpected system crashes. Now we can restart a corrupted background page without hindering the user.
  • No need for an extension reboot to reset a background page.
  • Save on memory resources by putting idle background pages to sleep.
How do I implement Event Pages?

To turn your background into an Event Page, set `persistent: false` on the background page in your manifest.json. Here’s more info on background scripts with implementation details.

Now that your background script is non-persistent, you need to tell Firefox when to wake up the page if it’s suspended. There are two methods available:

  1. Use an event listener like `browser.tabs.onCreated` in your background script.  Event listeners must be added at the top level execution of your script. This way, if your background is sleeping Firefox knows to wake the script whenever a new tab is spawned. This works with nearly all events in the WebExtensions API. Here’s more info on adding listeners. (Note that Firefox recognizes arguments passed to addListener and does not create multiple listeners for the same set of arguments.)
  2. Use `browser.runtime.getBackgroundPage` if you need a background page to run processes unrelated to events. For instance, you may need a background script to run a process while the user is involved with a browser action or side panel. Use this API anytime you need direct access to a background page that may be suspended or closed. Here’s more info on background script functions.

Menus and Scripting APIs also support persistent data:

  • Menu items created by an event page are available after they’re registered — even if the event page is terminated. The event page respawns as necessary to menu events.
  • Registered scripts can be injected into matching web pages without the need for a running Event Page.
Scripting

You can take another big step toward MV3 by switching to the new Scripting API. This API consolidates several scripting related APIs — contentScripts.register(), tabs.insertCSS(), tabs.removeCSS(), and tabs.executeScript() — and adds capabilities to register, update, and unregister content scripts at runtime.

Also, arbitrary strings can no longer be executed because the code parameter has been removed. So you’ll need to move any arbitrary strings executed as scripts into files contained within the extension, or to the func property used with, if necessary, the args parameter.

This API requires the scripting permission.

Preparing for MV3 restrictions

MV3 will impose enhanced restrictions on several features. Most of these restrictions are outlined in the MV3 migration guide. By following the steps detailed in the guide, there are some ways you can begin modifying your MV2 extension to make it comply more closely with MV3 requirements. A few noteworthy areas include…

Conform to MV3’s Content Security Policy

Mozilla’s long-standing add-on policies prohibit remote code execution. In keeping with these policies, the content_security_policy field no longer supports sources permitting remote code in script-related directives, such as script-src or `’unsafe-eval’`. The only permitted values for the `script-src` directive is `’self’` and `’wasm-unsafe-eval’`. `’wasm-unsafe-eval’` must be specified in the CSP if an extension wants to use WebAssembly. In MV3, content scripts are subject to the same CSP as other parts of the extension.

Historically, a custom extension CSP required object-src to be specified. This is not required in MV3 and was removed from MV2 in Firefox 106 (see object-src in content_security_policy on MDN). This change makes it easier for extensions to customize the CSP with minimal boilerplate.

The Content Security Policy (CSP) is more restrictive in MV3. If you are using a custom CSP in your MV2 add-on, you can validate the CSP by temporarily running it as an MV3 extension.  See the MV3 migration guide for details.

Upgrade insecure requests – https by default

When communicating with external servers, extensions will use https by default. Extensions should replace the “http:” and ”ws:” schemes in their source code with secure alternatives, “https:” and ”wss:”. The default MV3 CSP includes the upgrade-secure-requests directive, to enforce the use of secure schemes even if an insecure scheme was used.

Extensions can opt out of this https requirement by overriding the content_security_policy and omitting the upgrade-secure-requests, provided that no user data is transmitted insecurely through the extension.

Opt-in permissions

All MV3 permissions, including host permissions, are opt-in for users. This necessitated a significant Firefox design change — the introduction of the extensions button — so users can easily grant or deny website specific permissions at any time (the button is enabled on Firefox Nightly for early testing and feedback).

The extensions button gives Firefox users direct control over website specific extension permissions.

Therefore, you must ensure your extension has permission whenever it accesses APIs covered by a permission, accesses a tab, or uses Fetch API. MV2 already has APIs that enables you to check for permissions and watch for changes in permission. When necessary, you can get the current permission status. However, rather than always checking, use the permissions.onAdded and permissions.onRemoved event APIs to watch for changes.

Update content scripts

While content scripts continue to have access to the same extension APIs in MV3 as in MV2, most of the special exceptions and extension specific capabilities have been removed from the web platform APIs (DOM APIs). In particular, the extension’s host permissions no longer apply to Fetch and XMLHttpRequest.

CSP for content scripts

With MV2 no CSP is applied to content scripts. In MV3, content scripts are subjected to the same CSP as other parts of the extension (see CSP for content scripts on MDN). Notably, this means that remote code cannot be executed from the content script. Some existing uses can be replaced with functionality from the Scripting API such as func and args (see the “Scripting” section above), which is available to MV2 extensions.

XHR and Fetch

With MV2 you also have access to some APIs, such as XMLHttpRequest and Fetch, from both extension and web page contexts. This allows for cross origin requests in a way that is not available in MV3. In MV3, XHR and Fetch operate as if the web page itself was using them, and are subject to cross origin controls.

Content scripts can continue using XHR and Fetch by first making requests to background scripts. A background script can then use Fetch to get the data and return the necessary information to the content script. To avoid privacy issues, set the “credentials” option to “omit” and cache option to “no-cache”. In the future, we may offer an API to support the make-request-on-behalf-of-a-document-in-a-tab use case.

Will Chrome MV3 extensions work in Firefox MV2?

The release of MV3 in Firefox is distinct from Chrome. Add-ons intended to work across different browsers will, in most cases, require some level of adjustment to be compatible in both Firefox and Chrome. That said, we are committed to a high level of compatibility. We will be providing additional APIs and features in the near future. If you’ve converted your Chrome extension to Google’s MV3, you may be able to consolidate some of those changes into your Firefox MV2 extension. Here are a few areas to investigate:

  • Service Workers are not yet available in Firefox; however many scripts may work interchangeably between Service Workers and Event Pages, depending on functionality. To get things working, you may need to remove service worker specific APIs. See Service Worker Global Scope for more information.
  • DNR is not yet available in Firefox. Firefox retains WebRequest blocking in MV3, which can be used in place of DNR. When DNR is available, simple request modifications can be moved over to DNR.
  • The storage.session API is not yet available in Firefox. You can use other storage mechanisms in the meantime.

Hopefully, we’ve provided helpful information so you can use the new MV2 features to start your migration to MV3. As always, we appreciate your feedback and welcome questions. Here are the ways to get in touch:

The post Begin your MV3 migration by implementing new features today appeared first on Mozilla Add-ons Community Blog.

Categorieën: Mozilla-nl planet

Andrew Halberstadt: How to Work on Taskcluster Github

ma, 31/10/2022 - 21:45

Taskcluster Github is the Taskcluster service responsible for kick starting tasks on Github repositories. At a high level:

  1. You install a Taskcluster app from the Github marketplace.
  2. This app sends webhooks to the Github service.
  3. Upon receiving a webhook, the Github service processes your repository’s .taskcluster.yml file.
  4. The Github service schedules tasks (if any) and updates the Github checks suite, or comments on your push / pull-request if there is an error.

While the service itself is relatively simple, testing it locally can be a pain! One approach might be to try and synthesize Github’s webhook events, and then intercept the network requests that the Github service makes in response. But this is tricky to do, and without actually seeing the results in a proper Github repo, it’s hard to be sure that your changes are working as intended.

Ideally you would have a real repo, with a development version of the app listed in the Github Marketplace, hooked up to a Taskcluster Github service running on your local machine. This way you could trigger webhooks by performing real actions in your repo (such as opening a pull-request). Better yet, you could see exactly how your Github service changes react!

Thanks to a lot of great work from Yarik, this is easier than ever and is all documented (or linked to) from this page. If you are already familiar with Taskcluster development, or enjoy figuring things out yourself, you may wish to skip this post and read the docs instead. But if you are a Taskcluster newbie, and would appreciate some hand holding, follow along for a step by step tutorial on how to work on and test Taskcluster Github!

Categorieën: Mozilla-nl planet

Pagina's