Mozilla Firefox

When we launched our Environmental Sustainability Programme in March 2020, we identified three strategic goals: Reduce and mitigate Mozilla’s organisational impact; Train and develop Mozilla staff to build with sustainability in mind; Raise ... [More] awareness for sustainability, internally and externally. Today, we are releasing our baseline Greenhouse Gas emissions (GHG) assessment for 2019, which forms the basis upon which we will build to reduce and mitigate Mozilla’s organisational impact.   GHG Inventory: Summary of Findings Mozilla’s overall emissions in 2019 amounted to: 799,696 mtCO2e (metric tons of carbon dioxide equivalent). Business Services and Operations: 14,222 mtCO2e Purchased goods and services: 8,654 mtCO2e Business travel: 2,657 mtCO2e Events: 1,199 mtCO2e Offices and co-locations: 1,195 mtCO2e Remotees: 194 mtCO2e Commute: 147 mtCO2e Product use: 785,474 mtCO2e   How to read these emissions There are two major buckets: Mozilla’s impact in terms of business services and operations, which we calculated with as much primary data as possible; The impact of the use of our products, which makes up roughly 98% of our overall emissions. In 2019, the use of products spanned Firefox Desktop and Mobile, Pocket, and Hubs. Their impact is significant, and it is an approximation. We can’t yet really measure the energy required to run and use our products specifically. Instead, we are estimating how much power is required to use the devices needed to access our products for the time that we know people spent on our products. In other words, we estimate the impact of desktop computers, laptops, tablets, or phones while being online overall. For now, this helps us get a sense of the impact the internet is having on the environment. Going forward, we need to figure out how to reduce that share while continuing to grow and make the web open and accessible to all. The emissions related to our business services and operations cover all other categories from the GHG protocol that are applicable to Mozilla. For 2019, this includes 10 offices and 6 co-locations, purchased goods and services, events that we either host or run, all of our commercial travel including air, rail, ground transportation, and hotels, as well as estimates of the impact of our remote workforce and the commute of our office employees, which we gathered through an internal survey.   How we look at this data It’s easy to lose sight of all the work we’ve got to do to reduce our business services and operations emissions, if we only look at the overarching distribution of our emissions: If we zoom in on our business services and operations emissions, we’ll note that our average emissions per employee are: 12 mtCO2e. There is no doubt plenty of room for improvement. Our biggest area for improvement will likely be the Purchased Goods and Services category. Think: more local and sustainable sourcing, switching to vendors with ambitious climate targets and implementation plans, prolonging renewal cycles, and more.  In addition, we need to significantly increase the amount of renewable energy we procure for Mozilla spaces, which in 2019 was at: 27%. And while a majority of Mozillians already opt for a low-carbon commute, we’ll explore additional incentives here, too: We will also look at our travel and event policies to determine where we add the most value, which trip is really necessary, how we can improve virtual participation, and where we have space for more local engagement. You can find the longform, technical report in PDF format here. We’ll be sharing more about what we learned from our first GHG assessment, how we’re planning to improve and mitigate our impact soon. Until then, please reach out to the team should you have any questions at [email protected]. The post Release: Mozilla’s Greenhouse Gas emissions baseline appeared first on The Mozilla Blog. [Less]

