Mozilla GFX: WebRender newsletter #20 |
Newsletter number twenty is here, delayed again by a combination of days off and the bi-annual Mozilla AllHands which took place last week in San Francisco.
A big highlight in the WebRender side is the work on porting all primitives to the brush system approaching completion. Individually, porting each primitive doesn’t sound like much but with all of the pieces coming together:
This translates into noticeable performance imporvements on a lot of very complex pages. The most outstanding remaining performance issues are now caused by the CPU fallback which we are working on moving off of the critical path, so things are looking very promiscing especially with the mountain of other performance improvements we are currently holding off on to concentrate on correctness.
Speaking of fixing correctness issues, as usual we can see from the lists below that there is also a lot of progress in this area.
In about:config, just set “gfx.webrender.all” to true and restart the browser. No need to toggle any other pref.
The best place to report bugs related to WebRender in Gecko is the Graphics :: WebRender component in bugzilla.
Note that it is possible to log in with a github account.
https://mozillagfx.wordpress.com/2018/06/19/webrender-newsletter-20/
|
|
Nicholas Nethercote: San Francisco Oxidation meeting notes |
At last week’s Mozilla All Hands meeting in San Francisco we had an Oxidation meeting about the use of Rust in Firefox. It was low-key, being mostly about status and progress. The notes are here for those who are interested.
https://blog.mozilla.org/nnethercote/2018/06/19/san-francisco-oxidation-meeting-notes/
|
|
Firefox UX: Written by Amy Lee & Eric Pang |
Written by Amy Lee & Eric Pang
Motion may sometimes feel like an afterthought or worse yet “polish”. For the release of Firefox Quantum (one of our most significant releases to date), we wanted to ensure that motion was not a second class citizen and that it would play an important role in how users perceived performance in the browser.
We (Amy & Eric) make up the UX side of the “motion team” for Firefox. We say this in air quotes because the motion team was essentially formed based on our shared belief that motion design is important in Firefox. With a major release planned, we thought this would be the perfect opportunity to have a team working on motion.
We made a sticker and started calling ourselves the motion team.
The next plan of action was to audit the existing motions in Firefox across mobile and desktop. We documented them by taking screen recordings and highlighted the areas that needed the most attention.
From this exercise it was clear that consistency and perceived performance were high on our list of improvements.
The next step was to gather inspiration for a mood board. From there, we formed a story that would become the foundation of our motion design language.
During this process, we asked ourselves:
How can we make the browser feel smoother, faster and more responsive?.
With Photon (Firefox’s new design language) stemming from Quantum we knew there was going to be an emphasis on speed in our story. Before starting work on any new motions, we created a motion curve to reflect this. The aim was to have a curve that would be perceived as fast yet still felt smooth and natural when applied to tabs and menu items. Motion should also be informative (i.e showing where your bookmarked item is saved, when your tab is done loading) and lastly, have personality. We defined our story based on these considerations.
The motion story was presented to the rest of the UX team during a work week held in Toronto (the UX team is distributed across several countries so work weeks are planned for in-person collaboration).
This was our mission statement:
The motion design language in Firefox Quantum is defined by three principles: Quick, Informative and Whimsical. Following these guiding principles, we aim to achieve a cohesive, consistent, and enjoyable experience within the family of Firefox browsers.
Next we presented some preliminary concepts to support these principles:
Animations should be fast and nimble and never keep the user waiting longer than they need to. The aim is to prioritize user perceived performance over technical benchmarks.
Motion should help ease the user through the experience. It should aid the flow of actions, giving clear guidance for user orientation: spatial or temporal.
Even though most people would not associate whimsy with a browser, we wanted to incorporate some playful elements as part of Firefox’s personality (and maybe ourselves).
After getting feedback and buy-in from the rest of the UX team on the motion story, we were able to start working with them in applying motion to their designs.
The Photon project was divided across various functional teams all focusing on different design aspects of Firefox. With motion overlapping many of these teams we started opening communication channels with each that would directly impact our work. We worked especially close with the visual/interaction team since it didn’t make sense to start motion design on components that were not yet close to complete. We had regular check-ins to set a rough ordering/priority of when we would schedule motion work of specific components.
Once we had near final visuals/interactions, it was time to get into After Effects and start animating!
https://medium.com/media/f099215e9a6dea67eec0d1a6e4ee729b/hrefImplementing animations, especially detailed ones such as bookmarking and downloading, was an interesting challenge for the development team (Jared Wein, Sam Foster, and Jim Porter).
Rather than have a developer try to reproduce our motion designs through code, which can become tedious, we wanted to be able to export the motion directly. This ensured that the nuances of the motion was not lost during implementation.
To have the animations performant in the browser, the file sizes also needed to be small. This was done by using SVG assets and CSS animations.
We explored existing tools but did not find anything suitable that would be compatible with the browser. We created our own process and designed the animations in After Effects and used the Bodymovin extension to export them as JSON files.
One developer in particular, Markus Stange made this method possible by writing a tool, to convert JSON files into SVG sprite sheets. Sam further refined the tool and it became an essential asset in translating timeline animations from After Effects into CSS animations.
After rounds of asset production, refinements, reviews, and testing, the big day came with the launch of Firefox Quantum!
We were a bit anxious awaiting feedback since this was the most significant update since Firefox 1.0 first launched in 2004.
Thankfully the release was met with positive reviews. We were happy that even some of our motions got a kudos.
So that wraps up the story of how the “motion team” for Firefox came to be. But that’s not all we do here at Mozilla. These days you’ll also find Eric busy working away at UX for Web Payments, Privacy and Search, while Amy casts her Dark theme magic and spins out the next UX iteration of Activity Stream and Onboarding.
If you haven’t given Firefox Quantum a try, take it for a spin and let us know what you think.
Written by Amy Lee & Eric Pang was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story.
|
|
Air Mozilla: Creative Media Awards Webinar |
This is an informational webinar for a global public audience interested in learning more about Mozilla's Creative Media Awards track. This event is being streamed...
|
|
About:Community: Firefox 61 new contributors |
With the upcoming release of Firefox 61, we are pleased to welcome the 59 developers who contributed their first code change to Firefox in this release, 53 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:
https://blog.mozilla.org/community/2018/06/18/firefox-61-new-contributors/
|
|
QMO: Firefox 61 Beta 14 Testday Results |
Hello Mozillians!
As you may already know, last Friday – June 15th – we held a new Testday event, for Firefox 61 Beta 14.
Thank you all for helping us make Mozilla a better place!
From India team: Aishwarya Narasimhan, Mohamed Bawas, Surentharan, amirthavenkat, Monisha Ravi
Results:
– several test cases executed for Fluent Migration of Preferences, Accessibility Inspector: Developer Tools and Web Compatibility.
Thanks for another successful testday
https://quality.mozilla.org/2018/06/firefox-61-beta-14-testday-results/
|
|
Tarek Ziad'e: IOActivityMonitor in Gecko |
This is a first blog post of a series on Gecko, since I am doing a lot of C++ work in Firefox these days. My current focus is on adding tools in Firefox to try to detect what's going on when something goes rogue in the browser and starts to drain your battery life.
We have many ideas on how to do this at the developer/user level, but in order to do it properly, we need to have accurate ways to measure what's going on when the browser runs.
One thing is I/O activity.
For instance, a WebExtension worker that performs a lot of disk writes is something we want to find out about, and we had nothing to track all I/O activities in Firefox, without running the profiler.
When Firefox OS was developed, a small feature was added in the Gecko network lib, called NetworkActivityMonitor.
That class was hooked as an NSPR layer to send notifications whenever something was sent or received on a socket, and was used to blink the small icon phones usually have to signal that something is being transferred.
After the Firefox OS project was discontinued in Gecko, that class was left in the Gecko tree but not used anymore, even though the option was still there.
Since I needed a way to track all I/O activity (sockets and files), I have refactored that class into a generalised version that can be used to get notified every time data is sent or received in any file or socket.
The way it works is pretty simple: when a file or a socket is created, a new NSPR layer is added so every read or write is recorded and eventually dumped into an XPCOM array that is notified via a timer.
This design makes it possible to track along sockets, any disk file that is accessed by Firefox. For SQLite databases, since there's no way to get all FD handles (theses are kept internal to the sqlite lib), the IOActivityMonitor class provides manual methods to notify when a read or a write happens. And our custom SQLite wrapper in Firefox allowed me to add calls like I would do in NSPR.
It’s landed in Nightly :
And you can see how to use it in its Mochitest
|
|
Cameron Kaiser: TenFourFox FPR8b1 available |
That's not to say this is strictly a security patch release (though most of the patches for the final Firefox 52, 52.9, are in this beta). The big feature I did want to get in FPR8 did land and seems to work properly, which is same-site cookie support. Same-site cookie support helps to reduce cross-site request forgeries by advising the browser the cookie in question should only be sent if a request originates from the site that set it. If the host that triggered the request is different than the one appearing in the address bar, the request won't include any of the cookies that are tagged as same-site. For example, say you're logged into your bank, and somehow you end up opening another tab with a malicious site that knows how to manipulate your bank's transfer money function by automatically submitting a hidden POST form. Since you're logged into your bank, unless your bank has CSRF mitigations (and it had better!), the malicious site could impersonate you since the browser will faithfully send your login cookie along with the form. The credential never leaked, so the browser technically didn't malfunction, but the malicious site was still able to impersonate you and steal your money. With same-site cookies, there is a list of declared "safe" operations; POST forms and certain other functions are not on that list and are considered "unsafe." Since the unsafe action didn't originate from the site that set the cookie, the cookie isn't transmitted to your bank, authentication fails and the attack is foiled. If the mode is set to "strict" (as opposed to "lax"), even a "safe" action like clicking a link from an outside site won't send the cookie.
Same-site cookie support was implemented for Firefox 60; our implementation is based on it and should support all the same features. When you start FPR8b1, your cookies database will be transparently upgraded to the new database schema. If you are currently logged into a site that supports same-site cookies, or you are using a foxbox that preserves cookie data, you will need to log out and log back in to ensure your login cookie is upgraded (I just deleted all my cookies and started fresh, which is good to give the web trackers a heart attack anyway). Github and Bugzilla already have support, and I expect to see banks and other high-security sites follow suit. To see if a cookie on a site is same-site, make sure the Storage Inspector is enabled in Developer tools, then go to the Storage tab in the Developer tools on the site of interest and look at the Cookies database. The same-site mode (unset, lax or strict) should be shown as the final column.
FPR8 goes live on June 25th.
http://tenfourfox.blogspot.com/2018/06/tenfourfox-fpr8b1-available.html
|
|
Dustin J. Mitchell: Actions as Hooks |
You may already be familiar with in-tree actions: they allow you to do things like retrigger, backfill, and cancel Firefox-related tasks
They implement any “action” on a push that occurs after the initial hg push operation.
This article goes into a bit of detail about how this works, and a major change we’re making to that implementation.
Until very recently, actions worked like this:
First, the decision task (the task that runs in response to a push and decides what builds, tests, etc. to run) creates an artifact called actions.json.
This artifact contains the list of supported actions and some templates for tasks to implement those actions.
When you click an action button (in Treeherder or the Taskcluster tools, or any UI implementing the actions spec), code running in the browser renders that template and uses it to create a task, using your Taskcluster credentials.
I talk a lot about functionality being in-tree. Actions are yet another example. Actions are defined in-tree, using some pretty straightforward Python code. That means any engineer who wants to change or add an action can do so – no need to ask permission, no need to rely on another engineer’s attention (aside from review, of course).
Since the beginning, Taskcluster has operated on a fairly simple model: if you can accomplish something by pushing to a repository, then you can accomplish the same directly. At Mozilla, the core source-code security model is the SCM level: try-like repositories are at level 1, project (twice) repositories at level 2, and release-train repositories (autoland, central, beta, etc.) are at level 3. Similarly, LDAP users may have permisison to push to level 1, 2, or 3 repositories. The current configuration of Taskcluster assigns the same scopes to users at a particular level as it does to repositories.
If you have such permission, check out your scopes in the Taskcluster credentials tool (after signing in). You’ll see a lot of scopes there.
The Release Engineering team has made release promotion an action. This is not something that every user who can push to level-3 repository – hundreds of people – should be able to do! Since it involves signing releases, this means that every user who can push to a level-3 repository has scopes involved in signing a Firefox release. It’s not quite as bad as it seems: there are lots of additional safeguards in place, not least of which is the “Chain of Trust” that cryptographically verifies the origin of artifacts before signing.
All the same, this is something we (and the Firefox operations security team) would like to fix.
In the new model, users will not have the same scopes as the repositories they can push to. Instead, they will have scopes to trigger specific actions on task-graphs at specific levels. Some of those scopes will be available to everyone at that level, while others will be available only to more limited groups. For example, release promotion would be available to the Release Management team.
This makes actions a kind of privilege escalation: something a particular user can cause to occur, but could not do themselves.
The Taskcluster-Hooks service provides just this sort of functionality:
a hook creates a task using scopes assiged by a role, without requiring the user calling triggerHook to have those scopes.
The user must merely have the appropriate hooks:trigger-hook:.. scope.
So, we have added a “hook” kind to the action spec.
The difference from the original “task” kind is that actions.json specifies a hook to execute, along with well-defined inputs to that hook.
The user invoking the action must have the hooks:trigger-hook:.. scope for the indicated hook.
We have also included some protection against clickjacking, preventing someone with permission to execute a hook being tricked into executing one maliciously.
There are three things we may wish to vary for an action:
Most of these are configured within the hooks service (using automation, of course). If every action is configured uniquely within the hooks service, then the self-service nature of actions would be lost: any new action would require assistance from someone with permission to modify hooks.
As a compromise, we noted that most actions should be available to everyone who can push to the corresponding repo, have fairly limited scopes, and need not limit their inputs. We call these “generic” actions, and creating a new such action is self-serve. All other actions require some kind of external configuration: allocating the scope to trigger the task, assigning additional scopes to the hook, or declaring an input schema for the hook.
The hook definition for an action hook is quite complex: it involves a complex task definition template as well as a large schema for the input to triggerHook.
For decision tasks, cron tasks, an “old” actions, this is defined in .taskcluster.yml, and we wanted to continue that with hook-based actions.
But this creates a potential issue: if a push changes .taskcluster.yml, that push will not automatically update the hooks – such an update requires elevated privileges and must be done by someone who can sanity-check the operation.
To solve this, ci-admin creates tasks hooksed on the .taskcluster.yml it finds in any Firefox repository, naming each after a hash of the file’s content.
Thus, once a change is introduced, it can “ride the trains”, using the same hash in each repository.
As of this writing, two common actions are operating as hooks: retrigger and backfill. Both are “generic” actions, so the next step is to start to implement some actions that are not generic. Ideally, nobody notices anything here: it is merely an implementation change.
Once all actions have been converted to hooks, we will begin removing scopes from users. This will have a more significant impact: lots of activities such as manually creating tasks (including edit-and-create) will no longer be allowed. We will try to balance the security issues against user convenience here. Some common activities may be implemented as actions (such as creating loaners). Others may be allowed as exceptions (for example, creating test tasks). But some existing workflows may need to change to accomodate this improvement.
We hope to finish the conversion process in July 2018, with that time largely taken with a slow rollout to accomodate unforseen implications. When the project is finished, Firefox releases and other sensitive operations will be better-protected, with minimal impact to developers’ existing worflows.
|
|
Byron Jones: in-tree annotations of third-party code (moz.yaml) |
I've recently landed changes on mozilla-central to provide initial support for in-tree annotations of third-party code. (Bug 1454868, D1208, r5df5e745ce6e).
moz.yaml
from the top of moz_yaml.pl create a moz.yaml in the top level of third-party codemach vendor manifest --verify path/to/moz.yamlmoz.yaml files in-tree (help here is appreciated!)moz.yaml files remain validmoz.yaml TemplateFrom python/mozbuild/mozbuild/moz_yaml.py#l50
---
# Third-Party Library Template
# All fields are mandatory unless otherwise noted
# Version of this schema
schema: 1
bugzilla:
# Bugzilla product and component for this directory and subdirectories
product: product name
component: component name
# Document the source of externally hosted code
origin:
# Short name of the package/library
name: name of the package
description: short (one line) description
# Full URL for the package's homepage/etc
# Usually different from repository url
url: package's homepage url
# Human-readable identifier for this version/release
# Generally "version NNN", "tag SSS", "bookmark SSS"
release: identifier
# The package's license, where possible using the mnemonic from
# https://spdx.org/licenses/
# Multiple licenses can be specified (as a YAML list)
# A "LICENSE" file must exist containing the full license text
license: MPL-2.0
# Configuration for the automated vendoring system.
# Files are always vendored into a directory structure that matches the source
# repository, into the same directory as the moz.yaml file
# optional
vendoring:
# Repository URL to vendor from
# eg. https://github.com/kinetiknz/nestegg.git
# Any repository host can be specified here, however initially we'll only
# support automated vendoring from selected sources initiall.
url: source url (generally repository clone url)
# Revision to pull in
# Must be a long or short commit SHA (long preferred)
revision: sha
# List of patch files to apply after vendoring. Applied in the order
# specified, and alphabetically if globbing is used. Patches must apply
# cleanly before changes are pushed
# All patch files are implicitly added to the keep file list.
# optional
patches:
- file
- path/to/file
- path/*.patch
# List of files that are not deleted while vendoring
# Implicitly contains "moz.yaml", any files referenced as patches
# optional
keep:
- file
- path/to/file
- another/path
- *.mozilla
# Files/paths that will not be vendored from source repository
# Implicitly contains ".git", and ".gitignore"
# optional
exclude:
- file
- path/to/file
- another/path
- docs
- src/*.test
# Files/paths that will always be vendored, even if they would
# otherwise be excluded by "exclude".
# optional
include:
- file
- path/to/file
- another/path
- docs/LICENSE.*
# If neither "exclude" or "include" are set, all files will be vendored
# Files/paths in "include" will always be vendored, even if excluded
# eg. excluding "docs/" then including "docs/LICENSE" will vendor just the
# LICENSE file from the docs directory
# All three file/path parameters ("keep", "exclude", and "include") support
# filenames, directory names, and globs/wildcards.
# In-tree scripts to be executed after vendoring but before pushing.
# optional
run_after:
- script
- another script
|
|
Daniel Pocock: The questions you really want FSFE to answer |
As the last man standing as a fellowship representative in FSFE, I propose to give a report at the community meeting at RMLL.
I'm keen to get feedback from the wider community as well, including former fellows, volunteers and anybody else who has come into contact with FSFE.
It is important for me to understand the topics you want me to cover as so many things have happened in free software and in FSFE in recent times.
Some of the things people already asked me about:
What are the issues you would like me to address? Please feel free to email me privately or publicly. If I don't have answers immediately I would seek to get them for you as I prepare my report. Without your support and feedback, I don't have a mandate to pursue these issues on your behalf so if you have any concerns, please reply.
Your fellowship representative
https://danielpocock.com/the-questions-you-really-want-fsfe-to-answer
|
|
Niko Matsakis: MIR-based borrow check (NLL) status update |
|
|
Nick Cameron: What do you think are the most interesting/exciting projects using Rust? |
Last week I tweeted "What do you think are the most interesting/exciting projects using Rust? (No self-promotion :-) )". The response was awesome! Jonathan Turner suggested I write up the responses as a blog post, and here we are.
I'm just going to list the suggestions, crediting is difficult because often multiple people suggested the same projects, follow the Twitter thread if you're interested:
|
|
The Mozilla Blog: WITHIN creates distribution platform using WebVR |
Virtual Reality (VR) content has arrived on the web, with help from the WebVR API. It’s a huge inflection point for a medium that has struggled for decades to reach a wide audience. Now, anyone with access to an internet-enabled computer or smartphone can enjoy VR experiences, no headset required. A good place to start? WITHIN’s freshly launched VR website.
From gamers to filmmakers, VR is the bleeding edge of self-expression for the next generation. It gives content creators the opportunity to tell stories in new ways, using audience participation, parallel narratives, and social interaction in ever-changing virtual spaces. With its immersive, 360-degree audio and visuals, VR has outsized power to activate our emotions and to put us in the center of the action.
WITHIN is at the forefront of this shift toward interactive filmmaking and storytelling. The company was one of the first to launch a VR distribution platform that showcases best-in-class VR content with high production values.
“Film is this incredible medium. It allows us to feel empathy for people that are very different from us, in worlds completely foreign to our own,” said Chris Milk, co-founder of WITHIN, in a Ted Talk. “I started thinking, is there a way I could use modern and developing technologies to tell stories in different ways, and tell different kinds of stories that maybe I couldn’t tell using the traditional tools of filmmaking that we’ve been using for 100 years?”
WITHIN’s approach is to bring curated and original VR experiences directly to viewers for free, rather than trying to gain visibility for their content through existing channels. Until now, VR content was mostly presented to headset users via the manufacturer’s store websites. So if you shelled out hundreds of dollars for an Oculus Rift or HTC Vive, you would see a library of content when you fired up your rig.
With its new site, WITHIN is making VR content accessible to everyone, whether they’re watching on a laptop, mobile phone, or headset. The company produces immersive VR experiences with high-profile partners like the band OK Go and Tyler Hurd. It also distributes top-tier VR experiences, like family-friendly animation and nature shows, with 360-degree visuals and stereoscopic sound.
“We aim to make it as easy as possible for fans to discover and share truly great VR experiences,” said Jon Rittenberg, Content Launch Manager at WITHIN.
The key to reaching a vast potential audience of newcomers is to make a platform that is simple to use and easy to explore. Most importantly, it should work without exposing visitors to technical hurdles. That’s a challenge for two reasons.
First, the web is famously democratic. Companies like WITHIN have no control over who comes to their site, what device they’re on, what operating system that device runs, or how much bandwidth they have. Second, the web is still immature as a VR platform, with a growing but limited number of tools.
To build a platform that ‘just works’, the engineers at WITHIN turned to the WebVR API. Mozilla engineers built the foundation for the WebVR API with a goal to give companies like WITHIN a simpler way to support a range of viewing options without having to rewrite their code for each platform. WebVR provides support for exposing VR devices and headsets to web apps, enabling developers to translate position and movement information from the display into movement around a 3D scene.
Using the WebVR specification, the company built its WITHIN WebVR site so it could adapt to dozens of factors and give new viewers a consistently great experience. In an amazing proof-of-concept for VR on the web, the company was able to optimize each streaming experience to a wide range of platforms and displays, like Vive, Rift, PSVR, iOS, Android, GearVR, and Oculus Go.
“The API really helped us out. It gave us all the pieces we needed,” said Jono Brandel, Lead Designer at WITHIN. “Without the WebVR API, we could not have done any of this stuff in the browser. We wouldn’t have access to VR headsets.”
The WITHIN WebVR site does a fantastic job of adapting its VR content to a range of devices. The site can identify a visitor’s device and push content suited for that device, making it easy on the end user. The majority of visitors to WITHIN’s VR site arrive on a Cardboard device that works with their smartphone. That delivers a basic experience: 3D stereoscopic visuals with some gyroscopic controls.
Headset users get the same content with higher resolution visuals and binaural audio, which brings life-like sound effects to VR experiences. The VR content can also adapt to different head and hand tracking inputs, and supports common navigational tools in popular headsets. Folks visiting via a browser can view VR content just as they would play a 3D, interactive game or watch a 360-degree video online.
To get this level of adaptive support took quite a bit of work behind the scenes. “We have a room filled with a ton of devices: smartphones, computers, and operating systems. We’ve got everything,” Brandel said. “It’s really cool that one code base supports all of these platforms.”
The web is a great platform for creating and experiencing VR. It’s easy to share content broadly, across continents and cultures. And it’s simple to get started building 3D experiences using free tools like A-Frame, invented by Mozilla engineers with help from a talented and dedicated open source community.
“We’re excited to see such big platforms making a bet on WebVR,” said Lars Bergstrom, Director of Mixed Reality at Mozilla. “As new devices reach more people, we expect the WebVR specification will continue to grow and evolve.”
Mozilla and WITHIN are also collaborating to make the open web platform even better for VR distribution. The two companies are working together on a series of experiments to make WebVR versions of popular players as capable as native applications, using tech standards WebGL and WebAssembly.
The goal is to make it simpler for content creators to push their stories and games to the web, without having to do a lot of coding work. The two companies are exploring how to use Unity’s popular gaming platform to streamline the publication to the web, while still delivering performance, stability, and scale for immersive experiences.
“The Unity ecosystem is already mature – and it’s where the designers and developers are focused,” said Christopher Van Wiemeersch, Senior UX Web Engineer at Mozilla. “We’re hoping that WebAssembly and the Unity-WebVR Exporter can help us use the web as a distribution platform and not only as a content-creation platform. You’re using JavaScript under the hood, but you don’t have to learn it yourself.”
Earlier this year, Mozilla released Unity WebVR Assets, a tool that aims to reduce complexity for content authors by letting them export content from the Unity platform and have the experiences work on the web. You can check it out in the Unity Asset Store.
If you’re a filmmaker interested in getting your VR experience on the WITHIN platform, you can submit your project here for consideration.
The post WITHIN creates distribution platform using WebVR appeared first on The Mozilla Blog.
|
|
Daniel Stenberg: curl survey 2018 analysis |
This year, 670 individuals spent some of their valuable time on our survey and filled in answers that help us guide what to do next. What's good, what's bad, what to remove and where to emphasize efforts more.
It's taken me a good while to write up this analysis but hopefully the results here can be used all through the year as a reminder what people actually think and how they use curl and libcurl.
A new question this yeas was in which continent the respondent lives, which ended up with an unexpectedly strong Euro focus:
What didn't trigger any surprises though was the question of what protocols users are using, which basically identically mirrored previous years' surveys. HTTP and HTTPS are the king duo by far.
Read the full 34 page analysis PDF.
Some other interesting take-aways:
https://daniel.haxx.se/blog/2018/06/12/curl-survey-2018-analysis/
|
|
The Mozilla Blog: Level Up with New Productivity Features in Firefox for iOS |
Today, we’re announcing new features in Firefox for iOS to make your life easier. Whether you’re a multi-tasker or someone who doesn’t want to waste time, we’re rolling out new features to up your productivity game.
For those times when you need to leave the office but want to read that file during your commute or at a later time, we now provide support for downloading files to your mobile devices. First download them to your device, then access and share it in the main menu where you’ll find a folder with all your downloads.
Easy to download
A folder with your downloads
Did you ever come across an article that catches your eye but don’t have time to read it right away? We’ve added a one-stop menu to give you choices on what to do with the link. You can open it directly in Firefox, add it to your bookmark or reading list to peruse at your convenience, or send it to another device that’s linked to your Firefox account.
A one-stop menu with choices
You’ll get the answer quickly now that we’ve made it easier to see whether your mobile device is connected to all your devices where you use Firefox. Click on the menu button listed prominently at the top of the application menu. From there, you’ll see if you’re synced, and if you aren’t you’ll have the option to do so. If you don’t have a Firefox Account, you can sign up directly here.
From the top of the app menu you’ll see if you’re synced or not
Firefox continues to bring convenience to iOS users. To get the latest version of Firefox for iOS, visit the App Store.
The post Level Up with New Productivity Features in Firefox for iOS appeared first on The Mozilla Blog.
https://blog.mozilla.org/blog/2018/06/12/level-up-with-new-productivity-features-in-firefox-for-ios/
|
|
This Week In Rust: This Week in Rust 238 |
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.
Box, &Trait, impl Trait, and dyn Trait.This week's crate is clap-verbosity-flag, a small crate to easily add a verbosity setting to Rust command line applications. Thanks to Yoshuawuyts for the suggestion!
Submit your suggestions and votes for next week!
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.
110 pull requests were merged in the last week
+= into + and = where + is explicitly requested (such as generics)#[cfg] and #[cfg_attr] on generic parametersnearest_common_ancestorpending_obligationsmacro_exports.. in incorrect position to avoid further errors#[panic_implementation]ScalarPairs are offset==0 field + other non-zst fieldfmt::Alignment into stdFuture and task system to the standard librarystdIterator::step_byiterator_repeat_withentry-or-default() return typeChanges to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
No RFCs were approved this week.
Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
throw and fail as keywords in edition 2018.std::path::Path::ancestors.ToOwned::clone_into (toowned_clone_into).! to a type (RFC 1216).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.
Tweet us at @ThisWeekInRust to get your job offers listed here!
explicit lifetimes no longer scare me the way they used to.
– Nicholas Nethercote on his blog
(selected by llogiq per one unanimous vote)
Please submit your quotes for next week!
This Week in Rust is edited by: nasa42 and llogiq.
https://this-week-in-rust.org/blog/2018/06/12/this-week-in-rust-238/
|
|
The Mozilla Blog: Our past work with Facebook |
Over the last three months, Mozilla has been a vocal critic of Facebook’s practices with respect to its lack of user transparency. Throughout this time we’ve engaged with Facebook directly about this and have continued to comment publicly as the story about Facebook’s data practices evolves.
Mozilla Corporation recently received two termination notices from Facebook about work that we did with them in the past. These appear to be part of Facebook’s broader effort to clean up its third-party developer ecosystem. This is good – we suspect that we weren’t the only ones receiving these notices. Still, the notices, and recent reporting of Facebook data sharing with device makers, prompted us to take a closer look at our past relationships with the company and we think it is important to talk about what we found.
At a high level we found that Mozilla Corporation had two agreements with Facebook initiated in 2012 and 2013 respectively. No information from Facebook was transferred to Mozilla Corporation in either situation but there were permissions granted to Mozilla Corporation in the agreements with respect to user data. In fact, in one case, our engineers noticed the overly broad access and requested that Facebook limit it. Here are some additional details:
In 2012, Mozilla Corporation had an agreement with Facebook that was intended to make it easier for individuals using Facebook through the Firefox browser to interface with the Facebook application. The relationship was part of our work on the Social API, an effort to integrate social experiences more seamlessly into the browser. As part of that agreement, Facebook was able to display web pages, including users’ data appearing on those pages, in specialized locations in the Firefox browser. This means that data was sent directly to the browser client, and none of the users’ Facebook information was shared with Mozilla Corporation. You can find more publicly available information about this integration here.
The 2013 agreement related to our now-defunct mobile operating system, Firefox OS. When users began using a Firefox OS device, they were given the explicit option of importing their Facebook contacts onto that device. Again, none of the users’ Facebook information was shared with Mozilla. When users disconnected their Facebook account, they were given the option of removing their Facebook data from the device. You can see in our public bug tracker that our team actually asked Facebook to remove some data access permissions because “we shouldn’t request permissions we don’t need.”
While these agreements have remained in effect, the work on these projects had already ended. We finished deprecating the Social API in 2017. Mozilla stopped development of Firefox OS in 2015, although any Firefox OS devices still in use today may retain access until Facebook shuts down that access in accordance with their termination notice.
We are bringing this to your attention because we want to be clear that our products technically had access to Facebook’s APIs and because we want to explain what was done with that access. We encourage other companies to review their relationships with Facebook and to be transparent about what those involved. That level of transparency is what is needed today to build a healthier, more trustworthy Internet that puts users first.
The post Our past work with Facebook appeared first on The Mozilla Blog.
https://blog.mozilla.org/blog/2018/06/11/our-past-work-with-facebook/
|
|
Gervase Markham: Mozilla All Hands |
Today, from across the world, Mozillians are gathering in San Francisco for our six-monthly All Hands. For obvious reasons, I won’t be able to be there, so I want to wish all the best to everyone, and I am confident that more awesome ideas for rocking the free web will emerge from their deliberations. Each year brings different grey clouds to the sky, and requires us to adjust our strategy and tactics to deal with new threats. Some we win and a few we lose, but it’s clear that the world and the web are much better places with Mozilla in them fighting for what is right.
http://feedproxy.google.com/~r/HackingForChrist/~3/2w52hc1X-NQ/
|
|
Robert O'Callahan: Bay Area Visit |
I'm on my way to San Francisco for a guest visit to the Mozilla All Hands ... thanks, Mozilla!
After that, I'll be taking a break for a few days and going hiking with some friends. Then I'll spending a week or so visiting more people to talk about rr and Pernosco. Looking forward to all of it!
|
|