Mozilla Firefox

In November, I wrote about my team’s work on experimental new web design tools. We also ran a survey to rank the challenges of web design and development. A big thank you to everyone who participated in our open design process! We received over 900 ... [More] responses in one month, and discovered major findings which continue to inform the Firefox DevTools’ 2019 roadmap. The Methods With guidance from Mozilla’s data scientists, I chose the MaxDiff method for the challenge-ranking portion of the survey. MaxDiff requires the survey taker to make trade-offs within subsets of the pool of options. This works well for ranking a large number of options, which would be too overwhelming for a regular card sort. It also produces a more accurate overall ranking by emphasizing relative differences in priority. In practice, this produced 10 survey pages that each showed a set of 4 random options from a pool of 23 total web design challenges. Participants had to choose the “least“ and “most” impactful options in each set. The ranking was then determined by scores computed using the following formula: # times rated best – # times rated worst ————————————————— # times item appeared The second portion of the survey focused on specific frustrations with browser developer tools. For this section we only offered 7 options, so we used a simple drag-and-drop card sort. The Takeaways The highest-ranked issues by far were related to CSS layout debugging—learning the root cause of mysteries like unwanted scrollbars and unexpected size and position. Accordingly, my highest priority right now is digging deeper into CSS debugging issues with further research and experiments. (You can help by taking my brief new CSS Debugging follow-up survey! More info below.) Unsurprisingly, cross-browser compatibility was also a top choice. We’re investigating ways to ease the pain of debugging browser differences, including auditing, hints, and a more robust responsive design tool. Mid-ranked issues included Flexbox, Grid, and Accessibility. We plan to continue improving our Accessibility Panel; however, for now we’ll step back a bit from our successfully launched Flexbox and Grid tools. Letting them breathe and collecting more real-world feedback will allow us to swing back with fresh new ideas later. Lowest-ranked issues included Lack of Visual/WYSIWYG Tools, Animations, WebGL, and SVG. The visual tools part was surprising—we’ve seen a lot of love for click-and-drag visual tools like the beautifully designed Visbug and Webflow. I suspect my old-school wording here—WYSIWYG (“what you see is what you get”)—brought to mind less-delightful experiences of the past. There are clearly ways to improve developers’ lives with modern tools in this space. As for the browser issues card sort, we hear you loud and clear on the issue of “Moving CSS changes back to my editor.” We’re currently in the process of adding export options to our Changes panel, and would love your input on our designs! DOM breakpoints are also in the plans for this year. You can view the full MaxDiff and card sort rankings in this report. Follow-up Survey: CSS Layout Debugging Now we need your help again! The main takeaway from the first survey was that developers and designers of every experience level want to better understand CSS issues like unexpected scrollbars and sizing. We’ve started researching and prototyping potential tool ideas for investigating specific types of CSS bugs, but we need your feedback to guide our work. Please take a moment with our quick single-page CSS Layout Debugging survey and help us rank the most time-consuming bugs. Your feedback will be immensely helpful in clarifying our plans in 2019 and beyond. Thank you! Victoria & the Firefox DevTools team The post Web Design Survey Findings and Next Steps appeared first on Mozilla Hacks - the Web developer blog. [Less]