When we launched our Environmental Sustainability Programme in March 2020, we identified three strategic goals: Reduce and mitigate Mozilla’s organisational impact; Train and develop Mozilla staff to build with sustainability in mind; Raise ... [More] awareness for sustainability, internally and externally. Today, we are releasing our baseline Greenhouse Gas emissions (GHG) assessment for 2019, which forms the basis upon which we will build to reduce and mitigate Mozilla’s organisational impact.   GHG Inventory: Summary of Findings Mozilla’s overall emissions in 2019 amounted to: 799,696 mtCO2e (metric tons of carbon dioxide equivalent). Business Services and Operations: 14,222 mtCO2e Purchased goods and services: 8,654 mtCO2e Business travel: 2,657 mtCO2e Events: 1,199 mtCO2e Offices and co-locations: 1,195 mtCO2e Remotees: 194 mtCO2e Commute: 147 mtCO2e Product use: 785,474 mtCO2e   How to read these emissions There are two major buckets: Mozilla’s impact in terms of business services and operations, which we calculated with as much primary data as possible; The impact of the use of our products, which makes up roughly 98% of our overall emissions. In 2019, the use of products spanned Firefox Desktop and Mobile, Pocket, and Hubs. Their impact is significant, and it is an approximation. We can’t yet really measure the energy required to run and use our products specifically. Instead, we are estimating how much power is required to use the devices needed to access our products for the time that we know people spent on our products. In other words, we estimate the impact of desktop computers, laptops, tablets, or phones while being online overall. For now, this helps us get a sense of the impact the internet is having on the environment. Going forward, we need to figure out how to reduce that share while continuing to grow and make the web open and accessible to all. The emissions related to our business services and operations cover all other categories from the GHG protocol that are applicable to Mozilla. For 2019, this includes 10 offices and 6 co-locations, purchased goods and services, events that we either host or run, all of our commercial travel including air, rail, ground transportation, and hotels, as well as estimates of the impact of our remote workforce and the commute of our office employees, which we gathered through an internal survey.   How we look at this data It’s easy to lose sight of all the work we’ve got to do to reduce our business services and operations emissions, if we only look at the overarching distribution of our emissions: If we zoom in on our business services and operations emissions, we’ll note that our average emissions per employee are: 12 mtCO2e. There is no doubt plenty of room for improvement. Our biggest area for improvement will likely be the Purchased Goods and Services category. Think: more local and sustainable sourcing, switching to vendors with ambitious climate targets and implementation plans, prolonging renewal cycles, and more.  In addition, we need to significantly increase the amount of renewable energy we procure for Mozilla spaces, which in 2019 was at: 27%. And while a majority of Mozillians already opt for a low-carbon commute, we’ll explore additional incentives here, too: We will also look at our travel and event policies to determine where we add the most value, which trip is really necessary, how we can improve virtual participation, and where we have space for more local engagement. You can find the longform, technical report in PDF format here.. We’ll be sharing more about what we learned from our first GHG assessment, how we’re planning to improve and mitigate our impact soon. Until then, please reach out to the team should you have any questions at [email protected]. The post Release: Mozilla’s Greenhouse Gas emissions baseline appeared first on The Mozilla Blog. [Less]

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust ... [More] or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR. Updates from Rust Community Official Announcing Rust 1.48.0 [Inside] Source-based code coverage in nightly Newsletters Tooling IntelliJ Rust Changelog #135 Rust-Analyzer Changelog #51 Knurling-rs Changelog #6 Observations/Thoughts ECS Scheduler Throughs, Part 1 Generating a config file reference for CLI tools in Rust Rust in 2021 Anonymous Sum Types for Rust Error Handling The C Standard Library Is Not Dependency Free Scoped Trait Implementation Rust Walkthroughs SQLite File Parser Pt. 2: The Header... continues Rust from a Gopher - Lessons 7, 8 & 9 Writing an embedded display driver in Rust Rocket Tutorial 03: Proper routing Intro to Yew, a Rust Frontend Framework An Ownership Puzzle with Rust, Async, and Hyper Make A Language - Part Ten: Starting Again Make A Language - Part Eleven: Refinements OS in Rust: Custom target to build kernel for a bare metal: Part-3 Creating a Tetris Clone in Rust, with Bevy (Part 1) [PL] CrabbyBird #3 Generowanie świata gry – cześć I [video] Crust of Rust: Sorting Algorithms [video] (Live Coding) Audio adventures in Rust: UI with Actix, WebView, and React Project Updates The Big Picture of gfx/wgpu ecosystem xd(1): hex-dumping tool with a ♥♪ code page 437 twist ♫♥ Fwumious Wabbit: really fast logistic regression (+more) in Rust Rust for Modding Smash Ultimate reacty_yew: Generating Yew components from React components via Typescript type definitions Servo's New Home Miscellaneous Dog Fight — Python VS Golang VS Rust for JSON Processing Build an SMS Alert System over the weekend with Rust and Zero-Cost Build a Scalable Trading Bot With Rust Over the Weekend Oh No! My Data Science Is Getting Rust-y The Usability of Ownership Crate of the Week This week's crate is lingua, a ngrams-based natural language detector. Thanks to Willi Kappler for the suggestion! Submit your suggestions and votes for next week! Call for Participation Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. gfx-rs/naga - DirectX IR If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 299 pull requests were merged in the last week enable LLVM Polly via llvm-args implement destructuring assignment for structs and slices make _ an expression, to discard values in destructuring assignments add asm register information for SPIR-V add #[cfg(panic = '...')] resolve: collapse macro_rules scope chains on the fly never inline C variadics, cold functions, functions with incompatible attributes normalize function type during validation eliminate some temporary vectors do not collect tokens for doc comments chalk: variance lower intrinsics calls: forget, size_of, unreachable, wrapping_* move likely/unlikely argument outside of invisible unsafe block specialize io::copy to use copy_file_range, splice or sendfile improve BinaryHeap performance BTreeMap: fix pointer provenance rules in underfullness implement BTreeMap::retain and BTreeSet::retain cargo: improve performance of almost fresh builds rustfmt: option to create groups for std, external crates, and other imports Rust Compiler Performance Triage 2020-11-10: 1 Regression, 2 Improvements, 2 mixed A mixed week with improvements still outweighing regressions. Perhaps the biggest highlight was the move to compiling rustc crates with the initial-exec TLS model which results in fewer calls to _tls_get_addr and thus faster compile times. See the full report for more. Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. RFCs [disposition: merge] RFC: -C export-executable-symbols Tracking Issues & PRs [disposition: merge] Add PartialEq for proc_macro::Punct [disposition: merge] Implement PartialEq for proc_macro::Ident == strings [disposition: merge] Stabilize refcell_take [disposition: merge] Stabilize alloc::Layout const functions [disposition: merge] Impl Default for PhantomPinned [disposition: merge] stabilize const_int_pow [disposition: merge] Stabilize IpAddr::is_ipv4 and is_ipv6 as const [disposition: merge] Stabilize the backtrace feature. [disposition: merge] Tracking issue for methods converting bool to Option New RFCs Allow specifying features of the implicit lib dependency Upcoming Events Online November 18, Vancouver, BC, CA - Rust Study/Hack/Hang-out night - Vancouver Rust November 24, Dallas, TX, US - Last Tuesday - Dallas Rust November 26, Edinburgh, UK - Rust in the Polymesh Project - Rust Edinburgh November 26, Berlin, DE - Rust Hack and Learn - Berline.rs November 26, Tel Aviv-Yafo, IL - Rust Machine Learning On-line Meetup - ODSC Tel Aviv Data Science December 1, Buffalo, NY, US - Buffalo Rust User Group - Buffalo Rust Meetup December 8, Saarbücken, Saarland, DE - Meetup: 6u16 (virtual) - Rust Saar If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Rust Jobs Software Engineer at ChainSafe Systems (Toronto, CA, Remote) Software Developer (Rust) at MeiliSearch (Paris, FR) Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week This time we have two quotes of the week: i just spent 8h finding a mutability bug and now i wanna be a catgirl – @castle_vanity on twitter reacting to a post depicting C++ programmers as muscle-laden bodybuilders and Rust programmers as catgirls Thanks to Maximilian Goisser for the suggestion. The code people write is first a question to the compiler, and later a story for people changing that code. – Esteban Kuber on /r/rust llogiq is mightily pleased with his suggestion. Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell, llogiq, and cdmistman. Discuss on r/rust [Less]

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust ... [More] or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR. Updates from Rust Community Official Announcing Rust 1.48.0 [Inside] Source-based code coverage in nightly Newsletters Tooling IntelliJ Rust Changelog #135 Rust-Analyzer Changelog #51 Knurling-rs Changelog #6 Observations/Thoughts ECS Scheduler Thoughts, Part 1 Generating a config file reference for CLI tools in Rust Rust in 2021 Anonymous Sum Types for Rust Error Handling The C Standard Library Is Not Dependency Free Scoped Trait Implementation Rust Walkthroughs SQLite File Parser Pt. 2: The Header... continues Rust from a Gopher - Lessons 7, 8 & 9 Writing an embedded display driver in Rust Rocket Tutorial 03: Proper routing Intro to Yew, a Rust Frontend Framework An Ownership Puzzle with Rust, Async, and Hyper Make A Language - Part Ten: Starting Again Make A Language - Part Eleven: Refinements OS in Rust: Custom target to build kernel for a bare metal: Part-3 Creating a Tetris Clone in Rust, with Bevy (Part 1) [PL] CrabbyBird #3 Generowanie świata gry – cześć I [video] Crust of Rust: Sorting Algorithms [video] (Live Coding) Audio adventures in Rust: UI with Actix, WebView, and React Project Updates The Big Picture of gfx/wgpu ecosystem xd(1): hex-dumping tool with a ♥♪ code page 437 twist ♫♥ Fwumious Wabbit: really fast logistic regression (+more) in Rust Rust for Modding Smash Ultimate reacty_yew: Generating Yew components from React components via Typescript type definitions Servo's New Home Miscellaneous Dog Fight — Python VS Golang VS Rust for JSON Processing Build an SMS Alert System over the weekend with Rust and Zero-Cost Build a Scalable Trading Bot With Rust Over the Weekend Oh No! My Data Science Is Getting Rust-y The Usability of Ownership Crate of the Week This week's crate is lingua, a ngrams-based natural language detector. Thanks to Willi Kappler for the suggestion! Submit your suggestions and votes for next week! Call for Participation Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. gfx-rs/naga - DirectX IR If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 299 pull requests were merged in the last week enable LLVM Polly via llvm-args implement destructuring assignment for structs and slices make _ an expression, to discard values in destructuring assignments add asm register information for SPIR-V add #[cfg(panic = '...')] resolve: collapse macro_rules scope chains on the fly never inline C variadics, cold functions, functions with incompatible attributes normalize function type during validation eliminate some temporary vectors do not collect tokens for doc comments chalk: variance lower intrinsics calls: forget, size_of, unreachable, wrapping_* move likely/unlikely argument outside of invisible unsafe block specialize io::copy to use copy_file_range, splice or sendfile improve BinaryHeap performance BTreeMap: fix pointer provenance rules in underfullness implement BTreeMap::retain and BTreeSet::retain cargo: improve performance of almost fresh builds rustfmt: option to create groups for std, external crates, and other imports Rust Compiler Performance Triage 2020-11-10: 1 Regression, 2 Improvements, 2 mixed A mixed week with improvements still outweighing regressions. Perhaps the biggest highlight was the move to compiling rustc crates with the initial-exec TLS model which results in fewer calls to _tls_get_addr and thus faster compile times. See the full report for more. Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. RFCs [disposition: merge] RFC: -C export-executable-symbols Tracking Issues & PRs [disposition: merge] Add PartialEq for proc_macro::Punct [disposition: merge] Implement PartialEq for proc_macro::Ident == strings [disposition: merge] Stabilize refcell_take [disposition: merge] Stabilize alloc::Layout const functions [disposition: merge] Impl Default for PhantomPinned [disposition: merge] stabilize const_int_pow [disposition: merge] Stabilize IpAddr::is_ipv4 and is_ipv6 as const [disposition: merge] Stabilize the backtrace feature. [disposition: merge] Tracking issue for methods converting bool to Option New RFCs Allow specifying features of the implicit lib dependency Upcoming Events Online November 18, Vancouver, BC, CA - Rust Study/Hack/Hang-out night - Vancouver Rust November 24, Dallas, TX, US - Last Tuesday - Dallas Rust November 26, Edinburgh, UK - Rust in the Polymesh Project - Rust Edinburgh November 26, Berlin, DE - Rust Hack and Learn - Berline.rs November 26, Tel Aviv-Yafo, IL - Rust Machine Learning On-line Meetup - ODSC Tel Aviv Data Science December 1, Buffalo, NY, US - Buffalo Rust User Group - Buffalo Rust Meetup December 8, Saarbücken, Saarland, DE - Meetup: 6u16 (virtual) - Rust Saar If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Rust Jobs Software Engineer at ChainSafe Systems (Toronto, CA, Remote) Software Developer (Rust) at MeiliSearch (Paris, FR) Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week This time we have two quotes of the week: i just spent 8h finding a mutability bug and now i wanna be a catgirl – @castle_vanity on twitter reacting to a post depicting C++ programmers as muscle-laden bodybuilders and Rust programmers as catgirls Thanks to Maximilian Goisser for the suggestion. The code people write is first a question to the compiler, and later a story for people changing that code. – Esteban Kuber on /r/rust llogiq is mightily pleased with his suggestion. Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell, llogiq, and cdmistman. Discuss on r/rust [Less]

