mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Andrew Halberstadt: Try Fuzzy: A Try Syntax Alternative

Mozilla planet - wo, 02/08/2017 - 15:50

It's no secret that I'm not a fan of try syntax, it's a topic I've blogged about on several occasions before. Today, I'm pleased to announce that there's a real alternative now landed on mozilla-central. It works on all platforms with mercurial and git. For those who just like to dive in:

bash $ mach mercurial-setup --update # only if using hg $ mach try fuzzy

This will prompt you to install fzf. After bootstrapping is finished, you'll enter an interface populated with a list of all possible taskcluster tasks. Start typing and the list will be filtered down using a fuzzy matching algorithm. I won't go into details on how to use this tool in this blog post, for that see:

bash $ mach try fuzzy --help # or $ man fzf

For who prefer to look before you leap, I've recorded a demo:

<video width="100%" height="100%" controls> <source src="/static/vid/blog/2017/mach-fuzzy.mp4" type="video/mp4"> </video>

Like the existing mach try command, this should work with mercurial via the push-to-try extension or git via git-cinnabar. If you encounter any problems or bad UX, please file a bug under Testing :: General.

Try Task Config

The following section is all about the implementation details, so if you're curious or want to write your own tools for selecting tasks on try, read on!

This new try selector is not based on try syntax. Instead it's using a brand new scheduling mechanism called try task config. Instead of encoding scheduling information in the commit message, mach try fuzzy encodes it in a JSON file at the root of the tree called try_task_config.json. Very simply (for now), the decision task knows to look for that file on try. If found, it will read the JSON object and schedule every task label it finds. There are also hooks to prevent this file from accidentally being landed on non-try branches.

What this means is that anything that can generate a list (or dict) of task labels can be a try selector. This new JSON format is much easier for tools to write, and for taskgraph to read.

Creating a Try Selector

There are currently two ways to schedule tasks on try (syntax and fuzzy). But I envision 4-5 different methods in the future. For example, we might implement a TestResolver based try selector which given a path can determine all affected jobs. Or there could be one that uses globbing/regex to filter down the task list which would be useful for saving "presets". Or there could be one that uses a curses UI like the hg trychooser extension.

To manage all this, each try selector is implemented as an @SubCommand of mach try. The regular syntax selector, is implemented under mach try syntax now (though mach try without any subcommand will dispatch to syntax to maintain backwards compatibility). All this lives in a newly created tryselect module.

If you have want to create a new try selector, you'll need two things:

  1. A list of task labels as input.
  2. The ability to write those labels to try_task_config.json and push it to try.

Luckily tryselect provides both those things. The first, can be obtained using the tasks.py module. It basically does the equivalent of running mach taskgraph target, but will also automatically cache the resulting task list so future invocations run much quicker.

The second can be achieved using the vcs.py module. This uses the same approach that the old syntax selector has been using all along. It will commit try_task_config.json temporarily and then remove all traces of the commit (and of try_task_config.json).

So to recap, creating a new try selector involves:

  1. Add an @SubCommand to the mach_commands.py, which dispatches to a file under the selectors directory.
  2. Generate a list of tasks using tasks.py.
  3. Somehow filter down that list (this part is up to you)
  4. Push the filtered list using vcs.py

You can inspect the fuzzy implementation to see how all this ties together.

Future Considerations

Right now, the try_task_config.json method only allows specifying a list of task labels. This is good enough to say what is running, but not how it should run. In the future, we could expand this to be a dict where task labels make up the keys. The values would be extra task metadata that the taskgraph module would know how to apply to the relevant tasks.

With this scheme, we could do all sorts of crazy things like set prefs/env/arguments directly from a try selector specialized to deal with those things. There are no current plans to implement any of this, but it would definitely be a cool ability to have!

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: August’s Featured Extensions

Mozilla planet - ti, 01/08/2017 - 23:49

Firefox Logo on blue background

Pick of the Month: Grammarly

by Grammarly
It’s like having an expert proofreader with you at all times. Grammarly offers contextual spell checks (it understands the distinction between “there” and “their” unlike 98% of English-speaking humans) as well as grammar edits.

“As a student at a university, this is the perfect tool to correct all of my writing mistakes.”

Featured: FoxyTab

by erosman
Enjoy a suite of tab related actions, like copy all URLs, close multiple tabs, tab duplication, and more.

“This literally saved my day. Especially someone like me who works as an administrator and moderator on multiple forums, this is a great tool.”

Featured: Zoom Page WE

by DW-dev
Use full-page zoom, text-only zoom, fit-to-width feature, and other ways to focus in on Web pages.

“This is the best text zooming add-on you can find.”

Featured: Save All Images

by belav
Detects all images on any given page and presents a simple way to instantly download them.

“Very useful.”

Featured: YouTube Dark Mode

by HTCom
Turn YouTube completely dark to enhance your viewing experience.

“Simple, effective, no unintentional side effects.”

Featured: EPUBReader

by EPUBReader
Read ebook files right in your browser.

