mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 4 maanden 4 dagen geleden

Firefox UX: Just another day

wo, 27/09/2017 - 12:03
Because we only like to reinvent the wheel when we have toBeta release

For many, today is just another day. Well, not for me, my team, and all the other people who spent the last six months on version 57 of the browser, the new Firefox Quantum. Today, we’re going into Beta release with the new UI which adheres to the new Photon visual language. If you feel your head spinning, you’re right. Let’s put one thing after another.

Style guide vs. design systems

My name is Emanuela Damiani, and in few days, it will be one year since I began working at Mozilla.

When I joined, I was asked to focus my attention on two products in particular: add-ons and the new design system.

Building a design system is not an easy job. First, what is a Design System? What is it not? What are the differences between a style guide and a pattern library? All those questions were buzzing in my mind like one hundred bees.

<figcaption>A design system is not a one-man job. When you I say ‘we’, I mean: Tina, Tori, Helen, Amin, Markus, Philip and myself.</figcaption>

Our team is not too big, or too small. It has six members, distributed from Vancouver to Taipei, passing through central Europe, and with just one person able to work 100% on the design system. Since the beginning, we have tried to use Slack as much as is possible to make it easy for anyone to give feedback and fill the gap of not being able to share time together.

When we all met together at the beginning of November last year, there was a zombie Firefox style guide in the wild.

We wanted to learn from that failure. We spent time interviewing anyone who worked on that project. What was the challenge? Why did the few things in the style guide feel so different from everything present in the product?

<figcaption>A design system success is not connected with the launch of style-guide or a UI-kit. The real success happens when your design system is adopted in your products.</figcaption>

One main point of failure of the previous style guide was in the process taken by the team. Without a complete inventory, the team was documenting and improving at the same time, ending up with some excellent and delightful insights for future development but nothing truly actionable for the present or representative of the product.

Plus, the style-guide had a strong focus only on the desktop, ignoring the complex ecosystem where Firefox products live.

Photon: from a visual refresh to a visual language“We started from the existing style guide, we checked if the identified macro areas were still valid, and we analyzed (or looked at) other existing design systems that were around for a while.”— Amin

Meanwhile, somewhere else in the organization, a group of people decided it was time to give all the cool improvements on the backend (a.k.a. Quantum) a nice visual refresh. The code name for this project was Photon.

That was the perfect opportunity for us. We started from there. All of the visual changes are expected to be in the product, overruling previous decisions. We had to start somewhere, so we started there.

Our first job was to understand all of the design decisions and be ready to raise our hands if some choices contradicted each other or did not meet accessibility standards. We made them aware of the other projects, products, constraints, and needs of other teams so that the team in charge of the visual refresh would have a more broad understanding of the design and development requirements.

While we were documenting, we ended up actively co-designing what eventually became a real design language that supported multiple platforms and multiple products.

Design for Scale“The higher the expected visibility on parts of your work, the more important it is to align to Photon. If very limited visibility is expected, full alignment is of lower priority. Use platform components until you have time to align better.”— Design for Scale, Photon Design System

We wanted to have documentation that combines theory and resources where theories are principles, visual guidelines, and patterns, and resources are everything from visual assets to tokens, from demos to templates, and from tools to code.

But how might we build a successful design language that also able to feel native in all the different platforms? Designing for scale is a challenging, delicate task. We wanted to support people going through this task and provide written content to help them understand this principle and apply it.

Feedback, feedback, feedback“With every page, we added we learned, step by step — we learned how to structure pages, how to structure the whole system, and we learned how to align differences between individual design teams and how to get people to make decisions that can be structured and documented.”— Markus

While we’re building the design system, we never stop collecting feedback by everyone on the Firefox team. In the end, those people are our primary users.

We like to think of the design system as a tool, a tool which enables other people, designers and non-designers, to design. It saves time on digging into Sketch files, trying to find patterns from other designers, and fixing design issues like incoherency, accessibility across platforms, and localization.

During Mozilla’s June 2017 All Hands in San Francisco, we spent hours just talking with different product teams, asking for feedback. How are they using the system? How is the system relevant for them?

<figcaption>When you ask “Can you bring somebody from your team?” and 15 people show up, you know you’re doing something right.</figcaption>Photon Design System: today

First, we gave it a name: Photon — it just makes sense, right?

Three months ago, we had a lot of visual decisions documented on the website, and many of those decisions were already on the Nightly release, but the design of our site didn’t really seem to reflect any of it. So, we applied all the principles documented in the product. The Photon Design System website today reveals how we use it in the wild.

We are working on the components and patterns. Day to day, our job resembles a detective’s. We follow leads in all the products and identify the ones that can bring extra value to the Firefox team. Where we see complexity, we act to simplify.

We want everyone who builds for Firefox to use the design system in their everyday workflow. Using the design system should be not more than easy, it should feel natural. To accomplish that, we’re focusing not only on the content but also on building tools and resources.

Final thoughts

For many, today is just another day. For the Photon Design System team, it’s when we see the system’s value realized.

<figcaption>Photon Design System</figcaption>

A design system is not built overnight but shaped gradually through our daily practices. It evolves every day — or maybe every week — and most importantly, it’s never done.

Just another day was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Air Mozilla: Kernel Recipes 27 Sept. (Full Day)

wo, 27/09/2017 - 10:00

Kernel Recipes 27 Sept. (Full Day) Share Kernel Contributions and Community

Categorieën: Mozilla-nl planet

Cameron Kaiser: TenFourFox FPR3 available ... when SourceForge is (also: Fx57 is yugly)

di, 26/09/2017 - 20:30
Sorry, everyone. I am well aware that SourceForge is down and you can't download TenFourFox FPR3 (or, for that matter, Classilla) right now. I don't have any control over that. If this keeps up more than a day or two, we'll see if we can get alternative hosting up somewhere.

