Peter Elmers has not yet given us a description of this presentation, nor any keyword tags to make searching for this event easier.

https://air.mozilla.org/dxr-all-the-things/

Francis Kang has not yet given us a description of this presentation, nor any keyword tags to make searching for this event easier.

https://air.mozilla.org/diving-into-the-unknown/

Tyler Lacroix has not yet given us a description of this presentation, nor any keyword tags to make searching for this event easier.

https://air.mozilla.org/a-swifty-internship/

Erica Wright has not yet given us a description of this presentation, nor any keyword tags to make searching for this event easier.

https://air.mozilla.org/everything-on-the-side/

Sai Chandramouli talks about what was accomplished in a summer internship at Mozilla: 1. Password Hints for weak passwords 2. Adding Geolocation data to emails...

https://air.mozilla.org/god-bless-fxa/

Reviewing Release Engineering, Release Promotion, and the Pulse-Notify microservice developed by Connor Sheehan during his internship at Mozilla.

https://air.mozilla.org/release-promotion-keeping-tabs-on-automation/

Nancy Pang has not yet given us a description of this presentation, nor any keyword tags to make searching for this event easier.

https://air.mozilla.org/ramping-up-the-web/

Group 1 of our interns are going to be presenting on what they worked on this summer.

https://air.mozilla.org/intern-presentations-2016/

Hello, SUMO Nation!

How have you been doing in July? Hopefully you’re getting some well deserved holidaying/AFK-ing done. I keep hearing chasing imaginary monsters around is fashionable nowadays… Any trainers out there?

Welcome, new contributors!

• Briana
• Europamoon100
• chrisranthony

If you just joined us, don’t hesitate – come over and say “hi” in the forums!

Most recent SUMO Community meeting

• You can read the notes here and see the video at AirMozilla.
  

The next SUMO Community meeting…

• …is happening on the 20th of July!
• If you want to add a discussion topic to the upcoming meeting agenda:
  • Start a thread in the Community Forums, so that everyone in the community can see what will be discussed and voice their opinion here before Wednesday (this will make it easier to have an efficient meeting).
  • Please do so as soon as you can before the meeting, so that people have time to read, think, and reply (and also add it to the agenda).
  • If you can, please attend the meeting in person (or via IRC), so we can follow up on your discussion topic during the meeting with your feedback.

Community

• We’re meeting with the Brazilian community tomorrow to talk about plans for the near future.
• Not too long after the weekly community meeting on Wednesday the 20th, you’re all invited to watch our guest Tina Seelig talk about the invention cycle – more details here!
• PLATFORM REMINDER & UPDATE! The Platform Meetings are BACK! If you missed the previous ones, here is the etherpad, with links to the recordings on AirMo. We are closing the sandbox preview – huge thanks to everyone who had the time to take a look around and provide feedback!
  • We’re looking deeper into security and privacy requirements, but also l10n options (Pontoon)
• The Release Report for Firefox 47 is here! (thanks to Rachel for coordinating and publishing it)
  
• Ongoing reminder #1: if you think you can benefit from getting a second-hand device to help you with contributing to SUMO, you know where to find us.
• Ongoing reminder #2: we are looking for more contributors to our blog. Do you write on the web about open source, communities, SUMO, Mozilla… and more? Do let us know!
• Ongoing reminder #3: want to know what’s going on with the Admins? Check this thread in the forum.

Social

• Ongoing reminder: We have a training out there for all those interested in Social Support – talk to Madalina or Costenslayer on #AoA (IRC) for more information.

Support Forum

Firefox

• for Android
  • Version 48 is still on track – release in early August.

• for Desktop
  • Version 48 is still on track – release in early August.

• for iOS
  • 5.0 has postponed to the end of July for marketing reasons – it’s ready but we’re not ready to promote it until the end of the month.
    
  • Remember, it will be a big update – don’t forget the articles for it are ready to be localized!