“Works flawlessly.”

Featured: Tab Auto Refresh

by Alex
Automatically refresh tabs based on custom time intervals.

“This is the first auto reload/refresh Firefox extension that I’ve found that can be customized for each tab that I have.”

Featured: TinEye Reverse Image Search

by TinEye
A new kind of reverse image searcher that uses image identification technology rather than keywords, metadata, or watermarks.

“If the image in question can’t be found, this finds it.”

Featured: Awesome Screenshot Plus

by Diigo Inc.
Take full page or partial screen grabs. Annotate with text and graphics. Store and share files. This is a full-service screenshot tool.

“It gives you a lot of options to edit, email, print. You will not be sorry!”

Nominate your favorite add-ons

Featured add-ons are selected by a community board made up of add-on developers, users, and fans. Board members change every six months. Here’s further information on AMO’s featured content policies.

If you’d like to nominate an add-on for featuring, please send it to amo-featured [at] mozilla [dot] org for the board’s consideration. We welcome you to submit your own add-on!

The post August’s Featured Extensions appeared first on Mozilla Add-ons Blog.

Categorieën: Mozilla-nl planet

Air Mozilla: Intern Presentations: Round 2: Tuesday, August 1st

Mozilla planet - ti, 01/08/2017 - 22:00

 Tuesday, August 1st Intern Presentations 11 presenters Time: 1:00PM - 3:45PM (PDT) - each presenter will start every 15 minutes 7 MTV, 2 TOR, 1 Paris, 1 London

Categorieën: Mozilla-nl planet

Air Mozilla: Intern Presentations: Round 2: Tuesday, August 1st

Mozilla planet - ti, 01/08/2017 - 22:00

 Tuesday, August 1st Intern Presentations 11 presenters Time: 1:00PM - 3:45PM (PDT) - each presenter will start every 15 minutes 7 MTV, 2 TOR, 1 Paris, 1 London

Categorieën: Mozilla-nl planet

Sebastin Santy: GSoC Week 9: Attaching Files

Mozilla planet - ti, 01/08/2017 - 20:22

Hi everyone,

This is a very short update, and there wasn’t much of an issue regarding this patch. It was merely adding the attachments with less options available to the user. We eliminated the review flags, as a bug filing process usually includes adding an image or a log as an attachment, and not a patch (for which a review might be required).

We also planned that we’ll avoid putting the tracking flags feature in the new-bug, as flagging is often done, after the bug is filed, and having them, would unnecessarily clutter the interface. The development is going a bit slow again, as it is getting difficult for me to juggle between timezones, but I hope, it will be completed before the deadline - Batteries Included! :-)

Categorieën: Mozilla-nl planet

Mark Banner: Moving Blog

Mozilla planet - ti, 01/08/2017 - 20:05

Just a short note to say that I’m moving my blogging to https://www.thebanners.uk/standard8/

Categorieën: Mozilla-nl planet

Air Mozilla: Webdev Extravaganza: August 2017

Mozilla planet - ti, 01/08/2017 - 19:00

 August 2017 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on. This...

Categorieën: Mozilla-nl planet

Air Mozilla: Webdev Extravaganza: August 2017

Mozilla planet - ti, 01/08/2017 - 19:00

 August 2017 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on. This...

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: NoScript’s Migration to WebExtensions APIs

Mozilla planet - ti, 01/08/2017 - 18:00

We asked Giorgio Maone, developer of the popular security extension NoScript, to share his experience about migrating to WebExtension APIs. Originally released in 2005, NoScript was developed to address security vulnerabilities in browsers by pre-emptively blocking scripts from untrusted websites. Over the time it grew into a security suite including many additional and often unique countermeasures against various web-based threats, such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and Clickjacking.

Why did you decide to transition NoScript to WebExtension APIs?

The so-called “legacy” add-on technology which NoScript has been built with is going to be banned very soon; therefore, like too often in real life, it’s either migrate or die. Many people rely on NoScript for being safer on the Web and in some cases for their physical security too, making this transition, although quite painful, an ethical obligation not to leave them in the cold.

For a long time, I strove to maintain as much backwards compatibility as possible, in order to offer some protection to those users stuck for various reasons with older, inherently less safe, versions of Firefox. For this reason, the legacy version of NoScript contains a lot of code for working around bugs that Firefox has since fixed: this cruft can safely go away during the migration. The plan is to have a lean and mean version of NoScript available as soon as Firefox 57 is released. Some of the APIs required for full parity with the legacy version won’t land until Firefox 57. Until then, I can selectively delegate and prioritize some features to WebExtension APIs that already work by packaging NoScript as an Embedded WebExtension, which is also the best way to migrate user preferences.

On the other hand, people who need NoScript most are those who use the anonymity and security specialized Tor Browser, which is based on Firefox ESR (Gecko 54 until June 2018) where NoScript is not viable yet as a WebExtension. Therefore I’m forced to maintain two very different code bases for almost one year after the release of Firefox 57, in order to support the vast majority of my users.