Also, my office PC (Windows 7) is now on the Firefox 57 beta and it's ... really garish and ugly looking. Switching the layout to Compact and the theme to Light helps a little with the tab bar, but the KITT loading tab animation is distracting, the icons manage to be intrusive and bland simultaneously, and the new logo is a bad LSD trip (to say nothing of the fact half my extensions stopped working, and while I knew that was coming, most of them have no replacement because the APIs don't yet exist). While I thought Australis was a step backwards in terms of utility, at least it had some design consistency. Photon, on the other hand, is all over the place and it's an unwelcome change on top of everything else. I'm almost afraid to update Firefox on the MacBook Air.

But, to be fair, it is palpably faster. Much faster. I certainly can't argue that. Nevertheless, the compromises made are such that if it weren't for Google's relentless commitment to snoop on everything I do, I have to candidly say I'm not sure I'd be sticking with the new Firefox.

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Curriculum Workshop, Fall Sept. 2017

di, 26/09/2017 - 18:00

Mozilla Curriculum Workshop, Fall Sept. 2017 Join us for a special, series finale “ask me anything” (AMA) episode of the Mozilla Curriculum Workshop at noon ET, on Tuesday, September 26th, 2017....

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Curriculum Workshop, Fall Sept. 2017

di, 26/09/2017 - 18:00

Mozilla Curriculum Workshop, Fall Sept. 2017 Join us for a special, series finale “ask me anything” (AMA) episode of the Mozilla Curriculum Workshop at noon ET, on Tuesday, September 26th, 2017....

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Firefox Quantum Developer Edition: the fastest Firefox ever with Photon UI and better tooling

di, 26/09/2017 - 16:05

Firefox Quantum is now available in Developer Edition, and this Firefox is fast.

As a reader of the Hacks blog, you may be familiar with Project Quantum, our attempt to refactor, redesign, replace, and modernize the very core of Firefox. We’ve shipped many incremental improvements to Firefox in the past, but this release marks the first milestone where we believe Firefox fundamentally feels like a newer, better browser.

To celebrate, we gave Developer Edition a brand new logo:

Why does this feel like a brand new browser? Read on!

Firefox Quantum: Towards a next-gen browser

Developer Edition now includes “Quantum CSS,” an entirely new CSS engine written in Rust and based on the Servo parallel browser engine project. Additionally, the “Quantum Flow” team tracked down and fixed 369 performance bugs in Firefox, with a special focus on responsiveness and UI interactions. Lastly, the “Quantum DOM” project began overhauling how Firefox prioritizes work, responding more quickly to events like user input while delaying less urgent computations until the browser is idle.

The result? Compared to Firefox six months ago, today’s Developer Edition is twice as fast on benchmarks like Speedometer 2.0 that simulate the real-world performance of modern web applications.

Furthermore, Firefox is 64-bit and multi-process by default, and Firefox’s unique architecture allows it to take advantage of modern, multi-core processors while still respecting your available RAM. Meanwhile, the “Quantum Compositor” project significantly reduced crashes caused by buggy graphics drivers.

Photon: Firefox’s new UI

To complement Quantum, the Photon team rebuilt Firefox’s interface to be faster and more modern:

You’ll hear more about Photon in November, but highlights include redesigned menus, square tabs, and a new “Library” button that acts as a single place for your bookmarks, downloads, history, etc. By default, Photon combines the search and URL bars into a single widget, but the old style is only a preference away.

The “Activity Stream” project redesigned the New Tab Page to feature highlights from your recent history and bookmarks, as well as recommendations from Pocket. Of course, each of these content blocks are optional, and add-ons can completely replace the new tab page to create entirely different experiences.

We also refreshed form handling in Firefox, adding a brand new autofill feature and implementing built-in widgets for <input type=date> and <input type=time> elements.

Lastly, Firefox’s preferences were completely redesigned and are now searchable.

DevTools in 57: Redesigned and better than ever

Firefox Quantum: Developer Edition also includes a ton of refined, redesigned, and brand new developer tools.

A few highlights:

  • The Console, Debugger, and Network tabs are now implemented using standard web technologies, including React and Redux, as part of our “devtools.html” effort.
  • The Inspector gained tons of new features for working with CSS Grid, CSS Variables, toggling classes on elements, etc.
  • The Console now supports grouping messages and expanding / inspecting objects in-line.
  • The Debugger offers completely new ways to search, navigate, and debug projects.

And that’s not all. To read in greater depth about what’s new in Firefox Developer Tools, check out Developer Edition Devtools Update.

 

Project Quantum: There’s more to come

Today’s release is a major milestone in Project Quantum, but we’re not done. Future releases of Firefox will include Quantum Render, a brand new, GPU-optimized rendering pipeline based on Servo’s WebRender project, and Quantum DOM Scheduler, a new technique that ensures that tabs in the background can’t slow down your active tabs.

Try out Developer Edition today, or sign up to get notified when Firefox Quantum is released to mainline Firefox. Either way, stay tuned to the Hacks blog to learn more about Project Quantum!

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Developer Edition Devtools Update: Now with Photon UI

di, 26/09/2017 - 16:05

Firefox 57 Developer Edition was just released! It’s such an advance that we’ve given this browser a new name: Firefox Quantum. This is a great opportunity to tell you about what the DevTools team has been up to since our last major update back in March.

DevTools visual update


Say hello to a complete visual refresh of both our Light and Dark themes, matching the new visual style of Firefox Quantum. (We call this UI Photon.) The new design is simpler, cleaner and has better contrast. We also updated all the syntax highlighting colors to improve text readability. Check out this in-depth blog post at Firefox Nightly News by our UX Designer Victoria Wang for more details and research that went into choosing just the right colors.

Inspector

CSS Grid is taking over the web, and DevTools are here to help you master grids. Head over to the new Layout panel in the Inspector, where the CSS Grid widget lists all of the grid containers on the page. The grid overlays have also been improved: they now show line numbers, area names and adapt to the most complex CSS transforms.