Overview The Domain Name System (DNS) is often referred to as the “phonebook of the Internet.” It is responsible for translating human readable domain names–such as mozilla.org–into IP addresses, which are necessary for nearly all communication on ... [More] the Internet. At a high level, clients typically resolve a name by sending a query to a recursive resolver, which is responsible for answering queries on behalf of a client. The recursive resolver answers the query by traversing the DNS hierarchy, starting from a root server, a top-level domain server (e.g. for .com), and finally the authoritative server for the domain name. Once the recursive resolver receives the answer for the query, it caches the answer and sends it back to the client. Unfortunately, DNS was not originally designed with security in mind, leaving users vulnerable to attacks. For example, previous work has shown that recursive resolvers are susceptible to cache poisoning attacks, in which on-path attackers impersonate authoritative nameservers and send incorrect answers for queries to recursive resolvers. These incorrect answers then get cached at the recursive resolver, which may cause clients that later query the same domain names to visit malicious websites. This attack is successful because the DNS protocol typically does not provide any notion of correctness for DNS responses. When a recursive resolver receives an answer for a query, it assumes that the answer is correct. DNSSEC is able to prevent such attacks by enabling domain name owners to provide cryptographic signatures for their DNS records. It also establishes a chain of trust between servers in the DNS hierarchy, enabling clients to validate that they received the correct answer. Unfortunately, DNSSEC deployment has been comparatively slow: measurements show, as of November 2020, only about 1.8% of .com records are signed, and about 25% of clients worldwide use DNSSEC-validating recursive resolvers. Even worse, essentially no clients validate DNSSEC themselves, which means that they have to trust their recursive resolvers. One potential obstacle to client-side validation is network middleboxes. Measurements have shown that some middleboxes do not properly pass all DNS records. If a middlebox were to block the RRSIG records that carry DNSSEC signatures, clients would not be able to distinguish this from an attack, making DNSSEC deployment problematic. Unfortunately, these measurements were taken long ago and were not specifically targeted at DNSSEC. To get to the bottom of things, we decided to run an experiment. Measurement Description There are two main questions we want to answer: At what rate do network middleboxes between clients and recursive resolvers interfere with DNSSEC records (e.g., DNSKEY and RRSIG)? How does the rate of DNSSEC interference compare to interference with other relatively new record types (e.g., SMIMEA and HTTPSSVC)? At a high level, in collaboration with Cloudflare we will first serve the above record types from domain names that we control. We will then deploy an add-on experiment to Firefox Beta desktop clients which requests each record type for our domain names. Finally, we will check whether we got the expected responses (or any response at all). As always, users who have opted out of sending telemetry or participating in studies will not receive the add-on. To analyze the rate of network middlebox interference with DNSSEC records, we will send DNS responses to our telemetry system, rather than performing any analysis locally within the client’s browser. This will enable us to see the different ways that DNS responses are interfered with without relying on whatever analysis logic we bake into our experiment’s add-on. In order to protect user privacy, we will only send information for the domain names in the experiment that we control—not for any other domain names for which a client issues requests when browsing the web. Furthermore, we are not collecting UDP, TCP, or IP headers. We are only collecting the payload of the DNS response, for which we know the expected format. The data we are interested in should not include identifying information about a client, unless middleboxes inject such information when they interfere with DNS requests/responses. We are launching the experiment today to 1% of Firefox Beta desktop clients and expect to publish our initial results around the end of the year. The post Measuring Middlebox Interference with DNS Records appeared first on Mozilla Security Blog. [Less]