TenFourFox Feature Parity Release 13 beta 1 is now available (downloads, hashes, release notes). I took a different tack on this release because I still don't have good solutions for the missing JavaScript features currently affecting Citibank ... [More] , Github and a few other sites, so I've chosen to push out some side projects I've been working on in order not to make this a wasted release. Those features are support for WebP images and support for AppleScript automation. WebP images are an up-and-coming format based on the WebM VP8 codec, another way Google will consume the Web from the inside out, but they do have image size advantages and Firefox now supports them in Firefox 65. Google has two demonstration WebP galleries you can use to view some samples, and there are colour-managed examples in the Skia test suite. TenFourFox's WebP support currently can display lossy, lossless, transparent and colour-managed images, and will properly use any embedded colour profile. However, it is not currently AltiVec-accelerated (we do have some AltiVec VP8 code, so this should be possible at some point), and it does not yet support animated WebP images, which will appear blank. For this reason we don't pass an Accept: header indicating we accept WebP images like mainline Firefox and certain other browsers, though we will naturally try to display it if we get one. If you encounter issues related to WebP, you can try setting image.webp.enabled to false, but I'm planning to ship this support in FPR13 final, so it defaults to true. The other support is for AppleScript. One of the few advantages of being at feature parity instead of source parity is that we can feel free to implement features mainline Firefox doesn't want or consider a current priority, and one long-standing request going back to the pre-Firefox days is AppleScript support. In fairness, this is hard to achieve in Firefox, and getting harder because of its cross-platform asynchronous nature. Many of the assumptions AppleScript makes about an application and its internal object model are routinely violated for performance reasons in Firefox, and Firefox is not primarily written in Objective-C, so there need to be bridges written to regular C++ and JavaScript, proxy objects designed, etc. Since there was never any agreement on how this internal plumbing should look, only some speculative work was ever completed, and Firefox to this day only supports the basic AppleScript suite and some limited automation through GUI scripting methods. However, one thing that would certainly be handy for those non-daily drivers who might have a Power Mac sitting around doing nothing is to automate some tasks with it, like a kiosk or a display, or to assist with certain rote tasks. For that, AppleScript would certainly be the most painless way of doing so, so here is a first cut of AppleScript support for TenFourFox. Essentially I took that 8-year-old speculative patch, modified it to work with Firefox 45 and 10.4 (some of the dictionary actually comes from the dearly departed Camino, which had rich AppleScript support of its own), and greatly expanded its feature set to yield TenFourFox's AppleScript module. With FPR13 beta, open the AppleScript Script Editor.app, switch to the Event Log tab, and try this script (substitute your TenFourFox application name for TenFourFoxG5): tell application "TenFourFoxG5"  repeat with w in every browser window    repeat with t in every tab of w      repeat while (t is busy)        delay 1      end repeat      get name of t      get URL of t    end repeat  end repeatend tell This will iterate through every open browser window and every tab within that window, check an important synchronization property to make sure that the tab is not busy (being opened or being manipulated), and then report the name (title) and URL (location) of what's loaded in the Event Log. If you're an AppleScript jockey, you can well imagine what you can do with that information. Tabs also have other useful properties, like plaintext and HTML to get the text or HTML contents respectively of a tab. You might also want to create scripts for the Script menu (assuming you have that enabled) that act on text you have highlighted. TenFourFox can do that too: tell application "TenFourFoxG5"  repeat while (current tab of front browser window is busy)    delay 1  end repeat  display dialog ("" & selected of current tab of front browser window)end tell If you put this script into the Script menu, then highlight some text and select this script. A dialogue box will appear with the text you have selected. (Similarly, paste it into the Script Editor and run it to see.) You can also turn TenFourFox into an automated kiosk. Here's a script that opens a new window, makes it full screen, and then updates the display with what the New York state traffic cameras see on the Long Island Expressway every 15 seconds. It uses a second synchronization property called opening to determine when it's safe to manipulate the new window. (To stop it, Alt-Tab to the Script Editor, click Stop, then return to TenFourFox and close the fullscreen window with Cmd-W.) tell application "TenFourFoxG5"  activate  make new browser window  repeat while (opening)    delay 1  end repeat  tell front browser window    set fullscreen to true    set URL to "https://511ny.org/map/Cctv/428834--20"    repeat      delay 15      reload current tab    end repeat  end tellend tell TenFourFox can also be automated with GUI scripting as well, which can be used to manipulate the pulldown menus and even deliver clicks and keyboard events on web pages and the browser chrome. The complete dictionary, like any scriptable app, can be viewed from the Script Editor's Open Dictionary... option. Do note there are a few gotchas and a few things that don't work as expected, and you cannot currently control foxboxes with AppleScript even if they use FPR13; you can read all about the current state of AppleScript support and get many more examples of scripting on the TenFourFox Github AppleScript wiki entry. It's not a perfect mapping of Firefox/TenFourFox onto AppleScript, but it's much better than mainline Firefox which can barely be script-controlled at all. Please consider this support to be a work in progress and there may be more bugs and features yet to add(ress). Post your comments as usual. Like I say, I'm still concerned over the deficiencies accumulating in the browser that I don't know what to do with and don't have an easy means to patch into the browser core. That said, keep in mind that even if we did try to get a port of 52 off the ground to address these problems -- the functionality of which wouldn't guaranteed and has several major changes which would badly compromise TenFourFox's platform base -- we'd just have different deficiencies once Fx60 becomes the typical minimum, so it only delays the inevitable, and the Rust requirement for 54+ makes any later wholesale port impossible. Nevertheless, in the meantime these new features, although admittedly incomplete, at least give some additional functionality to the browser, and that's not worth nothing. FPR13 will go final with Firefox 66 on March 19. [Less]