Ever been bugged by a DOM element showing up in an unexpected spot? The Layout panel shows detailed box-model information, with all properties relevant to positioning, including the offset parent.

There are too many goodies in the Layout panel to list here, so have a look at this recent post covering the layout panel in the new Inspector.

CSS Variables are now widely supported and ready to be used in the wild! The Inspector shows the current value of a variable on hover. It also explains why a variable has a given value for the selected element.

It’s super-useful to be able to add, remove, and togge classnames when debugging CSS. Now you can easily do this from the Inspector. Click on the “.cls” button to reveal all of the classes applied to the selected element. You can toggle any of them or add new ones.

Don’t remember all the possible values possible for font-variant? That’s ok, you shouldn’t have to! Our CSS auto-completion now returns many more values.

I want to highlight one last feature of the Inspector. If you work with test automation tools, you will like the new Copy XPath context-menu option. This feature used to be in Firebug, and we are really glad to bring it back to DevTools!

Console

We are shipping a new Console UI in Firefox Quantum (Firefox 57)! Joining the Debugger and the Network Monitor, the Console has been rewritten using modern web technologies such as React and Redux. Looking forward to your feedback!

The new Console allows you to inspect objects in context. When an object is logged in the console, you can simply expand it and explore its contents. Existing features of the previous UI, such as filters and network request details, have also been ported to this new front-end.

Console.group() and groupCollapsed() are super useful to make your logs more organized and readable. Modern frameworks’ loggers nicely group & format bursts of updates. You can now collapse log groups to see only what matters to you.

Did you know you could persist logs when navigating from page to page? The “Persist Logs” checkbox is now much easier to find, directly in the Console panel.

Debugger

Thanks to all the feedback received since the new Debugger was first released on Developer Edition, we are shipping it to all channels with Firefox 56. Thanks again for your help, let’s take a look at the main new features.

Outline View & Function Search

Debugging is often about finding the right method. The new debugger features an outline view, with links to all the methods defined in the current source. If you prefer searching, you can also use function search and quickly jump to any function.

Project Search

Speaking of search, the new Debugger introduces project search, a.k.a. “Find in all files”. Pretty useful if you need to find where this alert (“foo”) is coming from. This was one of our top requested features, we are very happy to ship it in Firefox 57.

Collapsed Framework Callstacks

Frameworks and libraries are everywhere in the Web landscape, and Firefox Developer Tools embrace this! The debugger now displays matching icons in callstacks for framework sources. Framework methods are also collapsed by default in callstacks, so no need to scroll through foreign method calls anymore. You can also enable blackboxing to completely forget about a file and never have to step through it.

Pinned (AST) Breakpoints

With pinned breakpoints, the Debugger will keep track of your breakpoints even when the code changes. You can move methods in your source files, and breakpoints will automatically stay on the correct statements.

Async Stepping

Async & await will change the way we write asynchronous code for the better. The Debugger can now seamlessly step-over or step-in with async functions.

If you want to follow more closely the (very active!) development of the Debugger, you should check out the weekly updates published by the team.

Source maps

Babel, SCSS, WebAssembly, TypeScript… Compiling JS and CSS is now common practice. As a result, the code that the browser uses looks pretty different from the original source files. We finally support sourcemaps in all our major tools, so you can focus on working with your original files.

Network Monitor

Scheme, timings, headers… Here are just some of the new Netmonitor columns! You can choose your own set of columns to see only what you want. The filter input also provides auto-completion based on the column names, to build powerful filter queries.

What does the ETag header mean? What is status code 502? The Netmonitor now links to MDN Web Docs to help you learn about request & response headers, status codes, timings etc…

Timings for DOMContentLoaded and load are crucial when analyzing the performance of a website. They are now clearly visible in the new status bar, next to the requests’ summary.

You can now toggle “Persist Logs” and “Disable cache” right from the Network Monitor UI. This is super handy when you need to inspect a POST request that triggers a page navigation!

Storage Inspector

Tired of typing localStorage.setItem in the Console? You can now add new cookies or localStorage entries directly in the Storage Inspector.

Last but not least, the Storage Inspector is now enabled by default for all channels!

Thanks everyone!

That was a long read, thanks for reading to the end. We hope you will enjoy the new features we are rolling out. Feedback welcome, find us on Slack or on #devtools at irc.mozilla.org. And a HUGE thank you to all the contributors: You are doing an amazing job on DevTools:

  • Abhinav Koppula
  • Adrien Enault
  • Adrien Pachkoff
  • Ahmed Towkir
  • anejaalisha
  • Bomsy (Hubert B Manilla)
  • Brennan Brisad
  • Christopher Phonis-Phine
  • Eric Skoglund
  • Espen Henriksen
  • Gabrielle Singhcadieux
  • Hemant Singh
  • Henri Kemppainen
  • Hossain Al Ikram
  • Jaideep Bhoosreddy
  • Leonardo Couto
  • Locke Chen
  • Maxwell
  • Mayank
  • Micah Tigley
  • Michael Kohler
  • Mike Park
  • Mohammed Yaseen Khan
  • nbeltran14
  • Tim Nguyen
  • Nick Fox
  • Nicolas Ouellet-Payeur
  • Oriol Brufau
  • Pinkney
  • Ragnis
  • Rahul Chaudhary
  • Ruben Schmidmeister
  • Ruturaj Vartak
  • Santiago Paez
  • Sebastian Zartner
  • Sheldon Roddick
  • Stanford Lockhart
  • Stefan Yohansson
  • Stoyan Dimitrov
  • Stylizit (Matt R)
  • Swapnesh Kumar Sahoo
  • Vangelis Katsikaros
  • Vera
  • Vincent Lequertier
  • Xavier ALT
Categorieën: Mozilla-nl planet

Air Mozilla: Embedded Recipes 26 Sept. (afternoon)

di, 26/09/2017 - 16:00

Embedded Recipes 26 Sept. (afternoon) The first embedded conference in Paris

Categorieën: Mozilla-nl planet