Can you tell us about where you are with the migration?

NoScript already ships as a hybrid add-on, and I am in the process of moving all the code to WebExtensions APIs. Some features are even more performant on the new platform: it’s the case of the XSS filter, which takes advantage of the more asynchronous architecture of WebExtensions. The legacy XSS filter may stall the browser for a few seconds while checking very large (fortunately unusual) payloads; the WebExtensions-based version allows the browser to stay responsive no matter the load.

Have you had to use WebExtension APIs in creative ways?

NoScript 10 as a WebExtension is built mainly around the WebRequest API, which in its Firefox incarnation features some tweaks differentiating it from its Chromium counterpart. Last year I’ve been working together with the WebExtensions team to develop this enhanced API: a very pleasant experience and a welcome chance for me to contribute code on Mozilla Central again, after quite awhile. Dynamic permissions for embedded JavaScript are not natively supported by WebExtensions. Rather than requesting a new API, I am using Content Security Policies (CSP), a Web Application Security standard, to control scripting execution and other security properties of the webpage. Likewise I’m leveraging other Web Platform (HTML5) features, which were not available yet in the early NoScript days, to rebuild functionality originally based on “legacy” XUL and XPCOM technology.

What advice would you give to other legacy add-on developers?

Try to find workarounds for any missing pieces and be creative when using available APIs, not limited to just within the WebExtensions APIs boundaries but also exploring the whole Web Platform. If workarounds are impossible, ask the add-ons team for additions or enhancements.

Also, try to join and lobby the Browser Extensions Community Group hosted by the W3C. I feel that Mozilla has the most flexible and dynamically growing browser extensions platform, but it would be nice to make sure that the good ideas landing in Firefox also be available in Chrome and other browsers.

Thank you, Giorgio! Best of luck with the migration.

The post NoScript’s Migration to WebExtensions APIs appeared first on Mozilla Add-ons Blog.

Categorieën: Mozilla-nl planet

Justin Dolske: Photon Engineering Newsletter #10

Mozilla planet - ti, 01/08/2017 - 17:55

Woo yeah! Time for Photon newsletter #10!

Nightly-57 this week

Way back in newsletter #2, I talked about the Photon program schedule. Briefly, to save you a click: Photon is shipping with Firefox 57, and to allow time for bugfixes, quality, and polish we’ve been targeting August 7th as the date when we’ll be done with “major work.” That gives us 6 weeks of Nightly-57 to do that bugfixing (and another 6 weeks of Beta-57 for any further critical or low-risk improvements).

I’m pleased to report that we’re still solidly on track. Most of the big-ticket features for Photon have already landed, and the last few (notably: rectangular tabs, pinning Page Action items to the URL bar) are in good shape to land soon. That’s not to say Photon is “done” – just that the biggest and riskiest work will largely be behind us, and upcoming work will start to be more about finishing off rough edges.

Recent Changes

Menus/structure:

Animation:

  • The Stop/Reload animation has been tweaked to run faster.
  • Animations have been fixed to be positioned correctly regardless of display font size. [1] [2]
  • The Save to Bookmarks animation has landed in Nightly. (Add the Library button to the toolbar for the full effect!)
    star
    bookmark-animation
  • The Save to Pocket animation has also landed  (Again, you’ll want to ensure the Library button is in the toolbar to see all of the animation.)
    pocket-animation

Preferences:

  • Fixed Performance section regression around number of processes and uplifted it to Beta-55.
  • Started working on visual refresh but are holding off landing until after the uplift. This allows QA to finish verifying the changes (in Nightly) that will ship with Firefox 56, without these 57-only changes getting in the way.

Visual redesign:

Onboarding:

  • The first uncompleted tour is now shown by default (instead of just the first tour).
  • Updated the stub installer tagline to “Built for people, not for profit.
  • Made the “Learn More” button not wrap.
  • The Sync tour will be automatically marked as completed when you sign in with a Firefox account.
  • When refreshing a profile, don’t migrate a user’s session (tabs) unless the refresh was invoked by the user. This allows the reset triggered by the stub installer (e.g. for users coming back to Firefox after a long absence) to have a fresh experience, instead of seeing old tabs from months ago.
  • Made the onboarding UI look better in high-contrast mode.

Performance:

 

That’s it for now!


Categorieën: Mozilla-nl planet

Air Mozilla: Martes Mozilleros, 01 Aug 2017

Mozilla planet - ti, 01/08/2017 - 17:00

Martes Mozilleros Reunión bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...

Categorieën: Mozilla-nl planet

Air Mozilla: Martes Mozilleros, 01 Aug 2017

Mozilla planet - ti, 01/08/2017 - 17:00

Martes Mozilleros Reunión bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...

Categorieën: Mozilla-nl planet

The Mozilla Blog: New Test Pilot Experiments Available Today

Mozilla planet - ti, 01/08/2017 - 16:00

It’s been a busy summer for Firefox!                     Last month, we delivered the first in a series of groundbreaking updates to the browser. This week, the Test Pilot team is continuing to evolve Firefox features with three new experiences that will make for a simpler, faster and safer experience.