Ah, yes… nearly forgot about this – congratulations to Portugal and their supporters for winning the Euro this year. So, what will keep you busy and excited in the coming week(s)? Let us know in the comments!

https://blog.mozilla.org/sumo/2016/07/14/whats-up-with-sumo-14th-july/

SpiderOak has been described as "Snowden's favorite cloud service". They've now added group chat and will provide an overview and demo of their new Semaphor...

https://air.mozilla.org/semaphor-overview-and-demo-zero-knowledge-collaboration-tool/

It’s been possible to submit WebExtensions add-ons to addons.mozilla.org (AMO) since February, but I wanted to take a moment to highlight some of the improvements we’ve made since then that make it much easier to get your Chrome or Opera add-on into AMO.

These features have all been deployed to AMO over the last couple of months and are available for use.

New linter

We are now using the add-ons linter for WebExtensions which means that when we parse a WebExtensions add-on, we are running through a new JavaScript-powered linter, instead of the Python one. This parsing occurs each time you upload a new add-on or a new version of an add-on.

It uses eslint to parse the JavaScript and a schema to verify that the WebExtensions manifest is correct. Because we’ve started to implement functionality in the new add-ons linter that didn’t exist in the old version, more things will be showing up as warnings.

As an example, if you request a permission in the manifest that Firefox doesn’t support, you’ll get a warning:

Relaxed upload criteria

If you’ve developed and add-on for Chrome or Opera, we’d like you to upload it to AMO. For this reason, we’ve relaxed a few criteria around AMO. Once you’ve verified that an add-on works correctly using about:debugging, you should then be able to upload it to AMO quite easily. We’ve hopefully made this easier through the following steps:

Optional add-on id

If your WebExtension does not have an id specified in the manifest.json, then AMO will generate an id for your add-on and add it to the add-on signing process. You can then get the add-on id from AMO and re-use that in later API calls, if needed.

The command line tool web-ext also supports optional ids.

Uploads

AMO will now accept an add-on as a zip file or a crx file. It will still only emit xpi files that Firefox and other Mozilla projects can consume. In the case of a crx file, the extra data added by the Chrome store will be stripped out of the file.

We recommend using a tool like web-ext to generate the appropriate file for your add-on.

Comments in the manifest file