Air Mozilla: Embedded Recipes 26 Sept. (afternoon)

di, 26/09/2017 - 16:00

Embedded Recipes 26 Sept. (afternoon) The first embedded conference in Paris

Categorieën: Mozilla-nl planet

The Mozilla Blog: Start Your Engines – Firefox Quantum Lands in Beta, Developer Edition

di, 26/09/2017 - 15:14

Engines are important, both in cars and in browsers. That’s why we’re so revved up this morning – we’re releasing the Beta of a whole new Firefox, one that’s powered by a completely reinvented, modernized engine. Since the version number – 57 – can’t really convey the magnitude of the changes we’ve made, and how much faster this new Firefox is, we’re calling this upcoming release Firefox Quantum.

The journey to Firefox Quantum

Last October we announced Project Quantum, our effort to create a next-generation engine for modern computers, by leveraging technology from our Servo research project. Since then, our engineering team has been relentless in their focus on making Firefox incredibly fast.

Already this year we’ve launched several major improvements to Firefox that have it made it better than ever. For example, we’ve transformed Firefox to run using multiple processes, striking the “just right” balance between speed and memory usage. In addition, we’ve launched game-changing features like WebAssembly and WebVR, enabling super fast, near-native performance for web apps on the desktop and on VR headsets.

We’ve shipped a lot already, but we’ve been planning for many more projects to come together in Firefox Quantum.

Noticeably faster on many of the top websites

Firefox Quantum is such a big leap forward that you’ll feel it instantly, just browsing your favorite websites.

Turns out you can measure Firefox Quantum’s speed, too – our pit crew is kind of obsessed with a data-driven approach. One simple way of estimating browser performance is with Speedometer 2.0, a (still-in-development) benchmark that simulates modern web applications. Results vary based on the computer and apps you’re actively using, but one thing that’s relatively consistent is that Firefox Quantum is about 2X faster than Firefox was a year ago.

We encourage you to make your own comparisons, but here’s a short video that captures our observations when comparing Firefox Quantum and Chrome on various websites. Firefox Quantum is often perceivably faster.

Webpagetest running on Acer Aspire E15. Performance varies based on several factors.

 

So how we did we make Firefox Quantum so fast?

Firefox has historically run mostly on just one CPU core, but Firefox Quantum takes advantage of multiple CPU cores in today’s desktop and mobile devices much more effectively. This improved utilization of your computer’s hardware makes Firefox Quantum dramatically faster. One example: we’ve developed a breakthrough approach to laying out pages: a super fast CSS engine written in Rust, a systems programming language that Mozilla pioneered. Firefox’s new CSS engine runs quickly, in parallel across multiple CPU cores, instead of running in one slower sequence on a single core. No other browser can do this.

We’ve also improved Firefox so that the tab you’re actively using downloads and runs before other tabs you have open in the background. This prioritization of your active tab, along with Firefox’s “just right” multi-process architecture, results in Firefox Quantum often being faster than Chrome, while consuming roughly 30% less RAM.

In addition, for the past several months we’ve run a browser-wide initiative to zap any instances of slowness you might encounter while using Firefox. So far our pit crew has fixed 468 of these issues, both small papercuts and big bottlenecks.

 

Introducing the fast and fluid Photon design

It’s not enough to perform well on benchmarks, it’s also important that our users feel like they’re using a well thought out and high performance product.  To reflect all these under-the-hood improvements, we’ve refined and rebuilt Firefox’s user interface through our Photon project. Our talented team of designers and user researchers spent time understanding how users perceive web browsers, and in particular where they felt they were waiting on their browsers.

With the new design, Firefox leaps ahead with a new interface that reflects today’s reality of High DPI displays and users who are more task focused than they’ve ever been. We’re confident that with Photon, Firefox Quantum users will be impressed by the modern new design that puts their needs first. Photon doesn’t just look good, it’s also smarter. If you’re using Photon on a Windows PC with a touch display, the menus change size based on whether you click with a mouse or touch with a finger.

The new, minimalist design introduces square tabs, smooth animations, and a Library, which provides quick access to your saved stuff: bookmarks, Pocket, history, downloads, tabs, and screenshots. Firefox Quantum feels right at home with today’s mouse and touch-driven operating systems: Windows 10, macOS High Sierra, Android Oreo, and iOS 11.

 

https://blog.mozilla.org/wp-content/uploads/2017/09/Firefox-Quantum-Photon-UI-2.webm

 

 

Pocket built-in

Firefox Quantum enhances Firefox’s integration with Pocket, the read-it-later app that Mozilla acquired last year. When you open a new tab, you’ll see currently trending web pages recommended by Pocket users so you won’t miss out on what’s hot online, as well as your top sites. With the Pocket app for iOS and Android, you’ll have offline access to your saved stories wherever you go.

 

https://blog.mozilla.org/wp-content/uploads/2017/09/Firefox-Quantum-integrates-Pocket.webm

 

Upgrade to Firefox Quantum soon, or download the Beta today

If you’re already among the Firefox faithful, you’ll automatically upgrade to Firefox Quantum on November 14. But, if you enjoy the cutting edge, you can try it in Beta on desktop, Android, and iOS. Or, if you’re a web developer, download Developer Edition, which includes brand new, cutting-edge tools for those who build the web.

So much has changed about Firefox these past few years, and even more is in store. To learn more about Firefox Quantum in November, visit our page and we’ll keep you up to date on the latest news.

We’re super excited to get Firefox Quantum to our beta users and hope you’ll give it a try.

The post Start Your Engines – Firefox Quantum Lands in Beta, Developer Edition appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Air Mozilla: Embedded Recipes 26 Sept. (Full Day)

di, 26/09/2017 - 10:00

Embedded Recipes 26 Sept. (Full Day) The first embedded conference in Paris

Categorieën: Mozilla-nl planet

Air Mozilla: Embedded Recipes 26 Sept. (Full Day)

di, 26/09/2017 - 10:00