18 months ago I wrote about some work I did to speed up the Rust compiler (rustc). I’ve recently taken this work up again. Also, in the meantime rustc’s build system has been replaced and its benchmark suite has been overhauled. So it’s a good time ... [More] for an update. Getting the code The steps for getting the rustc code haven’t changed. First, I fork the main Rust repository on GitHub. Then I make two local clones: a base clone that I won’t modify, which serves as a stable comparison point (rust0), and a second clone where I make my modifications (rust1). I use commands something like this: user=nnethercote for r in rust0 rust1 ; do git clone https://github.com/$user/rust $r cd $r git remote add upstream https://github.com/rust-lang/rust git remote set-url origin [email protected]:$user/rust done Building the Rust compiler The compiler’s build system is complex with many possible invocations and configurations. I’ll cover the absolute minimum information required to understand how I’ve been using it. First, you need a config.toml file, which sits at the root of the repository and dictates the compiler’s configuration. I used the provided config.toml.example as a starting point, cut it down a lot, and ended up with the following. [llvm] optimize = true release-debuginfo = true assertions = false [rust] optimize = true codegen-units = 1 debug-assertions = false debuginfo = true debuginfo-lines = true jemalloc = false # EDIT: this used to be `use-jemalloc = false` It’s possible that some of these lines just restate defaults, but I figure it doesn’t hurt to be explicit. This configuration has the following characteristics. It results in the production of a fully optimized rustc, which is important for profiling. The exception to this is that I disable jemalloc, because DHAT doesn’t work when jemalloc is enabled. It has maximal debug info present, which ensures that profiles are as detailed as possible. Building rustc can be confusing, particularly because of the multiple compiler stages and the terminology around them. Here is the command I use. ./x.py build --stage 2 src/rustc This produces a stage 2 compiler that can handle procedural macros and so is suitable for profiling the benchmark suite. The benchmark suite rustc’s benchmark suite is called rustc-perf. It consists of two parts: collector: The 24 benchmark programs, 14 of which are “real” code (i.e. crates used in real applications), and 10 of which are toy programs or stress test microbenchmarks. Also, the harness code that runs and measures them. site: Code for displaying measurements as a website. The test harness is very thorough. For each benchmark, it measures Debug, Opt, and Check (no code generation) invocations. Furthermore, within each of those categories, it does five or more runs, including a normal build and various kinds of incremental builds. A full benchmarking run measures over 400 invocations of rustc. Note however that only the compilation of the final crate is measured in each benchmark; compilation of dependent crates is not included. rustc-perf was created primarily for the perf.rust-lang.org site, which tracks rustc’s performance over time. I recently modified it so it could be used to compare two builds of rustc on a local machine, which is a fundamental operation when optimizing. This can be done by running the suite and site locally and navigating to the local “compare” page, which looks like this: Note that rustc-perf uses perf-stat for its measurements, so the benchmarking functionality currently only works on Linux. I also extended rustc-perf so the benchmarks can be run under a profiler. I implemented support for perf-record, Cachegrind, and DHAT, because they are the profilers that I am most familiar with; it isn’t hard to add support for other profilers (including non-Linux ones). The advantage of integrating support for a profiler intto rustc-perf is that it gets the profiler invocations underneath the Cargo invocations, ensuring that the right rustc invocations are measured. Wins Here are the improvements I’ve made to rustc over the past few weeks. #49993: Cachegrind’s output showed that derived methods for the Token type were taking up significant time. This PR changed the ‘#’ counts in raw Lit variants from usize to u16, which reduced the size of Token from 32 to 24 bytes, speeding up some of the runs for coercions and html5ever by 1%. #50051: Rust’s Option::ok_or function transforms an Option value into a Result. It’s a bit of a footgun… as the docs say: Arguments passed to ok_or are eagerly evaluated; if you are passing the result of a function call, it is recommended to use ok_or_else, which is lazily evaluated. DHAT’s output showed that one hot allocation site involved the creation of a String while getting the value of the MIRI_BACKTRACE environment variable. This seemed to me like a strange thing to be happening frequently, and it turns out that it was at the end of a chain of calls that were only needed in the (rare) error case of an ok_or call. This PR changed the code to use a trivial closure with ok_or_else, speeding up runs for a lot of benchmarks, the best by 6%. #50052: DHAT’s output showed that the char_lit function, which parses “\u{…}” literals, was doing a lot of allocations while stripping out ‘_’ chars. This PR avoided that allocation, speeding up various runs — particularly ones for regex, futures, clap, coercions, hyper, and encoding — the best by 6%. #50106: Cachegrind’s output showed that the nearest_common_ancestor function, which computes the lowest common ancestor of two nodes in a scope tree, was very hot. The algorithm in use constructed the full scope chain for each node, and then worked backward from the end of the two scope chains until a difference was found. This is a reasonable algorithm in many circumstances, but some ad hoc instrumentation (eprintln! statements plus some simple post-processing) showed that the scope chains usually only differ by a handful of elements at the front and then have very long common tails, with dozens or even hundreds of elements. This PR switched to a different algorithm that looks for differences from the front of the scope chain, speeding up runs for many benchmarks, the best by 8%. #50174: By default, Rust’s HashSet and HashMap use a hash function that is very high quality but also very slow. Therefore, the Rust compiler internally uses different types, FxHashSet and FxHashMap, which are identical to the standard ones except they use a much faster hash function. Unfortunately, it’s easy to forget about them and use the standard hash tables instead. Cachegrind’s output showed that the default hash function code (SipHash) was executed a lot, and that one particularly hot hash table (the symbol interner) was using HashMap. This PR (trivially) changed that table to an FxHashMap, speeding up runs for numerous benchmarks, the best by 5%. #50240: Some of Rust’s standard containers, such as Vec, HashSet, and HashMap, have the nice property that by default they don’t allocate until an element is inserted. This is good because it’s surprising how often such containers are created but never inserted into. DHAT’s output showed that such behaviour would also help with a couple of the compiler’s uses of BTreeMap. I tried and failed to implement this behaviour directly in BTreeMap; according to Gankro, “BTreeMap is some of the most complex unsafe code in libstd” and “I just scared off a grizzled firefox dev explaining it“! Instead this PR introduced a thin wrapper type (LazyBTreeMap) around BTreeMap and used it in the handful of relevant places within the compiler, speeding up the runs for several benchmarks, the best by 3%. #50266 is open to do the general fix for BTreeMap, whereupon LazyBTreeMap will be able to be removed. #50246: Cachegrind’s output showed that a function named dump_allocs was hot for some benchmarks. This sounded to me like a logging or debugging function of some kind, and investigation confirmed that it was traversing data structures in order to build up strings that went unused in the standard case where logging is disabled. This PR (trivially) changed this function and a couple of related ones to be no-ops if logging is disabled, speeding up runs for coercions, tuple-stress, html5ever, and encoding, the best by almost 15%! This shows how not doing unclever things is often as important as doing clever things when it comes to optimizing software. Update: It’s worth noting that I also made three or four optimization attempts that didn’t work out — where I made a change that seemed like it should help, based on profiling data, but the effect was negligible. Success isn’t guaranteed! Future work All of the PRs mentioned above (except for the aborted BTreeMap change) involved small, simple changes to the Rust compiler’s code. I’m not a rustc expert, but I do know how to use a couple of profilers well, and I’ve been able to make a difference. I’m sure there are more improvements of this nature to be made, and I encourage other people to try profiling rustc with their favourite profilers to see what they can find. This is valuable because rustc’s speed is something that Rust users often complain about. And it’s fun, if you like that sort of thing   I’m happy to help people, and the members of the #rustc IRC channel are very friendly and helpful. Having said that, in a lot of cases, especially for opt builds, the majority of execution time is within LLVM, which rustc uses for code generation. Speeding up LLVM itself may be difficult, but I hope/suspect there is room for improvement in the way that rustc interacts with LLVM. If anyone has ideas on that front I’d love to hear about them. [Less]