Introduction This week the Servo project took a significant next step in bringing community-led transformative innovations to the web by announcing it will be hosted by the Linux Foundation.  Mozilla is pleased to see Servo, which began as a research ... [More] effort in 2012, open new doors that can lead it to ever broader benefits for users and the web. Working together, the Servo project and Linux Foundation are a natural fit for nurturing continued growth of the Servo community, encouraging investment in development, and expanding availability and adoption. Historical Retrospective From the outset the Servo project was about pioneering new approaches to web browsing fundamentals leveraging the extraordinary advantages of the Rust programming language, itself a companion Mozilla research effort. Rethinking the architecture and implementation of core browser operations allowed Servo to demonstrate extraordinary benefits from parallelism and direct leverage of our increasingly sophisticated computer and mobile phone hardware. Those successes inspired the thinking behind Project Quantum, which in 2017 delivered compelling improvements in user responsiveness and performance for Firefox in large part by incorporating Servo’s parallelized styling engine (“Stylo”) along with other Rust-based components. More recently, Servo’s WebRender GPU-based rendering subsystem delivered new performance enhancements for Firefox, and Servo branched out to become an equally important component of Mozilla’s Firefox Reality virtual reality browser. What’s Next? All along the way, the Servo project has been an exemplary showcase for the benefits of open source based community contribution and leadership. Many other individuals and organizations contributed much of the implementation work that has found its way into Servo, Firefox, Firefox Reality, and indirectly the Rust programming language itself. Mozilla is excited at what the future holds for Servo. Organizing and managing an effort at the scale and reach of Servo is no small thing, and the Linux Foundation is an ideal home with all the operational expertise and practical capabilities to help the project fully realize its potential. The term “graduate” somehow feels appropriate for this transition, and Mozilla could not be prouder or more enthusiastic. For more information about the Servo project and to contribute, please visit servo.org.   The post Foundations for the Future appeared first on Mozilla Hacks - the Web developer blog. [Less]