Send

Sending files over the internet is something many of us do everyday. Mozilla makes it easy to keep your files safe. With Send, your files self-destruct after download, so they can’t be accessed by anyone else. Your files are encrypted during transmission. Plus, Send encrypts files on the client side, so that not even Mozilla can read them.

Voice Fill

Mozilla is a champion of making the web open and accessible to everyone. With Voice Fill, we’re experimenting with support for Speech to Text (STT) functionality in Firefox, making it possible for users to input text in Firefox by voice. Your contributions to this experiment will help us optimize speech to text input so that we can expand support throughout Firefox.

Notes

Whether it’s a sticky note, an app or the back of an envelope, so many of us rely on jotting down quick notes to keep track of our busy lives. Notes is a simple, convenient place to take, store and retrieve notes – all within Firefox. We’re also working to build in support for Firefox Accounts, so you can sync your notes wherever you use Firefox

The Test Pilot program is open to all Firefox users and helps us test and evaluate a variety of potential Firefox features. To activate Test Pilot and help us build the future of Firefox, visit testpilot.firefox.com.

If you’ve experimented with Test Pilot features before, you know that you might run into some bugs or lose some of the polish in Firefox, so you can easily enable or disable features at any time.

We want your feedback! Try out these and other Test Pilot experiments and help us decide which new features to build into future versions of Firefox.

The post New Test Pilot Experiments Available Today appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Mozilla releases research results: Zero rating is not serving as an on-ramp to the internet

Mozilla planet - ti, 01/08/2017 - 07:00

Can digital literacy and Equal Rating solutions help connect the unconnected?

Today, 4 billion people live without the internet. There’s a global debate about how to connect the unconnected, but it’s often dominated by assumptions and not a lot of data or talking to actual users on the ground.

To better inform this issue, Mozilla recently supported a series of focus groups to investigate how and why people use subsidized services in India, Myanmar, Peru, Kenya, Nigeria, Rwanda and South Africa. Today, we’re releasing the results of this research carried out by Research ICT Africa, LIRNEasia and IEP.

Credit: Peter Cihon

Why do we care?
Many companies and organizations are working to connect the unconnected. For us at Mozilla, it is our mission to ensure the internet is a global public resource that’s open and accessible to all.

We’ve focused our work in this space on a concept we call Equal Rating. Building on Mozilla’s strong commitment to net neutrality, Equal Rating models are free of discrimination, gatekeepers, and pay-to-play schemes. Equal Rating stands in contrast to zero rating business models, which reduce the cost to zero only for some sites and services. We’ve pursued this through policy engagement with governments, an innovation challenge to catalyze new thinking in providing affordable access, and this research.

What did we ask?

  • What barriers are keeping people offline?
  • Is zero rating serving as an on-ramp to the internet?
  • Why and how do people use subsidized services?
  • Do people move beyond subsidized services, or do they just stay in the subsidized walled garden?
  • How does use of subsidized services affect future internet usage?

What did we find?

Zero rating is not serving as an on-ramp to the internet
In all countries surveyed — excluding India where zero rating has been banned by the regulator — focus groups revealed that users are not coming online through zero rated services. While more research is needed, if zero rating is not actually serving as an on-ramp to bring people online, the benefits seem low, while the resulting risk of these offerings creating an anti-competitive environment is extremely high.

People use zero rating as one of many cost saving strategies
This research revealed that people who use zero rated services usually also have full access to the internet, and make use of zero rated and subsidized data services as one of many money-saving strategies, including:

  • Use of multiple SIM cards to take advantage of promotions, better reception quality, or better prices for a given service.
  • Use of public Wi-Fi. For example, many buses in Kenya now provide Wi-Fi access, and participants reported being willing to wait for a bus that was Wi-Fi-enabled.
  • Tethering to mobile hotspots. In South Africa and India, users not only share data but also promotions and subsidized offers from one phone to another.
  • Earned reward applications (where users download, use, or share a promoted application in return for mobile data/credit). The research indicates that most users tend to play the system to get the most credit possible and then abandon the earned reward application.
  • While users, especially in the African studies, report skepticism about whether zero rated promotions are truly free, partially subsidized bundles are popular. Notably, many of these offerings are Equal Rating compliant.

Some, particularly rural and low income users, are trapped in walled gardens
While zero rated services tend to be only part of internet usage for most users studied, some users are getting trapped in the walled gardens of these subsidized offerings.

  • In particular, low income respondents in Peru and Rwanda use zero rated content for much of their browsing activity, as do rural respondents in Myanmar.
  • Awareness matters: in Myanmar, respondents who know they are in a zero rated walled garden (e.g., due to lack of photos and video) are more likely to access the full internet beyond the walled garden.
  • But, when Facebook is subsidized without impacting user experience, users tend to concentrate their usage on that single site, demonstrating concerns around the anti-competitive effects of zero rating.