When I started at Mozilla in 2008, I landed my dream job, as the Director of Add-ons for Firefox. I believed then, as I do today, that one size doesn’t fit all with Firefox. Fast forward to 2019 We’ve seen many changes in the tech landscape since we ... [More] launched addons.mozilla.org (AMO) in 2005. A few add-ons have millions of users, while there are many add-ons that have smaller audiences with specific needs. One add-on I really like is AddToAny, which lets me share on social networks. It is similar to a feature we used to have in Firefox that we removed due to lack of use, and I’m sure the 5,000 Firefox users of AddToAny are happy to have it. Unfortunately, the same system that allows privacy and security extensions to work can also make people vulnerable to data mining and malicious activity. While our users love how they can make Firefox theirs, they also look to us to maintain their safety and privacy on the web. Now more than ever, we need to deliver on the trust our users place in us and the expectations we place on our users to understand the choices they make with regards to the software they install. In many ways, we’ve mitigated risks by adopting WebExtensions as our means for extending Firefox, but as more and more functionality migrates to the cloud, policing this ecosystem through code review and policy is impractical. Fulfilling our brand promise of security and privacy We’ve been discussing ways to secure the extension ecosystem to better fulfill our brand promise of security and privacy for Firefox users. Finding the balance between openness and security is an extremely hard problem to solve, but we are going tackle it by making a few changes to the ecosystem now and through 2020. In the spirit of iterating towards a reasonable set of changes that are intended to reduce risk to Firefox users as well as reduce the burden placed on smaller add-on developers, we’re exploring the following: Helping users discover through Mozilla properties a curated set of extensions that we believe are useful and valuable. Investing in helping users better understand the risks extensions can present, and giving them the tools to assist in managing those risks. Reducing the risk of showing potentially malicious extensions through our products and services. This requires an ecosystem-wide approach, and there are a number of unknowns to address in regards to discovery and publication platforms (including Firefox and addons.mozilla.org). Stay tuned As we explore the future of add-ons we will continue to make users’ security and privacy a priority. We will test and try different things, and work with the Firefox developer community to find a good place where we are confident that our users will be safe whenever they use Firefox. The post Keeping Add-Ons Safe for our Users appeared first on Future Releases. [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 News & Blog Posts Moving from Ruby to Rust. Rust lifetime visualization ideas. Generators II: The question mark problem. A list of itch.io games written in Rust. Cross-compiling Rust code to Minix. One hundred Rust PRs later. This week in Rust and WebAssembly 10. Crate of the Week This week's crate is num-format, a crate to format numbers to international standards. Thanks to Vikrant 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. RustFest is searching for local teams to apply for the next events. The CLI-WG wants to help other CLI maintainers to write good first issues for contributions. TiKV: Figure out how to add a second "release" profile for "dev+optimized" builds. TiKV: Consolidate rocksdb imports into one module for engine abstraction. TiKV: Avoid unnecessary clone of unstable raft log. If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 247 pull requests were merged in the last week Implement incremental "fat" LTO Enable comparing fat pointers impl iter() for dyn Error Improve the error messages for missing stability attributes Cut down on number formating code size Reduce the size of hir::Expr Make saturating_add and saturating_sub const functions Stabilize slice_sort_by_cached_key Stabilize str::escape_* methods with new return types Stabilize the time_checked_add feature Update the future/task API Speed up the fast path for assert_eq! and assert_ne! cargo: Stabilize Alternative Registries Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: RFC 2570: Linked list cursors. 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] #[link(kind="raw-dylib")]. [disposition: merge] Associated type defaults. Tracking Issues & PRs [disposition: merge] Relax some Ord bounds on BinaryHeap. [disposition: merge] Relax some Hash bounds on HashMap and HashSet. [disposition: merge] Stabilize TryFrom and TryInto with a convert::Infallible empty enum. [disposition: merge] Clarify guarantees for Box allocation. [disposition: merge] dbg!() without parameters. New RFCs No new RFCs were proposed this week. Upcoming Events Online Feb 27. Rust Events Team Meeting on Telegram. Mar 6. Rust Community Team Meeting on Discord. Africa Mar 6. Johannesburg, ZA - Rust on embedded. Europe Feb 28. Copenhagen, DK - Copenhagen Rust Hack Night #0xC. Feb 28. Torino, IT - Rust Turin Meetup. Feb 28. Wroclaw, PL - Rust Wroclaw Meetup. Mar 6. Berlin, DE - Berlin Rust Hack and Learn. North America Feb 21. San Diego, US - San Diego Rust. Feb 21. Arlington, US - Rust DC—Learn+Try: Custom Redis Datastructures. Feb 25. Durham, US - Triangle Rustaceans. Feb 26. Irvine, US - Orange County Rust. Feb 26. Stanford, US - [@ Stanford] Barriers to Learning Rust, Wasmer. Feb 27. Ann Arbor, US - Ann Arbor Rust Meetup. Feb 27. Mesa, US - Phoenix Rust: Embedded Devices. Mar 6. Indianapolis, US - Indy.rs. Mar 6. Atlanta, US - Rust Atlanta Meetup. Mar 6. Vancouver, CA - Vancouver Rust meetup. 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 Rust Software Consultant at Knoldus, Noida, IN. Software Developer at Finhaven, Vancouver, CA. Software Engineer at Discord, San Francisco, US. Network Engineer at NearProtocol, San Francisco, US. Navitia Software Engineer at Kisio Digital, Paris, FR. Rust web developer at Impero, Denmark/remote. Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week … the experience I had in 2019 was dramatically better than the first time I touched the language. After a month I’m feeling very comfortable, and looking forward to writing more. Ryan Ragona, Learning Rust in 2019 Thanks to Jules Kerssemakers for the suggestion! Please submit your quotes for next week! This Week in Rust is edited by: nasa42, llogiq, and Flavsditz. 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 News & Blog Posts Moving from Ruby to Rust. Rust lifetime visualization ideas. Generators II: The question mark problem. A list of itch.io games written in Rust. Cross-compiling Rust code to Minix. One hundred Rust PRs later. This week in Rust and WebAssembly 10. Crate of the Week This week's crate is num-format, a crate to format numbers to international standards. Thanks to Vikrant 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. RustFest is searching for local teams to apply for the next events. The CLI-WG wants to help other CLI maintainers to write good first issues for contributions. TiKV: Figure out how to add a second "release" profile for "dev+optimized" builds. TiKV: Consolidate rocksdb imports into one module for engine abstraction. TiKV: Avoid unnecessary clone of unstable raft log. If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 247 pull requests were merged in the last week Implement incremental "fat" LTO Enable comparing fat pointers impl iter() for dyn Error Improve the error messages for missing stability attributes Cut down on number formating code size Reduce the size of hir::Expr Make saturating_add and saturating_sub const functions Stabilize slice_sort_by_cached_key Stabilize str::escape_* methods with new return types Stabilize the time_checked_add feature Update the future/task API Speed up the fast path for assert_eq! and assert_ne! cargo: Stabilize Alternative Registries Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: RFC 2570: Linked list cursors. 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] #[link(kind="raw-dylib")]. [disposition: merge] Associated type defaults. Tracking Issues & PRs [disposition: merge] Relax some Ord bounds on BinaryHeap. [disposition: merge] Relax some Hash bounds on HashMap and HashSet. [disposition: merge] Stabilize TryFrom and TryInto with a convert::Infallible empty enum. [disposition: merge] Clarify guarantees for Box allocation. [disposition: merge] dbg!() without parameters. New RFCs No new RFCs were proposed this week. Upcoming Events Online Feb 27. Rust Events Team Meeting on Telegram. Mar 6. Rust Community Team Meeting on Discord. Africa Mar 6. Johannesburg, ZA - Rust on embedded. Europe Feb 28. Copenhagen, DK - Copenhagen Rust Hack Night #0xC. Feb 28. Torino, IT - Rust Turin Meetup. Feb 28. Wroclaw, PL - Rust Wroclaw Meetup. Mar 6. Berlin, DE - Berlin Rust Hack and Learn. North America Feb 21. San Diego, US - San Diego Rust. Feb 21. Arlington, US - Rust DC—Learn+Try: Custom Redis Datastructures. Feb 25. Durham, US - Triangle Rustaceans. Feb 26. Irvine, US - Orange County Rust. Feb 26. Stanford, US - [@ Stanford] Barriers to Learning Rust, Wasmer. Feb 27. Ann Arbor, US - Ann Arbor Rust Meetup. Feb 27. Mesa, US - Phoenix Rust: Embedded Devices. Mar 6. Indianapolis, US - Indy.rs. Mar 6. Atlanta, US - Rust Atlanta Meetup. Mar 6. Vancouver, CN - Vancouver Rust meetup. 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 Rust Software Consultant at Knoldus, Noida, IN. Software Developer at Finhaven, Vancouver, CA. Software Engineer at Discord, San Francisco, US. Network Engineer at NearProtocol, San Francisco, US. Navitia Software Engineer at Kisio Digital, Paris, FR. Rust web developer at Impero, Denmark/remote. Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week … the experience I had in 2019 was dramatically better than the first time I touched the language. After a month I’m feeling very comfortable, and looking forward to writing more. Ryan Ragona, Learning Rust in 2019 Thanks to Jules Kerssemakers for the suggestion! Please submit your quotes for next week! This Week in Rust is edited by: nasa42, llogiq, and Flavsditz. 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 News & Blog Posts Moving from Ruby to Rust. Rust lifetime visualization ideas. Generators II: The question mark problem. A list of itch.io games written in Rust. Cross-compiling Rust code to Minix. One hundred Rust PRs later. This week in Rust and WebAssembly 10. Crate of the Week This week's crate is num-format, a crate to format numbers to international standards. Thanks to Vikrant 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. RustFest is searching for local teams to apply for the next events. The CLI-WG wants to help other CLI maintainers to write good first issues for contributions. TiKV: Figure out how to add a second "release" profile for "dev+optimized" builds. TiKV: Consolidate rocksdb imports into one module for engine abstraction. TiKV: Avoid unnecessary clone of unstable raft log. If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 247 pull requests were merged in the last week Implement incremental "fat" LTO Enable comparing fat pointers impl iter() for dyn Error Improve the error messages for missing stability attributes Cut down on number formating code size Reduce the size of hir::Expr Make saturating_add and saturating_sub const functions Stabilize slice_sort_by_cached_key Stabilize str::escape_* methods with new return types Stabilize the time_checked_add feature Update the future/task API Speed up the fast path for assert_eq! and assert_ne! cargo: Stabilize Alternative Registries Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: RFC 2570: Linked list cursors. 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] #[link(kind="raw-dylib")]. [disposition: merge] Associated type defaults. Tracking Issues & PRs [disposition: merge] Relax some Ord bounds on BinaryHeap. [disposition: merge] Relax some Hash bounds on HashMap and HashSet. [disposition: merge] Stabilize TryFrom and TryInto with a convert::Infallible empty enum. [disposition: merge] Clarify guarantees for Box allocation. [disposition: merge] dbg!() without parameters. New RFCs No new RFCs were proposed this week. Upcoming Events Online Feb 27. Rust Events Team Meeting on Telegram. Mar 6. Rust Community Team Meeting on Discord. Africa Mar 6. Johannesburg, ZA - Rust on embedded. Europe Feb 28. Copenhagen, DK - Copenhagen Rust Hack Night #0xC. Feb 28. Torino, IT - Rust Turin Meetup. Mar 6. Berlin, DE - Berlin Rust Hack and Learn. North America Feb 21. San Diego, US - San Diego Rust. Feb 21. Arlington, US - Rust DC—Learn+Try: Custom Redis Datastructures. Feb 25. Durham, US - Triangle Rustaceans. Feb 26. Irvine, US - Orange County Rust. Feb 26. Stanford, US - [@ Stanford] Barriers to Learning Rust, Wasmer. Feb 27. Ann Arbor, US - Ann Arbor Rust Meetup. Feb 27. Mesa, US - Phoenix Rust: Embedded Devices. Mar 6. Indianapolis, US - Indy.rs. Mar 6. Atlanta, US - Rust Atlanta Meetup. Mar 6. Vancouver, CN - Vancouver Rust meetup. 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 Rust Software Consultant at Knoldus, Noida, IN. Software Developer at Finhaven, Vancouver, CA. Software Engineer at Discord, San Francisco, US. Network Engineer at NearProtocol, San Francisco, US. Navitia Software Engineer at Kisio Digital, Paris, FR. Rust web developer at Impero, Denmark/remote. Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week … the experience I had in 2019 was dramatically better than the first time I touched the language. After a month I’m feeling very comfortable, and looking forward to writing more. Ryan Ragona, Learning Rust in 2019 Thanks to Jules Kerssemakers for the suggestion! Please submit your quotes for next week! This Week in Rust is edited by: nasa42, llogiq, and Flavsditz. Discuss on r/rust. [Less]