Embedded Recipes 26 Sept. (Full Day) The first embedded conference in Paris

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 201

di, 26/09/2017 - 06:00

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 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 Crate of the Week

This week's crate is rustbreak, a crate providing simple single-file storage to e.g. persist settings. Thank you, Dieter Konrad 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.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

157 pull requests were merged in the last week

New Contributors
  • Basile Desloges
  • Bob Sun
  • James Tucker
  • Lucas Morales
  • Marcus Buffett
  • P.Y. Laligand
  • Romain Porte
Approved RFCs

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

Final Comment Period

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

New RFCs

No new RFCs were proposed this week.

Upcoming Events

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

Rust Jobs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

A Box always holds exactly one thing, like a single large struct. A Vec holds zero to many things of exactly one type and can change over time. If you had to relate them, a Box is a Vec with one element that went to Neverland and forgot it could ever grow.

/u/zzyzzyxx on reddit.

Thanks to /u/l-arkham for the suggestion.

Submit your quotes for next week!

This Week in Rust is edited by: nasa42 and llogiq.

Categorieën: Mozilla-nl planet

Eric Rahm: Firefox Memory Usage in the Quantum Era

di, 26/09/2017 - 02:09

This is a continuation of my Are They Slim Yet series. For background see my previous installment.

Firefox’s upcoming release 57 has a huge focus on performance. We’ve quantum-ed all the things but we haven’t really talked about memory usage, which is something that often falls by the wayside in the pursuit of performance. Luckily since we brought AWSY in tree it’s been pretty easy to track memory usage and regressions even on separate development branches. The Stylo team was a big user of this and it shows, we flipped the switch to enable Stylo by default around the 7th and you can see a fairly large regression, but by the 16th it was mostly gone:

Some great work has been happening lately to reduce Stylo's memory usage. https://t.co/TkwPKOQRT2 and https://t.co/C8x59Ur5IC have details.

— Nicholas Nethercote (@nnethercote) September 15, 2017

Hopefully I’ve convinced you we’ve put a lot of work into performance, now let’s see how we’re doing memory-wise compared to other browsers.

The methodology for the test is the same as previous runs: I used the ATSY project to load 30 pages and measure memory usage of the various processes that each browser spawns during that time.

The results Browser Memory Usage.<figcaption class="wp-caption-text">Memory usage of browsers across operating systems.</figcaption>

Edge has the highest memory usage on Windows, Chrome comes in with 1.4X the memory usage of Firefox 64-bit on Windows, about 2X Firefox on Linux. On macOS Safari is now by far the worst offender in memory usage, Chrome and Firefox are about even with Firefox memory usage having gone up a fair amount since the last time I measured.

Overall I’m pretty happy with where we’re at, but now that our big performance push is over I’d like to see us focus more on dropping memory usage so we can start pushing up the number of content processes. I’d also like to take a closer look into what’s going on on macOS as that’s been our biggest regression.

Browsers included are Edge 38 on Windows 10, Chrome Beta 62 on all platforms, Firefox Beta 57 on all platforms, and Safari Technology Preview 40 on macOS 10.12.6.

Note: I had to run the test for Safari manually again, they seem to have made some changes that cause all of the pages from my test to be loaded in the same content process.

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 25 Sep 2017

ma, 25/09/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 25 Sep 2017

ma, 25/09/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

The Mozilla Blog: Adding More Policy Firepower to the Mozilla Network

ma, 25/09/2017 - 19:47
By Mark Surman and Cori Zarek

 

In June, Mozilla launched a new fellowship that brings together policy experts from around the world to advance crucial tech policy efforts. Today, we are excited to announce the appointment of seven advisors to help steer this fellowship into the future. We are also announcing one new fellow, bringing the cohort to 11 fellows from four countries who are already up to great work.

Over the past three months, Mozilla’s Tech Policy Fellows have been digging into their projects to keep the Internet open and freely accessible to all. With most fellows joining directly out of government service, they’re continuing to move forward some of the urgent policy efforts they had been leading, and working to avoid any backsliding that might come with government transitions.

The fellows’ work is focused on protecting net neutrality, advancing policies around artificial intelligence and the Internet of Things, promoting affordable broadband service for vulnerable communities, and more. Amba Kak is our most recent addition, starting this month to work on promoting net neutrality in India.

To advance this work, the fellows are meeting with policymakers inside and outside of government; they’re keynoting major events and giving press interviews about the importance of these topics; and in the coming weeks, they’ll share more about their work with the Mozilla network on our network blog.

To give guidance and support to the fellows, Mozilla formed an Advisory Board comprised of some of the world’s top experts and supporters of a free and open Internet.

These seven individuals living in six different countries bring deep expertise in privacy, net neutrality, intellectual property, and digital inclusion. They will serve as a resource to the fellows as they pursue their individual projects and to Mozilla as we refine and institutionalize this program.

The fellows and advisors will gather next month at MozFest, Mozilla’s annual celebration of the Internet. They will collaborate on the fellows’ work and the fellows will lead sessions on tech policy topics during the weekend-long festival.

The advisors will also work with us to identify the next cohort of Tech Policy Fellows in early 2018 and will advise the program and the fellows for the coming two years. We look forward to bringing them on board and getting to work to continue advancing tech policy around the globe.

Meet the Tech Policy Fellowship Advisory Board:

Celina Beatriz

Celina Beatriz has a Master’s Degree in Human Rights from Harvard University and an Undergraduate Degree in Law from Pontifical Catholic University (PUC-Rio). She is an expert on human rights and technology. She was a researcher at Human Rights Watch in New York and a Supervisor at the Human Rights Clinic in Fundação Getulio Vargas (FGV Rio). Celina was a consultant for the Harvard Human Rights Clinic, a researcher at ISER, and an Associate of the Children’s and Adolescent’s Rights Protection in Rio de Janeiro. Celina is currently developing research in the human rights and technology field. She is Project Director at the Institute for Technology & Society of Rio de Janeiro (ITS Rio).

 