Digital illiteracy limits access for connected and unconnected alike
Infrastructure and affordability are commonly cited barriers to internet access around the world; yet, this research also points to a third important barrier: digital literacy.

  • Users and non-users alike do not understand all that the internet can offer.
  • Users generally restrict their internet use to a few large websites and services.
  • A lack of understanding about the internet and internet-connected devices exacerbates misconceptions and spreads fear around privacy, security, and health, which in turn undermines use of the internet. One Kenyan respondent said of non-users: “there are some assumptions that they can get diseases transmitted to them like skin cancer through the use of the internet.”

Many companies and NGOs are already doing great work to advance digital literacy, but we need to scale up these efforts.

Competition, literacy, language, and gender are also barriers to internet access

This research highlighted a series of consistent and persistent barriers to access.

  • While 95% of the world has access to an internet signal, far too often, users have access to only one, low quality provider, usually the most expensive option in their country.
  • Without basic literacy, some respondents cannot access the internet. As one respondent in rural South Africa said, “if you cannot read or write you cannot use internet, many people in this community are not educated and I believe most of them want to be able to use internet because it makes life easier.”
  • Others in Myanmar, Peru, and Rwanda cite the lack of local language content and tools as keeping them from coming online.
  • Evidence of a gendered digital divide is seen throughout all of the countries studied, with some women afraid of “breaking the machine” while others say social stigma, domestic abuse, negative impressions, and housework obligations limit their use of the internet.

These are just some of the highlights and interesting findings. We have results from nearly 80 focus groups in these seven countries. For more detailed information, the country summaries and full reports are available here.

Next steps to bring the next 4 billion online

Mozilla supported this research to help better inform what we believe is a global imperative to bring the world’s 4 billion unconnected people online to access the full and open internet.

Based on these findings, we believe the internet needs:

  • The development of more Equal Rating compliant models, many of which seemed to be quite popular with research respondents and provide access to the full diversity of the open internet, not just some parts of it.
  • Further investment in digital literacy training, especially in schools, on devices, and in retail outlets. For more information about Mozilla’s digital literacy efforts, see our recent Digital Skills Observatory study.
  • Work on all barriers to access to address infrastructure investment especially in rural areas, affordability, local content and local language tools, and gender equality.

Bringing the full internet to all people is one of the great challenges of our time. While we know there is more research needed, this research better informs the global debate on how to connect the unconnected, and makes clear the challenges ahead. We are committed to tackling these challenges but we know it will take all of us — tech companies, telecom companies, governments, civil society groups and philanthropists — working together to get everyone online.


We’d like to thank the researchers at Research ICT Africa, LIRNEasia, and IEP, as well as Jochai Ben-Avie (who manages all our Equal Rating work) and Peter Cihon (our awesome summer intern) who helped analyze this research
.

The post Mozilla releases research results: Zero rating is not serving as an on-ramp to the internet appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 193

Mozilla planet - ti, 01/08/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 tarpaulin, a crate to collect test coverage of your Rust code. Thanks to Colin Kiegel 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

146 pull requests were merged in the last week

New Contributors
  • Daiki Mizukami
  • Danek Duvall
  • Isaac van Bakel
  • Joshua Liebow-Feeser
  • MaulingMonkey
  • Richard Dodd
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 Style RFCs

Style RFCs are part of the process for deciding on style guidelines for the Rust community and defaults for Rustfmt. The process is similar to the RFC process, but we try to reach rough consensus on issues (including a final comment period) before progressing to PRs. Just like the RFC process, all users are welcome to comment and submit RFCs. If you want to help decide what Rust code should look like, come get involved!

The RFC style is now the default style in Rustfmt - try it out and let us know what you think!

Currently being discussed:

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

No quote was selected for QotW.

Submit your quotes for next week!

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

Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - August 1, 2017

Mozilla planet - ti, 01/08/2017 - 02:00

Here’s what happened on the MozMEAO SRE team from July 25th - August 1st.

Current work MDN Migration

@metadave and @escattone are working on migrating MDN from the SCL3 datacenter to AWS.

MDN misc Decommissioning the Virginia cluster

The last remaining services running on the Virginia cluster have been moved to other regions or hosting options:

Links
Categorieën: Mozilla-nl planet

Emma Humphries: Firefox Triage Report 2017-07-31

Mozilla planet - ti, 01/08/2017 - 01:44

It's the weekly report on the state of triage in Firefox-related components.

Hotspots

The components with the most untriaged bugs have not changed substantially from last week, and the number of untriaged bugs has gone up.

**Rank** **Component** **Last Week** **This Week** ---------- ------------------------------ --------------- --------------- 1 Core: JavaScript Engine 431 446 2 Firefox for Android: General 406 410 3 Core: Build Config 399 421 4 Core: General 234 239 5 Firefox: General 234 238 6 Core: Graphics 199 194 7 Core: XPCOM -- 178 8 Core: Disability Access APIs 173 162 All Components 8,403 8,543

Please make sure you’ve made it clear what, if anything will happen with these bugs.