Using Docker’s multi-stage build feature and Python’s virtualenv tool, we can make smaller and more secure docker images for production.

Hello Mozillians! As you may already know, last Friday February 15th – we held a new Testday event, for Firefox 66 Beta 8. Thank you all for helping us make Mozilla a better place: gaby2300, Priyadharshini  A and Aishwarya Narasimhan. Results: – ... [More] several test cases executed for “Storage Access API/Cookie Restrictions” . Thanks for another successful testday! [Less]

Firefox 66 is currently in beta and, for extension developers, the changes to the WebExtensions API center primarily around improving performance, stability, and the development experience. A total of 30 issues were resolved in Firefox 66, including ... [More] contributions from several volunteer community members. Major Performance Improvements for Storage I want to start by highlighting an important change that has a major, positive impact for Firefox users. Starting in release 66, extensions use IndexedDB as the backend for local storage instead of a JSON file. This results in a significant performance improvement for many extensions, while simultaneously reducing the amount of memory that Firefox uses. This change is completely transparent to extension developers – you do not need to do anything to take advantage of this improvement.  When users upgrade to Firefox 66, the local storage JSON file is silently migrated to IndexedDB. All extensions using the storage.local() API immediately realize the benefits, especially if they store small changes to large structures, as is true for ad-blockers, the most common and popular type of extension used in Firefox. The video below, using Adblock Plus as an example, shows the significant performance improvements that extension users could see. Other Improvements The remaining bug fixes and feature enhancements won’t be as noticeable as the change to local storage, but they nevertheless raise the overall quality of the WebExtensions API and make the development experience better.  Some of the highlights include: Another improvement was landed in Firefox so that it uses less memory when extensions load objects from storage into memory. The “Manage Extension Shortcuts” page now uses a default icon if no icon was included in the manifest file. Fixed a case where the window.close() API was not properly closing browser extension popups. Extension ports are no longer disconnected when switching tabs in Responsive Design Mode. By-passing tracking protection now works for domains listed as host permissions when those domains are used as iframes within an extension page. The permissions prompt no longer appears when newly added host permissions are a subset of host permissions that have already been granted. The webRequest API will now throw an error if you try to use it in blocking mode without declaring the webRequestBlocking permission Bookmarks context menu items, added in Firefox 59, now also appear in the bookmarks sidebar and library window. Manifest files with no specified default icon now throw an error. Firefox no longer emits a warning when the manifest property `background.persistent` is set to `true`. Thank you to everyone who contributed to the Firefox 66 release, but a special thank you to our volunteer community contributors, including: tossj, Varun Dey, and Edward Wu. The post Extensions in Firefox 66 appeared first on Mozilla Add-ons Blog. [Less]