Although comments are not valid in a JSON file, Chrome supports comments in the manifest.json file. To keep compatibility with Chrome, the addons-linter and hence AMO now support comments in the manifest file, but only comments starting with a double slash (//).

Translations

Finally, AMO now supports translations in the manifest. This again follows the Chrome standard, so that:

//in manifest.json:
"default_locale": "en",
"name": "__MSG_appName__",

//in _locales/en/messages.json:
{
  "appName": {
    "message": "My Add-on",
    "description": "The name of the add-on."
  }
}

//in _locales/de/messages.json:
{
  "appName": {
    "message": "Mein Add-on"
  }
}

The manifest will be parsed and the translations automatically entered into AMO. You need to ensure that default_locale is set in the manifest for the localisations to be activated. On the first upload, AMO will process the translations:

If you’d like to get involved then join our mailing list or check out our repositories on Github.

https://blog.mozilla.org/addons/2016/07/14/webextensions-support-on-amo/

Once a month, web developers from across Mozilla get together to talk about the work that we’ve shipped, share the libraries we’re working on, meet new folks, and talk about whatever else is on our minds. It’s the Webdev Extravaganza! The meeting is open to the public; you should stop by!

You can check out the wiki page that we use to organize the meeting, or view a recording of the meeting in Air Mozilla. Or just read on for a summary!

Shipping Celebration

The shipping celebration is for anything we finished and deployed in the past month, whether it be a brand new site, an upgrade to an existing one, or even a release of a library.

Okta SSO Fix Add-on

First up was shobson, who shared MoCo SSO Tweaks, a Firefox add-on that makes the Okta SSO flow better. Among other things, it auto-focuses the verification code field, makes Enter submit the verification code form, and optionally automatically checks the “Remember Device” checkbox.

ViewSourceConf.org

Next was hoosteeno, who shared viewsourceconf.org, the website for the 2016 edition of View Source, a conference for the web that Mozilla runs. The site is statically generated by Metalsmith and takes advantage of several plugins include the model plugin and the template plugin for Swig templates.

shobson worked on the frontend for the site. It intentionally avoids using jQuery and uses SVGs for small image filesizes and easy Retina support. In the future the site will be using Service Workers to enable offline access for the site, and particularly the schedule.

Air Mozilla Timenails

peterbe stopped by to talk about the timenail support he added to Air Mozilla. A timenail is a single screenshot from a video at a specific timestamp; a series of timenails is generated by the transcoding process and made available in the chapter editing interface for each video to help aid in finding good transition points for marking chapters in the video.

The site also calculates the difference between timenails and lets users filter the timenail list to only show thumbnails that have a difference between the previous timenail above a given threshold.

DXR

Next up was ErikRose, sharing a bunch of new changes that landed in DXR:

• Case-sensitivity is now inferred based on whether the search text is mixed case or not.
• Support for XPIDL
• 20% lower memory use
• Improved C++ analysis, including template support.

Thanks to new_one and Tom Klein for contributing these improvements!

Peep 3.1.2

Erik also mentioned that peep 3.1.2 is out, with support for pip 8.1.2.

Fathom

Erik’s last mention was Fathom, which is an experimental framework for extracting meaning from webpages. You provide it declarative rules that score and classify DOM nodes, and in return it will parse a webpage and rank DOM nodes in the page based on the given rules. You can then extract nodes from this ranking in various ways, such as finding the highest-ranked nodes for a specific attribute, or finding clusters of similarly-classified nodes that are close to each other.

Readable Bug Statuses in Bugzilla

emceeaich and dylan wanted to share (in absentia) the news that the Readable Bug Status package that emceeaich has been working on has been deployed on bugzilla.mozilla.org for bugs in the Firefox, Core, Toolkit, and BMO products. Readable Bug Status helps summarize the status of a bug using information from several fields.

Bedrock + Gulp

Next was pmac who shared the news that Bedrock has switched to using gulp to help manage their frontend build and development process. The site previously relied on django-pipeline completely to manage its static assets, but ran into issues with slow builds during development, as django-pipeline doesn’t watch for which files have changed and simply triggers a full build on each pageview. Switching to gulp allows the site to only rebuild frontend files that have changed, and it builds them as soon as they change instead of building them on-demand.

For more details, pmac wrote a blog post describing the switch.

Open-source Citizenship

Here we talk about libraries we’re maintaining and what, if anything, we need help with for them.

Google Analytics Pageviews on Non-Web Requests

peterbe shared a blog post he wrote describing how to use Raven to send pageview data to Google Analytics. This is useful for tracking usage of endpoints that don’t return webpages but are still considered part of your site’s public API.

Domainswitcher

peterbe also shared Domainswitcher, and add-on that lets you easily switch between domains while preserving the current path. The add-on is useful for web developers working on sites that want to switch between prod, staging, development, and locally-hosted instances of the site.

New Hires / Interns / Volunteers / Contributors

Here we introduce any newcomers to the Webdev group, including new employees, interns, volunteers, or any other form of contributor.

If you’re interested in web development at Mozilla, or want to attend next month’s Extravaganza, subscribe to the dev-webdev@lists.mozilla.org mailing list to be notified of the next meeting, and maybe send a message introducing yourself. We’d love to meet you!

See you next month!

https://blog.mozilla.org/webdev/2016/07/14/extravaganza-june-2016/

This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

https://air.mozilla.org/reps-weekly-20160714/

They say a Mozilla Web QA team member is the most fearless creature in the world. They say their jaws are powerful enough to crush...

https://air.mozilla.org/web-qa-team-meeting-8/

I posted an update to the Firefox Roadmap.

Firefox will deliver a rock solid browsing experience with world-beating customization and a first of its kind recommendation engine that gets you the content you want when you want it, whether at home or on the go.

https://asadotzler.com/2016/07/14/firefox-roadmap/

Project SensorWeb is an experiment from the Connected Devices group at Mozilla in open publishing of environmental data. I am excited about this experiment because we’ve had some serious air quality discoveries in Portland recently – our air is possibly the worst in the USA, and bad enough that mega-activists like Erin Brockovich are getting involved.

A couple of weeks ago, Eddie and Evan from Project SensorWeb helped me put together a NodeMCU board and a PM2.5 sensor so I could set up an air quality sensor in Portland to report to their network. They’re still setting up the project so I haven’t gotten the configuration info from them yet…

But you don’t need the SensorWeb server to get your sensor up and running and pushing data to your own server! I want a copy of the data for myself anyway, to be able to do my own visualizations and notifications. I can then forward the data on to SensorWeb.

So I started by flashing the current version of the SensorWeb code to the device, which is a Nodemcu 0.9 board with an ESP8266 wifi chip on board, and a PM2.5 sensor attached to it.

I used Kumar Rishav’s excellent step-by-step post to get through the process.

Some things I learned along the way:

• On Mac OS X you need a serial port driver in order for the Arduino IDE to detect the board.
• After much gnashing of teeth, I discovered that you can’t have the PM2.5 sensor plugged into the board when you flash it.

After getting the regular version flashed correctly, I tested with Kumar’s API key and device id, and confirmed it was reporting the data correctly to the SensorWeb server.

Now for the changes.

• I set up the Maker channel on IFTTT, which allows me post data to an HTTP endpoint to get it into IFTTT’s system.
• I then created a new IFTTT recipe that accepts the data from the device and pushes it into a Google spreadsheet.
• I forked the SensorWeb code and modified it to post to the Maker channel instead of the SensorWeb server.

I flashed the device and viola, it is publishing data to my spreadsheet.

And now once SensorWeb is ready to take new devices, I can set up a new IFTTT recipe to forward the posts to them, allowing me to own my own data and also publish to the project!

https://autonome.wordpress.com/2016/07/13/harvesting-air-quality-data-with-a-nodemcu-sensorweb-and-ifttt/

This post should find its way to the Planet Mozilla twitter feed; if it does, new posts to Planet will be reflected there again.

(Pic cropped out of the “Halo: ODST” trailer from when it was still called called “Recon”. Reinitialize…)

http://exple.tive.org/blarg/2016/07/13/reinitialize/

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 1278 listed add-ons were reviewed:

• 1194 (93%) were reviewed in fewer than 5 days.
• 62 (5%) were reviewed between 5 and 10 days.
• 22 (2%) were reviewed after more than 10 days.

There are 74 listed add-ons awaiting review.

You can read about the recent improvements in the review queues here.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers are critical for our success, and can earn cool gear for their work. Visit our wiki page for more information.

Compatibility

The compatibility blog post for Firefox 48 is up, and the bulk validation was run. The post for Firefox 49 is also up and the bulk validation will be run in the coming weeks.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to remove the signing override preference in Firefox 48. The unbranded builds, which were the final piece, are available here. We will update the Extension Signing doc with more information about how to obtain them.

Recognition

We would like to thank these people for their recent contributions to the add-ons world: Sylwia Ornatowska, dw-dev, Lavish Aggarwal, Baris Derin, Martin Giger, Viswaprasath, gorf4673, and Atique Ahmed Ziad.

You can read more about their contributions in our recognition page.

https://blog.mozilla.org/addons/2016/07/13/add-ons-update-84/

mconley livehacks on real Firefox bugs while thinking aloud.

https://air.mozilla.org/the-joy-of-coding-episode-63/

One of the areas we have been focusing on lately is getting crashes on file for Nightly. The Platform team created Project Uptime to specifically focus on improving our crash situation on Desktop and Mobile. I immediately was interested in being a part of Project Uptime since I have always enjoyed investigating crashes.

The Uptime effort helps the overall Nightly product development for several reasons:

• Identifies issues early to make the product better
• Allows us to quickly identify regression ranges
• Helps catch crashes in Nightly before they might move to Aurora
• Keeps Nightly stable so we can retain users

My Typical Workflow

Once a week I look at the crashes in Crash Stats. We have a set of queries we reference that help make it easier to drill down by Platform as well as by type of crash.

Where it starts

If I see a new signature that doesn’t have a bug associated with it, I begin looking at the crashes in that signature. On Uptime we are usually looking at a crash volume on Nightly of 10 times a day or more, across multiple installations. On platforms such as Mac and Linux where we have less crash volume, I might file a bug that has less volume than that of a Windows crash.

An Example

Bug 1284051  is a good example of a bug I caught recently that was a small volume regression. The link to all the crashes showed me in what build the crash started. In this case the crash started with Build ID 20160630030207 and then continued in the Nightly builds for several days.

I start the process by looking at the set of crash reports and determining if they are from a set of users or from an individual user. In the screenshot below you can see that the install times are all different for this particular crash:

Note that there are sometimes crash spikes with a particular signature, but they all come from a single installation and turn out to be duplicates. In the typical Uptime workflow we ignore these, because it’s difficult to tell if it’s a actually a real problem or a specific problem with the user’s machine or installation.

I then look at an individual crash report and determine what stack we may have crashed in. The “Source”column in the attached screenshot may give me some clues about who last worked in that area of code.

In this particular example I was able to find “nsilva” had worked in that area by clicking on the second link, so I added a “needinfo” on him in the Bugzilla bug to see if he could help me figure out what might be causing the crash. One thing to remember is that although the Source column can be useful, you really need to expand the “Show Other Threads” to see the full picture (and you may need the help of a developer to untangle what is going on – I often do). You can also reference the Module Owners list if you are not sure who oversees a particular area of code. Lots of times you may not know where to bucket the crash – and when this happens don’t be afraid to ask for help (IRC is your best friend).

All of the information I find that is relevant goes into the bug report. Other items I may add include:

• Module or addon correlations
• Crash URLs, if there is trend
• Added comments, if there is a trend
• Uptime range if it is a startup crash

Other helpful items to include in the bug report (from the Uptime page):

• From about:support: The Nightly build id, which looks like “20160506052823”
• Number of crashes that have occurred with this signature. I usually paste a link which includes all the crashes across branches, or on a particular branch if it is branch specific.
• Crash rank (e.g. “this is the #1 top crash for Nightly 20160506052823”)
• Number of installations
• For new signatures, which Nightly build the crash started in. This page explains an easy way to search for this in Crash Stats.
• When possible, a regression window for that Nightly.  Adding “regression” and “regressionwindow-wanted” to the keyword field will also help trigger someone to help.
• When possible, an indication of which bug’s patches may have caused the crash.
• To get the attention of Release Drivers, nominate the bug by setting the appropriate tracking flag to ‘?‘ in the bug report.

This bug had a happy ending as nsilva was able to address the crash with a null check.

Platform specific crashes are another interesting area I like to explore. Since I run the Mac developer builds, I look at crashes specific to the next Mac OS version daily. It is possible in Crash Stats to construct a query which will return only the crashes that are present on the most recent Sierra beta. This is useful to be able to see and address early issues while the OS is under development. (You can also help the effort by joining the Apple beta program and running Sierra with Firefox installed – more users helps us identify issues more quickly

https://blog.nightly.mozilla.org/2016/07/13/crash-investigation-in-firefox-nightly/