Malavika Jayaram

Malavika Jayaram is the Executive Director of Digital Asia Hub, an independent, non-profit Internet and society research think tank based in Hong Kong, incubated by The Berkman Klein Center for Internet and Society at Harvard University. A practising technology lawyer for over 15 years, she spent eight years in London with global law firm Allen & Overy in the Communications, Media & Technology group, and as Vice President and Technology Counsel at Citigroup. While a partner at Jayaram & Jayaram, India, she was featured in the International Who’s Who of Internet e-Commerce & Data Protection Lawyers, and voted one of India’s leading lawyers.

Malavika taught India’s first course on information technology and law in 1997, and is now Adjunct Faculty at Northwestern University’s Pritzker School of Law, part of the Master of Science in Law program bridging STEM subjects and law. She has been a Fellow with the Centre for Internet & Society, India, since 2009, when she helped start their privacy work. She is on the Advisory Board of the Electronic Privacy Information Center (EPIC), and the Executive Committee of the IEEE Global Initiative for Ethical Considerations in Artificial Intelligence and Autonomous Systems.

 

Ronaldo Lemos

Ronaldo Lemos is an internationally respected Brazilian scholar and commentator on technology, intellectual property, and culture. He is a director of the Institute for Technology & Society of Rio de Janeiro (ITS Rio) and professor of law and innovation at the Rio de Janeiro State University (UERJ). He holds law degrees from University of Sao Paulo Law School and Harvard Law and has published a number of books and journal articles. He is currently a Visiting Professor at Columbia University’s School of International and Public Affairs. He has served as the project lead of Creative Commons Brazil since 2003. He is a non-resident visiting scholar with the MIT Media Lab and was a visiting fellow at Princeton University’s Center for Information Technology Policy (CITP) in 2011 and 2012. Lemos is a founder of Overmundo, for which he received the Prix Ars Electronica Golden Nica in the category of digital communities. Lemos was one of the creators of the Marco Civil, a law enacted in 2014 regulating the Internet in Brazil, protecting civil rights, privacy, and net neutrality. In 2015 he was appointed a Young Global Leader by the World Economic Forum. In 2016 he was appointed a fellow with Ashoka. Lemos serves as a board member in various organizations, such as the Mozilla Foundation and Access Now.

 

Alexander Macgillivray

Alexander Macgillivray, also know as “amac,” is curious about many things including law, policy, government, decision making, the Internet, algorithms, social justice, access to information, and the intersection of all of those. He was United States Deputy Chief Technology Officer for the last two years of the Obama Administration. He was Twitter‘s General Counsel, and head of Corporate Development, Public Policy, Communications, and Trust & Safety. Before that he was Deputy General Counsel at Google and created the Product Counsel team. He has served on the board of the Campaign for the Female Education (CAMFED) USA, was one of the early Berkman Klein Center folks, was certified as a First Grade Teacher by the State of New Jersey, and studied Reasoning & Decision Making as an undergraduate. These days he is doing a bunch of coding, writing, and short burst projects with organizations thinking about what they should be doing next.

 

Bitange Ndemo

Bitange Ndemo is an Associate Professor of Entrepreneurship at the University of Nairobi’s Business School. His research centers on the link between ICTs and small and medium enterprises in Kenya, with an emphasis on how ICTs influence economic development in Kenya.   Prof. Ndemo is an advisor to several organizations including the Better than Cash Alliance, a global initiative under UNCDF dedicated to promotion of cash alternatives; and the I-Hub, a premier innovation hub in Africa. He also sits on the Board of Research ICT Africa based in South Africa. He is a former Permanent Secretary of Kenya’s Ministry of Information and Communication, where he was credited with facilitating many transformative ICT projects. After years of developing the supply-side of broadband, he has now changed gears to demand-side through assisting start-ups in Africa and playing a key role building sustainable models of innovation hubs. Prof. Ndemo holds a PhD in Industrial Economics from the University of Sheffield in the UK, a Bachelor’s degree in Finance from the University of Minnesota, and an MBA from University of St. Thomas. He is an open data and big data evangelist, and dedicated to simplification / visualization of data for ordinary citizens to consume.

 

Rinalia Abdul Rahim

Rinalia Abdul Rahim is Managing Director and Chairman of Compass Rose Sdn Bhd. She has 20 years of experience in international development and ICT policy, where she focuses on the issues of access, empowerment, and governance. She currently serves as a member of the Board of Directors at the Internet Corporation for Assigned Names and Numbers (ICANN). From 2001-2008, she was Executive Director of the Global Knowledge Partnership (GKP), which she successfully positioned as the world’s first and leading multi-stakeholder initiative that promoted knowledge and ICT for Development (ICT4D).

From 1997-2001 she worked with the Malaysian Government in developing national ICT policies, strategies and programmes. Some of the strategies and framework were promoted as best practices by the United Nations Development Programme and were adopted by many developing countries across Asia, Africa, and the Middle East. She has held various advisory positions with international, regional, and national bodies, including agencies of the United Nations. She holds a Master’s in Public Policy from Harvard University and a Bachelor’s Degree in Political Science from Princeton University. She is certified in Corporate Governance by INSEAD. Raised in Malaysia, she has lived in the U.S., Hong Kong, Mainland China, and Singapore. She currently resides in Germany.

 

Nicole Wong

Nicole Wong specializes in assisting high-growth technology companies to develop international privacy and regulatory strategies. She previously served as Deputy U.S. Chief Technology Officer in the Obama Administration, focused on internet, privacy, and innovation policy. Prior to her time in government, Nicole was Google’s Vice President and Deputy General Counsel, and Twitter’s Legal Director for Products. She frequently speaks on issues related to law and technology, including five appearances before the U.S. Congress.