With the release of Firefox 83, we are pleased to welcome all the developers who’ve contributed their first code change to Firefox in this release, 18 of whom are brand new volunteers! Please join us in thanking each of these diligent and ... [More] enthusiastic individuals, and take a look at their contributions: akshat.dixit71: 1669833 akshay1992kalbhor: 1659264 dhairyabahl5: 1669921 jasleenbhambra: 1669334 marcos: 1665252 Alaa Emad: 1444611 Andreu Botella: 1661075 Daniel: 217434, 1667675 Harnaman Kaur: 1588185 Joaquín Serna: 1669044 Jonatan Klemets: 1668249 Mohamed H: 1617396 Niklas Baumgardner: 1612648 Richa Sharma: 1665568 Solomon Chiu: 1667939 Tanner Drake: 513180, 1642878 Vincent Bernat: 1554850 waverune: 1669026 [Less]

Did November spawn a monster this year? In truth, November has given us a few snippets of good news, far from the least of which is the launch of Firefox 83! In this release we’ve got a few nice additions, including Conical CSS gradients, overflow ... [More] debugging in the Developer Tools, enabling of WebRender across more platforms, and more besides. This blog post provides merely a set of highlights; for all the details, check out the following: Firefox 83 for developers on MDN Firefox 83 end-user release notes DevTools In the HTML Pane, scrollable elements have a “scroll” badge next to them, which you can now toggle to highlight elements causing an overflow (expanding nodes as needed to make them visible): You will also see an “overflow” badge next to the node causing the overflow. And in addition to that, if you hover over the node(s) causing the overflow, the UI will show a “ghost” of the content so you can see how far it overflows. These new features are very useful for helping to debug problems related to overflow. Web platform additions Now let’s see what’s been added to Gecko in Firefox 83. Conic gradients We’ve had support for linear gradients and radial gradients in CSS images (e.g. in background-image) for a long time. Now in Firefox 83 we can finally add support for conic gradients to that list! You can create a really simple conic gradient using two colors: conic-gradient(red, orange); But there are many options available. A more complex syntax example could look like so: conic-gradient( from 45deg /* vary starting angle */ at 30% 40%, /* vary position of gradient center */ red, /* include multiple color stops */ orange, yellow, green, blue, indigo 80%, /* vary angle of individual color stops */ violet 90% ) And in the same manner as the other gradient types, you can create repeating conic gradients: repeating-conic-gradient(#ccc 20deg, #666 40deg) For more information and examples, check out our conic-gradient() reference page, and the Using CSS gradients guide. WebRender comes to more platforms We started work on our WebRender rendering architecture a number of years ago, with the aim of delivering the whole web at 60fps. This has already been enabled for Windows 10 users with suitable hardware, but today we bring the WebRender experience to Win7, Win8 and macOS 10.12 to 10.15 (not 10.16 beta as yet). It’s an exciting time for Firefox performance — try it now, and let us know what you think! Pinch to zoom on desktop Last but not least, we’d like to draw your attention to pinch to zoom on desktop — this has long been requested, and finally we are in a position to enable pinch to zoom support for: Windows laptop touchscreens Windows laptop touchpads macOS laptop touchpads The post Firefox 83 is upon us appeared first on Mozilla Hacks - the Web developer blog. [Less]

Today is the release date of Firefox 83. One of the new features in this release is support for pinch-zooming on desktop platforms, a feature whose development I was involved with and which I’ll describe briefly in this blog post. Pinch gestures ... [More] have long been the standard method of interaction to trigger zooming on mobile devices, and the mobile version of Firefox has supported them since (I believe) its inception. The desktop version of Firefox has also had a zoom feature for a long time, activated via Ctrl+Plus/Minus or Ctrl+mousewheel or a button in the UI, but importantly, this performs a different type of zooming than pinch gestures on mobile, as I’ll illustrate. The conventional method of zooming on desktop performs reflowing zoom, which looks like this: By contrast, pinch gestures on mobile perform non-reflowing zoom, which looks like this: While both methods of zooming increase the scale of text, images, and other content elements, reflowing zoom reflows the page such that the scaled-up content still fits into the same horizontal viewport width. This can cause text to be split up into lines differently, and more generally elements to change their position relative to each other. Non-reflowing zoom leaves the page layout alone and just scales the content, creating overflow in the horizontal direction that you need to scroll to bring into view. Non-reflowing zoom has some important advantages over reflowing zoom: Reflow is expensive, making non-reflowing zoom much faster and more responsive. Non-reflowing zoom is more predictable in the sense that the content at the pinch gesture’s “focus point” will remain stationary, so you can zoom in “on an element” more accurately. The non-reflowing behaviour can also be a downside: if it’s a paragraph of text you’re zooming in on, if you zoom to a point where the lines are wider than the screen, you have to scroll horizontally to read a whole line. Basically, reflowing and non-reflowing zoom lend themselves to different use cases. Reflowing zoom is useful if, say, you’re reading an article but the text is a bit small for comfort (though I’ll take the opportunity to plug Firefox’s Reader View as an even better option for this case). Non-reflowing zoom is useful if, say, you want to zoom in on an image or diagram to get a closer look at it. Firefox users have long asked for the ability to trigger non-reflowing zoom on desktop platforms, using pinch gestures on a touchscreen or touchpad, a feature that other browsers have introduced over time as well. Firefox 83 finally fulfils this request, for touchscreens on all platforms, and touchpads on Windows and Mac. (Linux touchpads are still a work in progress.) Reflowing zoom hasn’t gone away, it’s still activated using the same means as before (Ctrl+mousewheel etc.). I’d like to extend a big thank you to my colleagues Kartikaya Gupta, Timothy Nikkel, and Kris Taeleman, with whom I collaborated on this feature, among many others who lent a helping hand. Implementing this feature was trickier than it sounds. Without getting into too many details, some of the main sources of complexity were: Scrollbars, particularly given that on desktop platforms you can interact with them (i.e. click them / drag them). I think our implementation here ended up being more complete than Chrome’s, in that scrollbars remain fully interactive even when zoomed. Web pages that want to handle pinch gestures themselves and “do their own thing”, such as Google Maps. Careful coordination is required to determine whether the pinch gesture should be handled by the page, or by the browser. If you’re a Firefox user with a touchscreen or a touchpad, I encourage you to give the new zoom feature a try! If you’re not a Firefox user, I encourage you to try Firefox If you run into any issues, bug reports are appreciated. [Less]

On January 26, 2021, Firefox will end support for Adobe Flash, as announced back in 2017. Adobe and other browsers will also end support for Flash in January and we are working together to ensure a smooth transition for all. Firefox version 84 will ... [More] be the final version to support Flash. On January 26, 2021 when we release Firefox version 85, it will ship without Flash support, improving our performance and security. For our users on Nightly and Beta release channels, Flash support will end on November 17, 2020 and December 14, 2020 respectively. There will be no setting to re-enable Flash support. The Adobe Flash plugin will stop loading Flash content after January 12, 2021. See Adobe’s Flash Player End of Life information page for more details. The post Ending Firefox support for Flash appeared first on Future Releases. [Less]