Not sure how to triage? Read https://wiki.mozilla.org/Bugmasters/Process/Triage.

Next Release

Wednesday is Merge Day for 56.

There are still 4,400 bugs filed during the Firefox 55 release cycle without decisions.

**Version** 55 55 55 55 ------------------------------------- ------------ ------------ ------------ ------------ **Date** 2017-07-10 2017-07-17 2017-07-24 2017-07-31 **Untriaged this Cycle** 4,525 4,451 4,317 4,479 **Unassigned Untriaged this Cycle** 3,742 3,682 3,517 3,674 **Affected this Cycle** 111 126 139 **Enhancements** 102 107 91 103 **Orphaned P1s** 199 193 183 192 **Stalled P1s** 195 173 159 179

What should we do with these bugs? Bulk close them? Make them into P3s? Bugs without decisions add noise to our system, cause despair in those trying to triage bugs, and leaves the community wondering if we listen to them.

Note

I’m traveling from the 1st to the 17th. I plan to send out updates on the 7th and 14th, but they may be delayed.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android, Firefox for IOs, and Toolkit which are unresolved, not filed from treeherder using the intermittent-bug-filer account*, and have no pending needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on next), P3 (backlog), or P5 (will not work on but will accept a patch).

A triage decision is not the same as a release decision (status and tracking flags.)

https://mozilla.github.io/triage-report/#report

Age of Untriaged Bugs

The average age of a bug filed since June 1st of 2016 which has gone without triage.

https://mozilla.github.io/triage-report/#date-report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 55 release cycle (March 6th, 2017) which do not have a triage decision.

https://mzl.la/2u1R7gA