Nicole chairs the board of Friends of Global Voices, a non-profit organization dedicated to supporting citizen and online media projects globally. She also sits on the boards of WITNESS, an organization supporting the use of video to advance human rights, and Mozilla. Nicole currently serves as an advisor to the School of Information at the University of California, Berkeley, Harvard Business School Digital Initiative, the Democratic National Committee Cybersecurity Advisory Board, Refactor Capital, and the Albright Stonebridge Group.

The post Adding More Policy Firepower to the Mozilla Network appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla GFX: WebRender newsletter #5

ma, 25/09/2017 - 18:41

Hi there, time for newsletter number five. An important detail went under the radar (and didn’t get featured in the newsletter whenever it happened): APZ (async panning and zooming) got enabled by default with WebRender. If you are one of the fearless nightly users who is trying WebRender out, please reset the preference layers.async-pan-zoom.enabled to its default value (true). So to recap, in order to experience the future of Firefox graphics in all of its work-in-progressness, go to about:config and:

  • turn on gfx.webrender.enabled
  • turn on gfx.webrendest.enabled
  • turn on gfx.webrender.layers-free
  • turn on gfx.webrender.blob-images
  • if you are on Linux, turn on layers.acceleration.force-enabled
  • if you had already followed the steps from newsletter #1, turn layers.async-pan-zoom.enabled back on.

Again, some key parts of the WebRender integration are still in a very rough shape. The performance (let alone stability) is still far from reflecting the targets of this project and I wouldn’t advise using this configuration by default yet.

I started a series of posts about WebRender on this blog. You can read part 1 which is an introductory post that doesn’t actually talk about WebRender at all. The post presents a high level overview of the architecture of current web browsers, in order to give some keys to understand the designs that will be explained in subsequent publications. The next post in this series will come in a few weeks.

Notable WebRender changes
  • Glenn fixed sub-pixel positioning of glyphs. Text now matches how it looks in Gecko on MacOS.
  • Lee implemented support for font variations in font instances.
  • Markus found, diagnosed and worked around a driver bug with the GLSL compiler on mac integrated GPUs.
  • The blur shader was rewritten (this hasn’t been hooked up to Gecko yet).
Notable Gecko changes
  • Kats turned layers-free on for transform and transform-3d reftests
  • Jeff has been investigating the overhead of the pile of clips that we currently have. See issues #1731 and #1742.
  • Nical reduced the overhead of transferring large resources from the content process to WebRender.

Categorieën: Mozilla-nl planet

Nick Cameron: How the RLS works

ma, 25/09/2017 - 05:53

The Rust Language Server (RLS) is an important part of the plan to provide IDE support for Rust developers. In this blog post I'll try to explain how the RLS works.

The language server architecture for IDEs is a client/server architecture. It separates the concerns of editing and understanding a program. By providing a language server, we provide Rust knowledge over a 'standardised' protocol (the LSP) to editors, thus allowing many editors to support Rust at the cost (theoretically) of supporting a single editor. The LSP does not mandate any particular method of compilation, nor are you restricted to the protocol (it is extensible, although the more you make use of extensions, the more per-client work there is to do). So an IDE based on the LSP can be just as powerful as a monolithic IDE, but it also let's you get up and running quickly across multiple platforms.

The RLS provides the data required for code completion, goto definition, type/docs on hover, refactoring, etc. See my earlier blog post, what the RLS can do for more details.

The best way to try out the RLS is in Visual Studio Code. You can install the extension by opening the command palette and typing ext install rust.

Language Server Protocol

The Language Server Protocol (LSP) is an open, JSON protocol. It specifies how the language server (e.g., the RLS) and client communicate. There is a spec, if you want more details (it's essential reading for working on the RLS).

The LSP is based on JSON-RPC, which basically means we're sending JSON over stdio. The JSON part is pretty nice, the stdio bit has pros and cons. It is nice and simple, but one stray println in the server somewhere (or a dependent crate) and everything blows up. The whole thing is pretty high level and you never have to worry about missing messages, out-of-order messages, etc.

A useful feature is that you can print to the client's console from the server by writing to stderr.

The protocol messages are either requests or notifications - the former has an id and must get a response, the latter has no id and cannot be responded to. Both kinds of messages can be sent in both directions, but the majority of messages are sent from the client to the server.

The messages in the LSP are pretty high level and leave a lot up to the server. You can expect a notification for any significant event on the client (such as opening or changing a file), and a request for most user actions which require language knowledge (e.g., 'goto definition' triggers a request, and it is the same request as triggered by 'peek definition').

Let's look at an example - the hover request. This is triggered when the user hovers their cursor over a token in the editor. The request looks like (in real life there would be less whitespace):

{ "jsonrpc": "2.0", "id": 3, "method": "textDocument/hover", "params": { "textDocument": { "uri": "file:///Users/nick/version-controlled/chefi/src/main.rs" }, "position": { "line": 110, "character": 25 } } }

Since this is a request, there is an id. method describes the type of the message, in this case textDocument/hover indicates that the user is hovering the cursor. The params give the file and location where the user is hovering.

(There is actually a little bit more boilerplate to indicate the size of the message).

The response in this case is:

{ "jsonrpc": "2.0", "id": 3, "result": { "contents": [{ "language": "rust", "value": "slog::Logger" }], "range": null } }

The id matches the request. The interesting bit here is the value field which is what actually gets displayed in the tool tip when the client hovers. There is an array for results/contents so that we can provide information from multiple sources.

RLS requirements

From the client's perspective, the most fundamental requirement for the RLS is that it must handle LSP messages, and it must do so quickly. For actions like hover or code completion, the user expects very little latency.

In order to fulfill this requirement, the RLS needs to process Rust programs to get knowledge of those programs, then manage that knowledge and make it available with low latency.

Due to the complexity of the Rust language and resource constraints, the RLS uses the Rust compiler to understand Rust programs. 'Processing Rust programs' then comes down to managing builds.

For other functions, the RLS depends on other tools - Rustfmt for formatting requests and Racer for code completion requests. A key factor which makes this interesting is that the project may be being edited in the client without being saved to disk, so the RLS must also manage changes to files which have not been written to disk and ensure that the compiler, Rustfmt, and Racer see the current state of the project.

RLS architecture

The architectural components of the RLS are roughly:

  • server module, handle the mechanics of being an LSP server (including handling setup and tear-down messages),
  • actions module, handle user actions,
  • build module, manage Cargo and rustc,
  • analysis crate, manage data about a program, as supplied by the compiler,
  • virtual file system (vfs) crate, manage the state of the project files.

There are also some supporting crates:

  • languageserver-types statically typed model of the LSP in Rust,
  • rls-data schema of the data about a program sent from the compiler to the RLS (and other clients, such as the new Rustdoc),
  • rls-span represent locations and ranges in the source code (this is surprisingly complicated and can give rise to a lot of subtle and annoying bugs).

To see how the above all fit together, let's go through a user scenario: the user is typing, then moves the cursor over an identifier to find the type. On every keystroke, the editor will send a textDocument/didChange notification to the RLS; since these are notifications, there are no replies. When the user puts the cursor over the identifier, the editor will send a textDocument/hover request, which the RLS will reply to (see above). The messages will be received in order by the RLS via stdin.

The server module listens to stdin, processes a message and its params, and forwards the message to the action module for handling. This all happens sequentially, the advantage of this is that we don't have to deal with out of order messages. The disadvantage is that an action can block the server indefinitely. Therefore, anything even remotely long-running should be done in its own thread.

The actions module is a collection of action handlers, plus some utility functions. The textDocument/didChange notifications are handled by the DidChange handler. The change is recorded in the VFS (virtual file system), and then the handler requests a build. Any build or long-running VFS action will spawn a new thread, so at this point the RLS is ready to process the next message on the main thread.

If the user is typing fast, then we'll end up with multiple build requests in a very short space of time. It does not make sense to start a build for each of these requests. The build module decides whether to start a build or not, and if it does start a build, it coordinates the building process. As we add support for workspaces, this is getting much more complex, but I'll stick to the single-crate story here.

A goal of the RLS is to finish a build as soon as possible so the user can get up to date information with low latency. However, we don't want to waste CPU time on builds that won't be useful, or burn through too much of the user's battery. Most of the time, information which is a few keystrokes out of date is fine. Therefore, we never do more than one build at a time. We also have no way to cancel a build. So, for most build requests, we wait a short time to see if we get a more up to date request before building. Thus, in this example we will only start a single build, once the user has finished typing.

On startup or if the user changes settings, the RLS does a 'cargo' build, otherwise (such as in the user scenario) the RLS does a 'rustc' build. For a 'cargo' build, the RLS runs Cargo in process, doing the equivalent of cargo check. Rather than calling rustc, we force Cargo to call our own compiler shim, which uses the compiler as a library but sets some options which would otherwise be unstable (the shim is actually the RLS with an env var set). For the primary crate, we intercept the call to rustc, record the arguments and env vars, and schedule a 'rustc' build.

A 'rustc' build compiles a crate by using rustc as a library compiled into the RLS. This lets us pass changed files from the VFS to rustc and to return data from rustc to the RLS, both without writing to disk.

For every crate, the RLS collects data about the compiler's analysis of the crate. For dependent crates we write and read this to/from disk (to avoid rebuilding where possible). For the primary crate, the data is passed in memory. The format of the data is specified by the rls-data and rls-span crates. The RLS passes the raw data to the rls-analysis crate which does some processing (e.g., cross-referencing definitions and references) and saves the data in memory (in a collection of hash tables).

When the RLS receives the textDocument/hover request, it does not wait for the build to complete. If necessary, it will use the existing data from a previous build. The Hover action must use the VFS to compute the correct position in the document, it can then look up information about a token in rls-analysis. This is usually very quick. The action handler produces a response, and the server module serialises the response and sends it to the editor via stdout.

Helping out

Let us know if you encounter any problems by filing issues on the RLS repo.

If you'd like to help by writing code, tests, or docs, then have a look at the repos for the RLS, our VSCode extension, or rustw. Or come ask questions on IRC in #rust-dev-tools or on Gitter.

Useful links:

Categorieën: Mozilla-nl planet

Cameron Kaiser: TenFourFox FPR3 available

ma, 25/09/2017 - 02:43
TenFourFox Feature Parity Release 3 is now available (downloads, hashes, release notes), after much delay due to Floodgap's gateway crapping its pants on Friday night. You'll be interested to know that it's a PowerPC too, by the way (a Motorola Freescale e300 series microcontroller, roughly equivalent to a 603e). There's a reason I have an SLA, which is to have a tech dispatched to Floodgap HQ in the dead of night to reflash the firmware which is specific to my ISP, but it also meant I spent Friday evening twiddling my thumbs instead of applying security patches. Sorry about that.

The fix for issue 72 did not stick, unfortunately, so I backed it out and replaced it with additional debugging code (thus, there is also a Debug version). Other than completing the rest of the relevant security updates, there are no other changes relative to the FPR3 beta. As usual expect this to go live tomorrow night sometime Pacific.

For FPR4, I have another large AltiVec upgrade in mind, and I would like to take a first pass at CSS Grid support and maybe also WOFF2 updates. In addition, because of the impending release of Firefox 57 "Judgment Day for XUL" this will be the first release of TenFourFox to have the "Get Add-ons" tab removed, since the Mozilla-specific pages will be hawking WebExtensions. You can still install old-style XUL addons compatible with the underlying Gecko 45 infrastructure; they'll just be something you have to separately download from AMO or whatever. While I might reintroduce this tab in the future, right now I don't have enough time to maintain a full-service legacy add-on site myself. However, if this is something Someone(tm) wants to work on and they can meet the technical requirements (and make a commitment to hosting it for an indefinite period), we can talk about it and see if you're the right fit for our community. Open a ticket on Github if you're that person.

Categorieën: Mozilla-nl planet

Pagina's