Recommendation: review bugs you are responsible for (https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2u2GCcG

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity = enhancement, and untriaged.

​Recommendation: ​product managers should review and mark as P3, P5, or RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2u1VLem

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3, P5, or RESOLVE.

Stalled High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be changed to P2, P3, P5 or RESOLVE.

* New intermittents are filed as P5s, and we are still cleaning up bugs after this change, See https://bugzilla.mozilla.org/show_bug.cgi?id=1381587, https://bugzilla.mozilla.org/show_bug.cgi?id=1381960, and https://bugzilla.mozilla.org/show_bug.cgi?id=1383923

If you have questions or enhancements you want to see in this report, please reply to me here, on IRC, or Slack and thank you for reading.



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

Alexis Metaireau: Comment installer Kinto manuellement chez Alwaysdata

Mozilla planet - ti, 01/08/2017 - 00:00
Qu'est-ce que Alwaysdata ?

Alwaysdata est un hébergeur français qui vous permet de payer pour un espace et d'y héberger autant de sites que vous le souhaitez en toute liberté.

L'équipe est à l'écoute et très sympathique ce qui en fait un service de grande qualité.

Une offre de découverte gratuite vous permet de tester le service avant de souscrire à un abonnement.

Créer un compte chez Alwaysdata

Pour créer un compte, rendez-vous ici: https://www.alwaysdata.com/fr/signup/

Vous allez renseigner vos coordonnées, votre email et choisir un mot de passe ainsi qu'un identifiant pour votre compte.

Cet identifiant vous sera nécessaire par la suite. Nous l'appelons ID_ALWAYSDATA.

Installation automatique de Kinto chez Alwaysdata

Avant toute chose, sachez qu'il existe un script qui s'occupe de faire l'installation pour vous automatiquement.

Vous pouvez le trouver ici : https://kinto.github.io/kinto-alwaysdata/

Installation manuelle de Kinto chez Alwaysdata Activez Python 3.6.0

Dans le menu Environnement > Python vérifiez que votre version de Python par défaut soit bien au moins Python 3.6.0

Configurer la version 3.6.0 de Python chez Alwaysdata. Créez une base de données PostgreSQL

Via l'administration de Alwaysdata vous pouvez créer un utilisateur et une base de données PostgreSQL, retenez bien l'identifiant et le mot de passe car vous en aurez besoin pour votre fichier de configuration kinto.ini

Créer un utilisateur et une base de données PostgreSQL Activer la connexion SSH

L'installation de Kinto chez Alwaysdata se fait à l'aide de la connexion SSH.

Commencez par vous connecter à l'administration et à activer votre compte SSH.

Activer l'utilisateur SSH. Créer le fichier de configuration de Kinto

Créez le fichier kinto/kinto.ini

Vous pouvez utiliser ce modèle de fichier ini en veillant bien à remplacer les champs de type {...} et à configurer votre base de donnée PostgreSQL (appellée ici DBname) avec votre identifiant et mot de passe. Il est conseillé de créer un utilisateur spécifique pour Kinto (ici DBuser) en plus de votre compte AlwaysData (ici ADuser).

  • {id_alwaysdata} -> ADuser_DBuser
  • {password} -> le mot de passe
  • {postgresql_host} -> postgresql-ADuser.alwaysdata.net
  • {prefixed_username} -> ADuser_DBname

Vous devez également générer une clé secrète pour {hmac_secret}. Pour ce faire vous pouvez utiliser la commande uuidgen.

Pas besoin de changer {bucket_id}/{collection_id}.

Créer le lanceur du serveur

Créez le fichier kinto/kinto.wsgi

Vous pouvez utiliser ce modèle de fichier WSGI

Veillez à ce que le fichier soit exécutable :

chmod +x kinto/kinto.wsgi Créer un environment virtuel Python et installez Kinto dedans

Vous pouvez vous connecter à votre compte SSH depuis le terminal :

ssh ID_ALWAYSDATA@ssh-ID_ALWAYSDATA.alwaysdata.net

Remplacez ID_ALWAYSDATA par l'identifiant de votre compte alwaysdata.

virtualenv kinto/venv/ kinto/venv/bin/pip install kinto[postgresql] kinto-attachment kinto/venv/bin/kinto migrate --ini kinto/kinto.ini Associer votre Kinto à un nom de domaine

Par défaut, Alwaysdata vous procure le sous domaine suivant: ID_ALWAYSDATA.alwaysdata.net

Mais vous pouvez également lier votre propre nom de domaine, soit en délégant la gestion du DNS à Alwaysdata soit en configurant la zone DNS pour pointer vers les serveurs de Alwaysdata.

Dans tous les cas Alwaysdata pourra vous fournir un certificat SSL gratuit via Let's Encrypt.

Ajoutez un nouveau site Configurer le site internet Informations

Entrez les informations concernant le site.

  • Nom : Kinto
  • Adresses: ID_ALWAYSDATA.alwaysdata.net
Nom du site et noms de domaine associés. Configuration

Configurer le site Python :

  • Type : Python WSGI
  • Chemin de l'application : /kinto/kinto.wsgi
  • Version de Python : Version par défaut
  • Répertoire du virtualenv : /kinto/venv/
  • Chemins statiques : /attachments/=attachments
Configuration du site Python SSL
  • Forcer le SSL : Oui
Configuration SSL Se connecter

Vous pouvez maintenant vous connecter au site et vérifier que tout fonctionne :

Configurer un administrateur

Connectez-vous à la kinto-admin : https://ID_ALWAYSDATA.alwaysdata.net/v1/admin/

Choisissez un login/password et connectez-vous. Vous allez obtenir un identifiant unique pour votre administrateur: basicauth:......

Vous pouvez ensuite modifier la configuration de votre serveur Kinto pour n'autoriser la création de bucket que par cet utilisateur (et vous protéger des usages abusifs de votre service.)

kinto.bucket_create_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.bucket_write_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.bucket_read_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.collection_create_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.collection_write_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.collection_read_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.group_create_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.group_write_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.group_read_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.record_create_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.record_write_principals = basicauth:800748fb8963fd00...a3420db354570a4e kinto.record_read_principals = basicauth:800748fb8963fd00...a3420db354570a4e

Si vous utilisez un autre système d'authentification, vous aurez probablement d'autres identifiants ne commençant pas par basicauth mais vous pouvez quand même utiliser ces identifiants dans votre fichier de configuration.

Vous pouvez également créer un groupe et utiliser ce groupe comme identifiant.

N'hésitez pas à nous demander de l'aide sur Slack ou IRC.

Categorieën: Mozilla-nl planet

David Humphrey: Service Workers and Cache Storage in Thimble

Mozilla planet - mo, 31/07/2017 - 20:03

tldr; During the spring and summer, I've been working on rewriting Thimble to use Service Workers and CacheStorage. Now that we've shipped it, I wanted to talk about how it works and what I learned.

On Twitter a few weeks back, I was reminiscing with Dave Herman and Brendan about web standards we worked on in Firefox a decade ago. Dave made the point that the 2017 web is still exciting and accelerating, especially with things like Service Workers. I couldn't agree more.

I've been waiting to be able to do what Service Workers provide forever. For years we heard about all the problems that they would solve, and I was a believer from day one. Imagine having a web server running in your browser, and able to serve any content type? Sign me up!

Now that they're here (Chrome and Firefox), most of what I see written relates to using Service Workers in order to build Progressive Web Apps (PWA). PWAs are great, but there are other things you can do with Service Workers. For example, you can use them to serve user generated content on the fly without needing a server.

Four years ago I started working on this problem. The goal was to be able to allow users to create arbitrary web sites/apps in a full editor, and then run them without needing a server. In a classroom setting, the network is often non-functional and I wanted to make it possible to just use a browser to do everything. I wanted a static web page to provide the following:

  • filesystem (we wrote a browser version of node's fs module called Filer)
  • full editor (we forked Adobe's Brackets editor and made it run in the browser)
  • "web server" to host static content from the filesystem
  • "web browser" to run the content (an iframe with a postMessage API)

My first attempt was done before Service Workers were readily available, and didn't use them. Also, because I wanted to support as many browsers as possible, I needed a "progressive" solution for providing these features: IE11 will never have Service Workers, for example, while Safari probably will (see how optimistic I am?).

This initial version made heavy use of Blob, URL.createObjectURL(), and DOMParser. The idea was to leverage the fact that all filesystem operations are asynchronous, which provides an opportunity to also create and cache Blob URLs for files, mapped to filenames. When a user tries to browse to index.html, we instead serve the cached Blob URL for that file, and the browser does the rest. For content within an HTML or CSS file, we simply rewrote all the relative links to use Blob URLs, such that image/background.png becomes blob:https%3A//mozillathimblelivepreview.net/264a3524-5316-47e5-a835-451e78247678.

It worked great for many years as part of Thimble, allowing students and teachers to learn web programming without having to do any installation or setup.

However, I was never satisfied with this approach, especially since I knew Service Workers could solve one or our largest problems: we couldn't reliably rewrite filenames to Blob URLs in dynamic JavaScript. Over and over again users would file bugs that would say, "I tried to use JS to load an image, and it didn't work!" Not being able to fully support JS at the network level was no good, and it frustrated me to not fully support all of the web.

So I slowly worked away at adding a secondary URL cache implementation based on Service Workers. My idea was to use the same pathways that we already had for writing Blob URLs for file content, but instead of rewriting links, we'd just let a Service Worker serve the content from our filesystem instead of the network.

There was one problem for which I couldn't see an elegant solution. I needed a way for the editor to share the content with the Service Worker, since we don't always serve pages from disk (e.g., IndexedDB): if a user is editing a file, we serve an instrumented version instead, which does things like live highlighting, hot reloads, etc. It's possible for a user to have many Thimble tabs open at once, but there will only be one Service Worker. I didn't want the Service Worker to have to poll every open Thimble window before it found the right content.

The solution turned out to be really easy. Instead of somehow posting data between the DOM windows and the Service Worker, I could instead use storage shared between both in the form of CacheStorage. Whoever had the brilliant insight to make this available to both window and the Service Worker, I salute your forward thinking!

Using CacheStorage I was now able to create and cache URLs in the editor's DOM every time content changed on disk, or whenever the live version of a resource was updated. Then, the browser could request the resource and the Service Worker could fulfill the request using the cached URL, without needing to know where it came from in the first place. It's beautifully simple and works flawlessly.

For example, here's the React version of the TodoMVC app running unmodified in Thimble, which uses lots of dynamic JS:

And here's a great HTML5 Game Workshop from Mozilla Hacks, which uses JS, audio, and dynamic images/sprites:

At a high level, the code on the editor/filesystem side looks like this:

var data; // Typed Array of bytes (PNG, CSS file, etc) var type; // some content type, maybe 'application/octet-binary' var blob = new Blob([data], {type: type}); var response = new Response(blob, { status: 200, statusText: "Served from Offline Cache" }); var headers = new Headers(); headers.append("Content-Type", type); var url; // How you want to address this, any valid URL. var request = new Request(url, { method: "GET", headers: headers }); var cacheName; // Some unique name for this cache, maybe a URL window.caches .open(cacheName) .then(function(cache) { cache.put(request, response); }) .catch(callback); };

Inside the Service Worker, I do something like this, looking for the requested URL in the cache, and serving it if possible:

self.addEventListener("fetch", function(event) { event.respondWith( caches.match(url) .then(function(response) { // Either we have this file's response cached, or we should go to the network return response || fetch(event.request); }) .catch(function(err) { return fetch(event.request); }) ); });

HTML, CSS, JavaScript all work now, and so does audio, video, JSON, and any new thing that gets added to the web next year. Everything just works, thanks to Service Workers.

We quietly enabled this new cache layer on Thimble a month ago, and it's been working well. We do feature detection on Service Workers and Cache Storage, and browsers that support them get the new cache implementation, while browsers that don't continue to use or old Blob URL based layer.

After so many years of workarounds and complex hacks to make this work, I was amazed at how little code it took to get this working with the Service Worker and Cache Storage APIs. This was my first major app that used the new Service Worker stuff, and I found it took me a long time to adjust my mental model for web dev (the Service Worker lifecycle is complex and sometimes surprising), and my debugging workflow; the final code isn't hard, but the adjustment in how you build and test it is fairly significant. I've also found that it's been somewhat frustrating for my teammates who don't know as much about Service Workers, and run into various cache-related bugs that can be annoying.

My experience is that Service Workers do indeed live up to the hype I heard a decade ago, and I'd highly recommend you consider using them in your own apps. Don't get hung up on thinking of them only as a way to cache resources coming from the server as you load your pages. Instead, you should also consider them in cases where your user or client app generates content on the fly. You can serve this dynamic content alongside your hosted content, blurring the line between client/server. There's a lot of interesting problems you can solve this way, and all of it can be done with or without network.

Also, if you're teaching or learning web dev, please give Thimble a try. We've been adding a lot of cool features beyond just this architectural change I've described, and we think it's one of the best online coding tools available right now.

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 31 Jul 2017

Mozilla planet - mo, 31/07/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Pages