WebmakerPledge to teach web literacy!

We recently launched a new site for people interested in helping others read, write and participate on the Web. Here, you’ll find guides for hosting your first Maker Party event, details on how to start a Mozilla Club, lesson plans for teaching web literacy skills, and much more. In the coming months, we’ll be adding more content, as well as new ways for our global community to connect with one another.

If you’re committed to maintaining the Web as an open public resource for all, and want to share your knowledge with others, please take a moment to pledge to teach web literacy!

By taking this pledge on the Mozilla Learning Network website, you’ll be signaling your interest to help us achieve our goal of universal web literacy. We truly can’t do it without your help.

More people need to know and understand the full potential of the Web. At Mozilla, we believe web literacy is as important as reading, writing and arithmetic. When you know how the Web works, you can use it as a creative platform. You can better understand what/how/who you’re sharing information with. And you can help share and shape its future.

Here’s how it works:

1. Visit teach.mozilla.org and click “Pledge to Teach”
2. Submit your email address to take the pledge
3. Share your pledge on Facebook and Twitter

Pledge to teach the web

We’ll follow up to learn a bit more about how we can help you fulfill your pledge, whether it’s pointing you to opportunities to develop your own leadership and mentoring skills, sharing free activities and lesson plans to teach web literacy skills to your learners, or connecting you with others in your region to have even greater impact in your local community.

Thanks in advance for joining us to #teachtheweb!

SeaMonkeySeaMonkey Win32 Trunk (2.39a1) nightly

After about a month  or so of ‘decrypting’ the required steps to creating nightlies, I have finally been able to build and upload Win32 Trunk nightly to http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly.

There are a few items that I need to mention:

1) Complete and partial snippets are not available.  This means (unfortunately) when installing a new nightly, it requires (I believe) uninstalling the previous one and installing the new nightly.  (I haven’t tested out the theory that you can install on top of the current nightly provided it is from the same version.)

2) While I have tried to keep in tune with the actual buildbot steps, there were some ‘liberties’ that I took to get the process working.  (tl;dr;, I basically ‘translated’ buildbot steps into Windows batch files. i.e. python code -> batch file)  As such, while the environment is the same as ‘what we would have when we have our Windows slaves migrated to Win2008R2′,  the actual build process is ‘different’ (read: manual).  So please treat these nightlies as ‘partial contributed’.

3) I’m working on the l10n repacks now (scary stuff) and probably with the same caveat that there won’t be any complete and partial snippets.

4) Once the repacks are done working, I will be working on figuring out the release process steps (which is a lot more involved, but thankfully, a lot of the build processes are similar to the nightlies).

Again, I thank everyone for your patience with me.

:ewong

SUMO BlogWhat’s up with SUMO – 3rd July

Hello, SUMO Nation! We are all (mostly) back from our recent Work Week in Whistler (also known as #mozwww on Twitter). So, what happened in Whistler? We had quite a few meetings, discussions, and chats – and some fun, too! … Continue reading

about:communityMDN at Whistler

The MDN community was well-represented at the Mozilla “Coincidental Work Week” in Whistler, British Columbia, during the last week in June. All of the content staff, a couple of the development staff, and quite a few volunteers were there. Meetings were met, code was hacked, docs were sprinted, and fun was funned.

Cross-team conversations

One of the big motivations for the “Coincidental Work Week” is the opportunity for cross-pollination among teams, so that teams can have a high-bandwidth conversations about their work with others. MDN touches many other functional groups within Mozilla, so we had a great many of these conversations. Some MDN staff were also part of “durable” (i.e., cross-functional) teams within the Engagement department, meeting with product teams about their marketing needs. Among others, MDN folks met with:

  • Add-ons, about future plans for add-ons.
  • Mozilla Foundation, about MDN’s role in broader learning initiatives, and about marketing themes for the last half of the year.
  • Firefox OS, about their plans in the next six months, and about increasing participation in Firefox OS.
  • Developer Relations and Platform Engineering, about improving coordination and information sharing.
  • Firefox Developer Tools, about integrating more MDN content into the tools, and making the dev-tools codebase more accessible to contributors.
  • Participation, to brainstorm ways to increase retention of MDN contributors.

Internal conversations

The MDN community members at Whistler spent some time as a group reflecting on the first half of the year, and planning and prioritizing for the second half of the year. Sub-groups met to discuss specific projects, such as the compatibility data service, or HTML API docs.

Hacking and sprinting

Lest the “Work Week” be all meetings, we also scheduled time for heads-down productivity. MDN was part of a web development Hack Day on Wednesday, and we held doc sprints for most of the day on Thursday and Friday. These events resulted in some tangible outputs, as well as some learning that will likely pay off in the future.

  • Heather wrote glossary entries and did editorial reviews.
  • Sebastian finished a new template for CSS syntax.
  • Sheppy worked on an article and code sample about Web RTC.
  • Justin finished a prototype feature for helpfulness ratings for MDN articles.
  • Saurabh prototyped an automation for badge nominations, and improved CSS reference pages’ structure and syntax examples.
  • Klez got familiar with the compatibility service codebase and development workflow; he also wrote glossary entries and other learning content.
  • Mark learned about Kuma by failing to get it running on Windows.
  • Will finished a patch to apply syntax highlighting to the CSS content from MDN in Dev Tools.

And fun!

Of course, the highlight of any Mozilla event is the chance to eat, drink, and socialize with other Mozillians. Planned dinners and parties, extracurricular excursions, and spontaneous celebrations rounded out the week. Many in the MDN group stayed at a hotel that happened to be a 20-minute walk from most of the other venues, so those of us with fitness trackers blew out our step-count goals all week. A few high points:

  • Chris celebrated his birthday at the closing party on Friday, at the top of Whistler mountain.
  • Mark saw a bear, from the gondola on the way up to the mountain-top party.
  • Saurabh saw snow for the first time. In June, no less.

    Open Policy & AdvocacyDecisive moment for net neutrality in Europe

    After years of negotiations, the E.U. Telecom Single Market Regulation (which includes proposed net neutrality rules) is nearing completion. If passed, the Regulation will be binding on all E.U. member states. The policymakers – the three European governmental bodies:  the Parliament, the Commission, and the Council – are at a crossroads: implement real net neutrality into law, or permit net discrimination and in doing so threaten innovation and competition. We urge European policymakers to stand strong, adopt clear rules to protect the open Internet, and set an example for the world.

    At Mozilla, we’ve taken a strong stance for real net neutrality, because it is central to our mission and to the openness of the Internet. Just as we have supported action in the United States and in India, we support the adoption of net neutrality rules in Europe. Net neutrality fundamentally protects competition and innovation, to the benefit of both European Internet users and businesses. We want an Internet where everyone can create, participate, and innovate online, all of which is at risk if discriminatory practices are condoned by law or through regulatory indifference.

    The final text of European legislation is still being written, and the details are still gaining shape. We have called for strong, enforceable rules against blocking, discrimination, and fast lanes are critical to protecting the openness of the Internet. To accomplish this, the European Parliament needs to hold firm to its five votes in the last five years for real net neutrality. Members of the European Parliament must resist internal and external pressures to build in loopholes that would threaten those rules.

    Two issues stand out as particularly important in this final round of negotiations: specialized services and zero-rating. On the former, specialized services – or “services other than Internet access services” – represent a complex and unresolved set of market practices, including very few current ones and many speculative future possibilities. While there is certainly potential for real value in these services, absent any safeguards, such services risk undermining the open Internet. It’s important to maintain a baseline of robust access, and prevent relegating the open Internet to a second tier of quality.

    Second, earlier statements from the E.U. included language that appeared to endorse zero-rating business practices. Our view is that zero-rating as currently implemented in the market is not the right path forward for the open Internet. However, we do not believe it is necessary to address this issue in the context of the Telecom Single Market Regulation. As such, we’re glad to see such language removed from more recent drafts and we encourage European policymakers to leave it out of the final text.

    The final text that emerges from the European process will set a standard not only for Europe but for the rest of the world. It’s critical for European policymakers to stand with the Internet and get it right.

    Chris Riley, Head of Public Policy
    Jochai Ben-Avie, Internet Policy Manager

    hacks.mozilla.orgHow fast are web workers?

    The next version of Firefox OS, the mobile operating system, will unleash the power of devices by taking full advantage of their multi-core processors. Classically, JavaScript has been executed on a single thread, but web workers offer a way to execute code in parallel. Doing so frees the browser of anything that may get in the way of the main thread so that it can smoothly animate the UI.

    A brief introduction to web workers

    There are several types of web workers:

    They each have specific properties, but share a similar design. The code running in a worker is executed in its own separate thread and runs in parallel with the main thread and other workers. The different types of workers all share a common interface.

    Web workers

    Dedicated web workers are instantiated by the main process and they can communicate only with it.

    Shared workers

    Shared workers can be reached by all processes running on the same origin (different browser tabs, iframes or other shared workers).

    Service workers

    Service workers have gained a lot of attention recently. They make it possible to proxy a web server programmatically to deliver specific content to the requester (e.g. the main thread). One use case for service workers is to serve content while offline. Service workers are a very new API, not fully implemented in all browsers, and are not covered in this article.

    In order to verify that web workers make Firefox OS run faster, we need to validate their speed by benchmarking them.

    The cost of creating web workers

    This article focuses on Firefox OS. All measurement are made on a Flame device, powered by middle-end hardware.

    The first set of benchmarks will look at the time it takes to create web workers. To do that, we set up a script that instantiates a web worker and sends a minimal message, to which the worker replies immediately. Once the response is received by the main thread, the time that the operation takes is calculated. The web worker is destroyed and the operation is repeated enough times to get a good idea of how long it takes on average to get a functional web worker. Instantiating a web worker is as easy as:

    // Start a worker.
    var worker = new Worker('worker-script.js');
     
    // Terminate a worker.
    worker.terminate();

    The same method is applied to the creation of broadcast channel:

    // Open a broadcast channel.
    var channel = new window.BroadcastChannel('channel-name');
     
    // Close a broadcast channel.
    channel.close();

    Shared workers can’t really be benchmarked here because once they are created, the developer can’t destroy them. The browser is entirely responsible for their lifetime. For that reason, we can’t create and destroy shared workers at will to get a meaningful benchmark.

    Web workers take about 40 ms to be instantiated. Also, this time is pretty stable with variations of only a few milliseconds. Setting up a broadcast channel is usually done within 1 ms.

    Under normal circumstances, the browser UI is refreshed at a rate of 60 frames per second. This means that no JavaScript code should run longer than the time needed by a frame, i.e., 16.66ms (60 frames per second). Otherwise, you may introduce jankiness and lag in your application.

    Instantiating web workers is pretty efficient, but still may not fit in the time allocated for a single frame. That’s why it’s important to create as few web workers as possible and reuse them.

    Message latency

    A critical aspect of web workers is having fast communication between your main thread and the workers. There are two different ways the main browser thread can communicate with a web worker.

    postMessage

    This API is the default and preferred way to send and receive messages from a web worker. postMessage() is easy to use:

    // Send a message to the worker.
    worker.postMessage(myMessage);
     
    // Listen to messages from the worker.
    worker.onmessage = evt => {
      var message = evt.data;
    };

    Broadcast Channel

    This is a newly implemented API, only available in Firefox at the time of this writing. It lets us broadcast messages to all contexts sharing the same origin. All browser tabs, iframes, or workers served from the same origin can emit and receive messages:

    // Send a message to the broadcast channel.
    channel.postMessage(myMessage);
     
    // Listen to messages from the broadcast channel.
    channel.onmessage = evt => {
      var message = evt.data;
    };

    To benchmark this, we use a script similar to the one described above, except that the web worker is not destroyed and reused at each operation. The time to get a round trip response should be divided by two.

    As you might expect, the simple postMessage is fast. It usually takes between 0 to 1 ms to send a message, whether to a web or shared worker. Broadcast channel API takes about 1 to 2 ms.

    Under normal circumstances, exchanging messages with workers is fast and you should not feel too concerned about speed here. However, larger messages can take longer.

    The size of messages

    There are 2 ways to send messages to web workers:

    • Copying the message
    • Transferring the message

    In the first case, the message is serialized, copied, and sent over. In the latter, the data is transferred. This means that the original sender can no longer use it once sent. Transferring data is almost instantaneous, so there is no real point in benchmarking that. However, only ArrayBuffer is transferable.

    As expected, serializing, copying, and de-serializing data adds significant overhead to the message transmission. The bigger the message, the longer it takes to be sent.

    The benchmark here sends a typed array to a web worker. Its size is progressively increased at each iteration. There is a linear correlation between size of the message and transfer time. For each measurement, we can divide the size (in kilobytes) by the time (in milliseconds) to get the transfer speed in kb/ms.

    Typically, on a Flame, the transfer speed is 80 kB/ms for postMessage and 12 kB/ms using broadcast channel. This means that if you want your message to fit in a single frame, you should keep it under 1,300 kB with postMessage and under 200 kB when using the broadcast channel. Otherwise, it may introduce frame drop in your application.

    In this benchmark, we use typed arrays, because it makes it possible to determine their size in kilobytes precisely. You can also transfer JavaScript objects, but due to the serialization process, they take longer to post. For small objects, this doesn’t really matter, but if you need to send huge objects, you may as well serialize them to a binary format. You can use something similar to Protocol Buffer.

    Web workers are fast if used correctly

    Here is a quick summary of various benchmarks related to web workers, as measured on a Flame:

    Operation Value
    Instantiation of a web worker 40 ms
    Instantiation of a broadcast channel 1 ms
    Communication latency with postMessage 0.5 ms
    Communication latency with broadcast channel 1.5 ms
    Communication speed with postMessage 80 kB/ms
    Communication speed with broadcast channel 12 kB/ms
    Maximum message size with postMessage 1,300 kB
    Maximum message size with broadcast channel 200 kB

    Benchmarking is the only way to make sure that the solution you are implementing is fast. This process takes much of the guesswork out of web development.

    If you want to run these benchmarks on a specific device, the app I built to make these measurements, web workers benchmark, is open source. You are also welcome to contribute by submitting new types of benchmarks.

    Firefox AppsFriend of Marketplace: Atique Ahmed Ziad

    Our newest Friend of Marketplace is  Atique Ahmed Ziad! Atique is an app developer, Marketplace code contributor,  and evangelist based in Bangladesh.

    He is also an avid bug-squasher and app curation board member, and has been mentoring other code contributors to fix bugs on Marketplace.

    “I love to contribute to Mozilla’s codebase, since it gives me a chance to make my written code visible to millions of people. It gives me a chance to take part in something big, which I can surely be proud of.”

    Thanks to Atique for all his contributions to Firefox Marketplace!

    A special shout-out goes to everyone who made a difference in June, including Shivee Gupta and Zunaid Amin Enan, who were mentored by Atique.

    The new contribution wiki for July is now available. Please check it for projects that might interest you, and be sure to report your contributions as well as the contributions of others in your community!

    The Mozilla BlogNew Sharing Features in Firefox

    Whichever social network you choose, it’s undeniable that being social is a key part of why you enjoy the Web. Firefox is built to put you in control, including making it easier to share anything you like on the Web’s most popular social networks. Today, we’re announcing that Firefox Share has been integrated into Firefox Hello. We introduced Firefox Share to offer a simple way of sharing Web content across popular services such as Facebook, Twitter, Tumblr, LinkedIn and Google+ and other social and email services  (full list here) to help you share anything on the Web with any or all of your friends.

    Firefox Hello link sharing

    Firefox Hello, which we’ve been developing in beta with our partner, Telefonica, is the only in-browser video chat tool that doesn’t require an account or extra software downloads. We recently added screen sharing to Firefox Hello to make it easier to share anything you’re looking at in your video call. Now you can also invite friends to a Firefox Hello video call by sharing a link via the social network or email account of your choice, all without leaving your browser tab. That includes a newly added Yahoo Mail integration in Firefox Share that lets Yahoo Mail users share Hello conversation links or other Web content directly from Firefox Share.

    For more information:
    Release Notes for Firefox for Windows, Mac, Linux
    Release Notes for Android
    Download Firefox

    Air MozillaGerman speaking community bi-weekly meeting

    German speaking community bi-weekly meeting https://wiki.mozilla.org/De/Meetings

    Hive Learning Network NYCMaker Prom 2015

    This is a blog post by Amelia Marsh, Summer Intern at Mozilla Hive NYC.

    Before I start this blog post in earnest, I want to introduce myself. I’m Amelia Marsh, I’m a student at the University of Arizona (located in Tucson, AZ) and I’m a member of a youth design team, who designs and influences the way that the Pima County Public Library’s 101 Youth Space functions and interacts with the Tucson community.

    Working at the 101 Space has defined how I look at learning and success, giving me a new pair of eyes around my own abilities and my potential for encouraging inspiration, success, and power in other students. I’m so excited to continue learning and working around educational innovation and networks, especially as a NYC rookie who can offer a unique perspective informed by the differences between my desert hometown and arguably the world’s most iconic city.

    The first event that I attended as part of my blogger/intern duties was Maker Prom. For those who don’t know, it’s a celebration created for the high and middle school-aged winners of the national Scholastic Awards in Art & Writing. For me, it was fascinating, comforting, and straight-up FUN.

    working hard on zinse

    New friends

    Whether you’re a seasoned organizer, a high school student in New York for the first time, or a newly assigned intern on her first assignment, there’s always a little bit of nervousness at the beginning of an event. I felt it as I wandered through the opulent Roosevelt Hotel in search of the Mozilla Hive NYC Team. With help from a security guard in the lobby and after a walk through a hallway populated almost entirely by the ribbons hanging off of balloons, I found the ballroom: full of organizers, waiting to be full of teenagers.

    And soon it was. Around 650 of them, all told. They moved like a slow river,

    experimenting with Mozilla Webmaker app,

    to fashion sketching with the Savannah College of Art and Design,

    to making LED circuit corsages with Blink Blink,

    to making music with littleBits synthkits,

    to mixing hot glue and LEDs in molds to make wearable bling with New York Hall of Science,

    to making light-up prom accessories with Stoked on STEAM

    to writing visual poetry with Parsons New School,

    to collaging, writing, and conceptualizing zines with Scholastic,

    to making music with Carnegie Hall and Building Beats,

    to playing with Oculus Rift and motion sensing robots with Maker State,

    to taking sonic prom portraits with Building Beats,

    Little rivulets included photo ops and free chips, and the lake was the dance floor, which was packed by the end of the night.

    Zine Making

    Zine-Making

    Maker Prom is a somewhat unique event because it works to bring a lot of teenagers with separate geographical experiences together to celebrate their collective achievements. And honestly, it worked. That’s one of the really amazing things about making stuff. It’s a great icebreaker. The concept of icebreaker sounds cliché as I write it, but forging relationships is vital for personal growth and happiness, and breaking the kinetic energy of shyness to begin those relationships can be hard. However, when you and a new person are exploring a creative technology there’s plenty of ways to start a conversation.

    I did this a lot at Maker Prom as I wandered around with Mozilla’s camera. I asked organizers what they had planned, but I also asked the teenagers what they were making. I sat next to a girl named Eden for 15 minutes as we worked on small zines. Both were a messy mixes of stickers, glitter paint, and newspaper clippings. Mine said “NYC”, her’s said “Art is Alive.”We shared our embarrassment at their simplicity, but she also told me about the story that got her the award that got her to this place, and about her friends and how New York City always manages to magic and new and full of possibilities. One of her favorite books is The Goldfinch by Donna Tartt.

    Making is a great conversation starter, but it’s more than a gimmick. A good conversation is fun and exploratory, and so is making a flashing dinosaur barrette out of hot glue, a mold, and an LED light. And let me tell you, I did not understand how that was going to happen until someone else explained it to me. And once I did understand, I wanted to explain it to everyone in the room. This kind of creativity necessarily exists in a community. I think that Eden said it best: art is alive.

    More photos on flickr!

    The post Maker Prom 2015 appeared first on Hive NYC.

    Mozilla Add-ons BlogT-Shirt Form Data Exposure

    On Monday, June 15, 2015 Mozilla announced on the Add-ons blog a free special edition t-shirt for eligible AMO developers. Eligible developers were requested to sign up via Google Form and asked to input their full name, full address, telephone number and T-shirt size.

    This document was mistakenly configured to allow potential public access for less than 24 hours, exposing the response data for 70 developers. As soon as the incident was discovered, we immediately changed the permission level to private access. Other than the developer who discovered and reported this incident, we are not aware of anyone without authorization accessing the spreadsheet.

    We have notified the affected individuals. We regret any inconvenience or concern this incident may have caused our AMO developer community.

    Air MozillaWeb QA Weekly Meeting

    Web QA Weekly Meeting This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.

    Air MozillaReps weekly

    Reps weekly Weekly Mozilla Reps call

    Meeting NotesMobile: 2015-07-01

    Schedule

    Topics for This Week

    Shipping as Add-ons
    Margaret and others have started work on shipping parts of Firefox as add-ons.
    Reducing APK Size
    Martyn landed code to remove MDPI assets from all builds.

    Tracking Review

    Beta

    • Next Build:
    ID Summary Status Assigned to Last change time
    789193 AMI_startup() takes 200ms on mobile, 26ms on desktop at startup NEW Jim Chen [:jchen] [:darchons] (nchen) 2015-04-21T19:20:16Z
    1120511 Autophone – Twitter Throbber stop regression 2015-01-15 REOPENED Seth Fowler [:seth] (seth) 2015-07-01T01:03:16Z
    1153844 Can’t select tracking flags on new bugs submitting page NEW 2015-04-24T12:19:40Z
    1163937 Downloads are not cleared from about:downloads when “Clear on exit” is used ASSIGNED :Margaret Leibovic (margaret.leibovic) 2015-07-01T22:37:56Z
    1169359 Investigate Fx Android interactions with Android M permission disabling ASSIGNED :Sebastian Kaspari (s.kaspari) 2015-06-12T09:25:11Z


    5 Total;
    5 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Aurora

    • Next Build:
    ID Summary Status Assigned to Last change time
    886969 Fennec allows scrolling of pages with overflow:hidden on the body element NEW James Willcox (:snorp) (jwillcox@mozilla.com) (snorp) 2015-06-05T18:15:38Z
    1016555 Disable OCSP checking for certificates covered by OneCRL ASSIGNED David Keeler [:keeler] (use needinfo?) (dkeeler) 2015-06-17T16:43:20Z
    1129614 Regression: Sometimes thumbnails in the tabs drawer are not updated, they expire ASSIGNED Mark Finkle (:mfinkle) (mark.finkle) 2015-07-02T02:57:32Z
    1132508 Last tab is cut off in tab tray after rotation REOPENED Martyn Haigh (:mhaigh) (mhaigh) 2015-06-11T00:50:03Z
    1144534 bad looking text depending on scroll NEW Timothy Nikkel (:tn) (tnikkel) 2015-05-14T17:30:29Z
    1164052 Autophone – intermittent Crash [unknown top frame] NEW 2015-06-18T17:08:38Z
    1170724 Autophone – 2015-05-20 Throbber start regression in S1S2 on fx-team NEW 2015-06-11T17:52:40Z
    1171337 black window during browsing NEW Randall Barker [:rbarker] (rbarker) 2015-06-11T17:55:55Z
    1179403 Private browsing ToolbarProgressView too dark NEW Michael Comella (:mcomella) (michael.l.comella) 2015-07-01T21:18:30Z
    1179407 Private browsing toolbar text background fades to wrong color NEW Michael Comella (:mcomella) (michael.l.comella) 2015-07-01T21:17:39Z


    10 Total;
    10 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Nightly

    • Next Build:
    ID Summary Status Assigned to Last change time
    1047127 Panning very stuttery on this page with overflow-x NEW 2015-06-10T18:43:44Z
    1114096 Wrong tab got mirrored NEW 2015-06-17T18:30:58Z
    1126244 Create a maximum reader mode cache size and evict records when necessary ASSIGNED Vivek Balakrishnan[:vivek] (vivekb.balakrishnan) 2015-04-30T17:08:28Z
    1131084 Can not mirror tab to Chromecast device NEW Randall Barker [:rbarker] (rbarker) 2015-06-17T18:31:14Z
    1148391 Tapping the bottom of the screen will make the reader mode toolbar bounce up and down NEW 2015-05-28T17:18:33Z
    1156553 Tab queue makes captive portal use annoying ASSIGNED Martyn Haigh (:mhaigh) (mhaigh) 2015-06-30T14:53:55Z
    1168867 Size of new Gecko selection carets doesn’t take font inflation into account NEW 2015-06-18T17:33:40Z
    1171860 Tapping the tab queue notification will open the link in normal browsing with “Open links in Private browsing” pref enabled NEW 2015-06-08T17:30:23Z


    8 Total;
    8 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Friends of the Mobile Team

    Give a shoutout/thanks to people for helping fix and test bugs. Make sure friends also get awarded a badge. New contributors are highlighted in bold.

    Stand ups

    Suggested format:

    • What did you do last week?
    • What are working on this week?
    • Anything blocking you?

    Please keep your update to under 2 minutes!

    James W. (snorp)

    • NEW HIRE: Dylan Roeh! He started this week in SFO, will be working remotely from Illinois
    • Fixed bug 1178961 – Crash on retrieving Gecko profile
    • Fixed bug 1167647 – Pass all of the content specific data to decoder, not just two bytes
    • Bounced bug 1171610 – Automatically use colorized warnings and errors if available
    • Playing with patches to remove the placeholder icon and border that shows up for images that are loading
    • Playing with a patch that disables the low-res tiles, and fades in the high-res ones when they are available, bug 1178376
    • Getting the first bits of the paint suppression work reviewed

    JChen

    Fixed
    Working on

    GCP

    • Last week:
      • Whistler
      • Agonize over frailty of technology
      • Reviews: VP8 Accell, SafeBrowsing/TP memory optimization
      • Review WebRTC bugs
    • This week:
      • Rebase/incorporate review comments for Video Sandboxing
      • Multiple list providers for SafeBrowsing
      • Cache update times for SafeBrowsing

    Eugen Sawin

    <Read Only>

    Fixed
    Working on

    Bryan Munar

    • Counting down the days before bNicholz gets home
    • Beating bNicholz at phone games while he’s on his honeymoon
    • Came up with teammate nicknames at Whistler: Chenxia –> Chenny or Chenny from the Block (margaret++)

    FIXED:

    WORKING ON (and nearly done with):

    WILL WORK ON AFTER:

    liuche

    Highlights:

    • Making first run prototypes for antlam with Import from Android
    • Finished the rest of doorhangers! sans Tracking Protection

    Present:

    karim

    Past:

    Present:

    Margaret

    Highlights:

    • Finishing up signed add-on work
    • High-res search icons for Android
    • Thinking about how to build features as add-ons

    Past:

    Present:

    jonalmeida

    • Learning basics on Android Sync and working on.
    • Current: 1145434 Use a system tray notification to show progress on Tab sending and receiving

    Past:

    Present:

    mcomella

    • Lint everything
      • Go home
      • Android lint
      • eslint is working, sort of
    • Private browsing colors

    Past:

    Present:

    rnewman

    Fixed
    Working on

    Sebastian

    • Currently: 1176207 Replace GridView implementation in Home Panels with RecyclerView implementation
    • Regressions: 1178703 Addons, 1178739 HomeProvider, 1178760 YouTube

    Everything:

    Martyn Haigh

    Past:

    • Meeting with antlam for tab queue v2 discussions
    • Walking up mountains, swimming in lakes, diving off bridges, snowball fights.

    Present:

    Ally

    • readonly due to mozflu from Whistler
    • in progress
      • Bug 1148524 – Add “edit login” option in about:passwords context menu
      • Whistler discussions: Kidfox & opening links in private browsing+tab queues
    • done
      • Bug 1136477 Unify terminology of Passwords/Logins for about:logins (nee about:passwords)
      • Bug 1141769 – Implement new style(unified) FHR/Telemetry password manager probes

    Emily

    Highlights:

    • #mozwww

    Past:

    Present:

    BLassey

    Fixed
    Working on

    Antlam

    • Past
    • Upcoming

    Robin

    So much Whistler. Wow.

    • Kinderfox for Tablets, nailing down v1 features with Karen, Sam, and Ally.
    • Wrapped up iOS UI bugs (mostly Reader View CSS).

    Supposed to be on PTO. ¯\_(ツ)_/¯

    • “Open later” Share Extension bug 1179067
    • Implement toggle unread for reading list items bug 1177936
    • Reflect local vs remote visits in Top Sites bug 1172072
    • Let other developers directly open pages in Firefox for iOS bug 1109684

    QA

    Feature Focus


    Details

    • Wednesdays – 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
    • Dial-in: conference# 99998
      • US/Toll-free: +1 800 707 2533, (pin 369) Conf# 99998
      • US/California/Mountain View: +1 650 903 0800, x92 Conf# 99998
      • US/California/San Francisco: +1 415 762 5700, x92 Conf# 99998
      • US/Oregon/Portland: +1 971 544 8000, x92 Conf# 99998
      • CA/British Columbia/Vancouver: +1 778 785 1540, x92 Conf# 99998
      • CA/Ontario/Toronto: +1 416 848 3114, x92 Conf# 99998
      • UK/London: +44 (0)207 855 3000, x92 Conf# 99998
      • FR/Paris: +33 1 44 79 34 80, x92 Conf# 99998
    • irc.mozilla.org #mobile for backchannel
    • Mobile Vidyo Room

    Meeting NotesFirefox/Gecko Delivery Planning: 2015-07-01

    Schedule & Progress onUpcoming Releases (Liz/Sylvestre/Lawrence)

    • 39 RC build6 is being tested now on the beta channel
    • we should know more in a few hours
    • maybe we can release later today

    Feedback Summary (Rob/Tyler/Matt)

    Desktop

    • Gathering feedback/files from users with start-up crash
    • Looking into potential Facebook video issue

    Mobile


    Planning Meeting Details

    • Wednesdays – 11:00am PT, 18:00 UTC
    • Mountain View Offices: Warp Core Conference Room
    • Toronto Offices: Finch Conference Room
    • irc.mozilla.org #planning for backchannel
    • (the developer meeting takes place on Tuesdays)

    Video/Teleconference Details – NEW

    hacks.mozilla.orgStreaming media on demand with Media Source Extensions

    Introducing MSE

    Media Source Extensions (MSE) is a new addition to the Web APIs available in all major browsers.  This API allows for things like adaptive bitrate streaming of video directly in our browser, free of plugins. Where previously we may have used proprietary solutions like RTSP (Real Time Streaming Protocol) and Flash, we can now use simpler protocols like HTTP to fetch content, and MSE to smoothly stitch together video segments of varied quality.

    All browsers that support HTMLMediaElements, such as audio and video tags, already make byte-range requests for subsequent segments of media assets.  One problem is that it’s up to each browser’s implementation of a media engine to decide when and how much to fetch.  It’s also tough to stitch together or deliver smooth playback of segments of different quality without pauses, gaps, flashes, clicks, or pops.  MSE gives us finer-grained control at the application level for fetching and playing back content.

    In order to begin streaming, we need to figure out how to transcode our assets into a meaningful byte format for browsers’ media engines, determine what abstractions MSE provides, and figure out how to instruct the browser to play them back.

    Having multiple resolutions of content allows us to switch between them while maintaining a constant viewport size.  This is known as upscaling, and it’s a common technique for real-time rendering in video games to meet a required frame time.  By switching to a lower quality video resolution, we can meet bandwidth limitations at the cost of fidelity.  The loss of fidelity causes such artifacts as aliasing, in which curves appear jagged and blocky.  This technique can often be seen by Netflix subscribers during peak viewing hours.

    Rather than having an advanced protocol like RTSP handle bandwidth estimates, we can use a simpler network protocol like HTTP and move the advanced logic up one level into the application logic.

    Transcoding

    My recommended tools, ffmpeg and Bento4, are both free and open-source software (FOSS). ffmpeg is our Swiss army knife of transcoding, and Bento4 is a collection of great tools for working with mp4.  While I’m partial to non-licensed codecs like webm/vp8-9/opus, current browser support for those containers and codecs is rather poor, so in this post we’ll just be working with mp4/h.264/aac.  Both of the tools I’m working with are command line utilities; if you have nice GUI tools in your asset pipeline you’d like to recommend to our readers, let us know in the comments below.

    We’ll start with a master of some file, and end up transcoding it into multiple files each of smaller resolutions, then segmenting the smaller-res whole files into a bunch of tiny files.  Once we have a bunch of small files (imagine splitting your video into a bunch of 10-second segments), the client can use more advanced heuristics for fetching the preferred next segment.

    MSE multiple resolutions

    Our smaller-res copies of the master asset

     Proper fragmentation

    When working with mp4 and MSE, it helps to know that the mp4 files should be structured so that metadata is fragmented across pieces of the container, and across the actual audio/video streams being fragmented, instead of clustered together.  This is specified in the ISO BMFF Byte Stream Format spec, section 3:

    “An ISO BMFF initialization segment is defined in this specification as a single File Type Box (ftyp) followed by a single Movie Header Box (moov).”

    This is really important: Simply transcoding to an mp4 container in ffmpeg does not have the expected format and thus fails when trying to play back in a browser with MSE.  To check and see if your mp4 is properly fragmented, you can run Bento4’s mp4dump on your mp4.

    If you see something like:

      $ ./mp4dump ~/Movies/devtools.mp4 | head
      [ftyp] size=8+24
        ...
      [free] size=8+0
      [mdat] size=8+85038690
      [moov] size=8+599967
        ...

    Then your mp4 won’t be playable since the [ftyp] “atom” is not followed immediately by a [moov] “atom.”  A properly fragmented mp4 looks something like this —

      $ ./mp4fragment ~/Movies/devtools.mp4 devtools_fragmented.mp4
      $ ./mp4dump devtools_fragmented.mp4 | head
      [ftyp] size=8+28
        ...
      [moov] size=8+1109
        ...
      [moof] size=8+600
        ...
      [mdat] size=8+138679
      [moof] size=8+536
        ...
      [mdat] size=8+24490
        ...
      ...

    — where mp4fragment is another Bento4 utility.  The properly fragmented mp4 has the [ftyp] followed immediately by a [moov], then subsequent [moof]/[mdat] pairs.

    It’s possible to skip the need for mp4fragment by using the -movflags frag_keyframe+empty_moov flags when transcoding to an mp4 container with ffmpeg, then checking with mp4dump:

      $ ffmpeg -i bunny.y4m -movflags frag_keyframe+empty_moov bunny.mp4
    Creating multiple resolutions

    If we want to switch resolutions, we can then run our fragmented mp4 through Bento4’s mp4-dash-encode.py script to get multiple resolutions of our video.  This script will fire up ffmpeg and other Bento4 tools, so make sure they are both available in your $PATH environment variable.

    $ python2.7 mp4-dash-encode.py -b 5 bunny.mp4
    $ ls
    video_00500.mp4 video_00875.mp4 video_01250.mp4 video_01625.mp4 video_02000.mp4
    Segmenting

    We now have 5 different copies of our video with various bit rates and resolutions. To be able to switch between them easily during playback, based on our effective bandwidth that changes constantly over time, we need to segment the copies and produce a manifest file to facilitate playback on the client.  We’ll create a Media Presentation Description (MPD)-style manifest file. This manifest file containing info about the segments, such as the threshold effective bandwidth for fetching the requisite segment.

    Bento4’s mp4-dash.py script can take multiple input files, perform the segmentation, and emit a MPD manifest that most DASH clients/libraries understand.

    $ python2.7 mp4-dash.py --exec-dir=. video_0*
    ...
    $ tree -L 1 output
    output
    ├── audio
    │   └── und
    ├── stream.mpd
    └── video
        ├── 1
        ├── 2
        ├── 3
        ├── 4
        └── 5
    
    8 directories, 1 file

    We should now have a folder with segmented audio and segmented video of various resolutions.

    MSE & Playback

    With an HTMLMediaElement such as an audio or video tag, we simply assign a URL to the element’s src attribute and the browser handles fetching and playback.  With MSE, we will fetch the content ourselves with XMLHttpRequests (XHRs) treating the response as an ArrayBuffer (raw bytes), and assigning the src attribute of the media element to a URL that points to a MediaSource object.  We may then append SourceBuffer objects to the MediaSource.

    Pseudocode for the MSE workflow might look like:

    let m = new MediaSource
    m.onsourceopen = () =>
      let s = m.addSourceBuffer('codec')
      s.onupdateend = () =>
        if (numChunks === totalChunks)
          m.endOfStream()
        else
          s.appendBuffer(nextChunk)
      s.appendBuffer(arrayBufferOfContent)
    video.src = URL.createObjectURL(m)
    

    Here’s a trick to get the size of a file: make an XHR with the HTTP HEAD method.  A response to a HEAD request will have the content-length header specifying the body size of the response, but unlike a GET, it does not actually have a body.  You can use this to preview the size of a file without actually requesting the file contents.  We can naively subdivide the video and fetch the next segment of video when we’re 80% of the way through playback of the current segment.  Here’s a demo of this in action and a look at the code.

    Note: You’ll need the latest Firefox Developer Edition browser to view the demo and test the code. More information below in the Compatibility section. The MSE primer from WebPlatform.org docs is another great resource to consult.

    My demo is a little naive and has a few issues:

    • It doesn’t show how to properly handle seeking during playback.
    • It assumes bandwidth is constant (always fetching the next segment at 80% playback of the previous segment), which it isn’t.
    • It starts off by loading only one segment (it might be better to fetch the first few, then wait to fetch the rest).
    • It doesn’t switch between segments of varying resolution, instead only fetching segments of one quality.
    • It doesn’t remove segments (part of the MSE API), although this can be helpful on memory constrained devices. Unfortunately, this requires you to re-fetch content when seeking backwards.

    These issues can all be solved with smarter logic on the client side with Dynamic Adaptive Streaming over HTTP (DASH).

    Compatibility

    Cross-browser codec support is a messy story right now; we can use MediaSource.isTypeSupported to detect codec support.  You pass isTypeSupported a string of the MIME type of the container you’re looking to play.  mp4 has the best compatibility currently. Apparently, for browsers that use the Blink rendering engine, MediaSource.isTypeSupported requires the full codec string to be specified.  To find this string, you can use Bento4’s mp4info utility:

    ./mp4info bunny.mp4| grep Codec
        Codecs String: avc1.42E01E

    Then in our JavaScript:

    if (MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E, mp4a.40.2"')) {
    // we can play this
    }

    — where mp4a.40.2 is the codec string for low complexity AAC, the typical audio codec used in an mp4 container.

    Some browsers also currently whitelist certain domains for testing MSE, or over-aggressively cache CORS content, which makes testing frustratingly difficult.  Consult your browser for how to disable the whitelist or CORS caching when testing.

    DASH

    Using the MPD file we created earlier, we can grab a high quality DASH client implemented in JavaScript such as Shaka Player or dash.js.  Both clients implement numerous features, but could use more testing, as there are some subtle differences between media engines of various browsers.  Advanced clients like Shaka Player use an exponential moving average of three to ten samples to estimate the bandwidth, or even let you specify your own bandwidth estimator.

    If we serve our output directory created earlier with Cross Origin Resource Sharing (CORS) enabled, and point either DASH client to http://localhost:<port>/output/stream.mpd, we should be able to see our content playing.  Enabling video cycling in Shaka, or clicking the +/- buttons in dash.js should allow us to watch the content quality changing.  For more drastic/noticeable changes in quality, try encoding fewer bitrates than the five we demonstrated.

    Shaka Player in Firefox Dev Edition

    Shaka Player in Firefox Developer Edition

    dash.js running in Firefox Developer Edition

    dash.js in Firefox Developer Edition

    In conclusion

    In this post, we looked at how to prep video assets for on-demand streaming by pre-processing and transcoding.  We also took a peek at the MSE API, and how to use more advanced DASH clients.  In an upcoming post, we’ll explore live content streaming using the MSE API, so keep an eye out.  I recommend you use Firefox Developer Edition to test out MSE; lots of hard work is going into our implementation.

    Here are some additional resources for exploring MSE:

    Mozilla Add-ons BlogAdd-ons Update – Week of 2015/07/01

    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.

    Add-ons Forum

    As we announced before, there’s a new add-ons community forum for all topics related to AMO or add-ons in general. The Add-ons category is already the most active one on the community forum, so thank you all for your contributions! The old forum is still available in read-only mode.

    The Review Queues

    • Most nominations for full review are taking less than 10 weeks to review.
    • 272 nominations in the queue awaiting review.
    • Most updates are being reviewed within 8 weeks.
    • 159 updates in the queue awaiting review.
    • Most preliminary reviews are being reviewed within 10 weeks.
    • 295 preliminary review submissions in the queue awaiting review.

    A number of factors have lead to the current state of the queues: increased submissions, decreased volunteer reviewer participation, and a Mozilla-wide event that took most of our attention last week. We’re back and our main focus are the review queues. We have a new reviewer on our team, who will hopefully make a difference in the state of the queues.

    If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

    Firefox 40 Compatibility

    The Firefox 40 compatibility blog post is up. The automatic compatibility validation will be run in a few weeks.

    As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) 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

    We announced that we will require extensions to be signed in order for them to continue to work in release and beta versions of Firefox. The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions.

    There’s a small change to the timeline: Firefox 40 will only warn about unsigned extensions (for all channels), Firefox 41 will disable unsigned extensions  by default unless a preference is toggled (on Beta and Release), and Firefox 42 will not have the preference. This means that we’ll have an extra release cycle before signatures are enforced by default.

    Electrolysis

    Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running content code in a different process than browser code. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

    We will be talking more about these changes in this blog in the future. For now we recommend you start looking at the available documentation.

    WebmakerWebmaker and Local Content Creation in Cambodia and Rwanda

    In January, the Mozilla Foundation partnered with Souktel Mobile Solutions to pilot new mobile content creation software in two countries: Cambodia and Rwanda. We showed that it’s possible for youth of any skill level to quickly become content creators and read, write and participate on the Web.

    With the same 60 participants, we have now started the next phase: a case study that explores web literacy and local content creation using Mozilla Webmaker. It’s part of our partnership with GSMA.

    Screen Shot 2015-07-01 at 8.48.07 AM

    Participants range from ages 18 to 37, are a mix of both genders, and are mainly first-time smartphone owners. The majority of participants access the Internet through mobile data, which is why Mozilla has worked hard to develop Webmaker for mobile.

    This second phase started in June with a workshop led by local Mozillians. Each participant was gifted a smartphone running Android 4.2 with Webmaker pre-installed. Participants were also given a basic introduction to the Webmaker app.

    Over the next four weeks, participants will be invited to create and share with the Webmaker app on their new smartphones. We will be observing their use of the Webmaker platform and individual profiles in order to better understand how people create local content, participate on the Web, and share in their community. Findings will shared in a report published with GSMA.

    So far, early interviews provided great insight into how people are using the Web. For example, 73% of participants are interested in using the Internet to learn skills and open up employment opportunities.

    More at the end of July!

    Screen Shot 2015-07-01 at 8.48.15 AM

    Firefox AppsFirefox Marketplace Introduces Mobile-Optimized Websites Into Content Fold

    Is this an app or a website? Does it matter?

    Is this an app or a website? Does it matter?

    Good content is good content. It doesn’t matter if that content comes in app or web form, as long as it offers a great experience on your mobile device. That’s why Firefox Marketplace just introduced mobile-optimized websites (MOW) into our ecosystem.

    From the name you can probably interpret what this type of content entails. Websites. Optimized. For mobile.

    The web is the greatest content ecosystem of all. It only makes sense to blend appropriate web content into Marketplace’s mobile discovery experience. We also want to help content creators by providing a distribution platform for which they can choose to develop just an MOW if that makes sense for them—as opposed to developing and maintaining both an app and website.

    There’s no need for apps and websites to compete. Should you engage with a news app or a website? Do you really care if you’re reading a breaking news headline in app or web form?

    Today, Marketplace offers a selective subset of MOWs across various categories. As the program evolves, we’ll explore ways the broader Mozilla community can submit MOWs to expand the breadth of content and participate in the curatorial process (if you’re interested in helping to curate content, please feel free to reach out to editor@mozilla.com and we’ll keep you informed of program developments).

    hacks.mozilla.orgTrainspotting: Firefox 39

    Note: Firefox 39 has been delayed due to a last-minute stability issue. It will be released later this week. We’ll update this post when the release occurs. Stay tuned!

    Trainspotting is a series of articles highlighting features in the lastest version of Firefox. A new version of Firefox is shipped every six weeks – we at Mozilla call this pattern “release trains.”

    A new version of Firefox is here, and with it come some great improvements and additions to the Web platform and developer tools. This post will call out a few highlights.

    For a full list of changes and additions, take a look at the Firefox 39 release notes.

    DevTools Love

    The Firefox Developer Tools are constantly getting better. We’re listening to developers on UserVoice, and using their feedback to make tools that are more powerful and easier to use. One requested feature was the ability to re-order elements in the Inspector:

    Editing and tweaking CSS Animations is easier than ever – Firefox 39 lets developers pause, restart, slow down, and preview new timings without having to switch applications.

    Menu of animation easing presets in the Inspector

    CSS Scroll Snap Points

    CSS Scroll Snap Points in action

    CSS Scroll Snap Points let web developers instruct the browser to smoothly snap element scrolling to specific points along an axis, creating smoother, easier to interact with interfaces with fewer lines of code.

    Improvements to Firefox on Mac OS X

    Firefox gets some Mac- specific improvements and updates in version 39:

    • Project Silk enabled – Improves scrolling and animation performance by more closely timing painting with hardware vsync. Read more about Project Silk.
    • Unicode 8.0 skin tone emoji – Fixed a bug in the rendering of skin tone modifiers for emoji.
    • Dashed line performance – Rendering of dotted and dashed lines is vastly improved. Check out the fixed bug for more information.

    Service Workers Progress

    Firefox’s implementation of the Service Workers API continues – fetch is enabled for workers and is now generally available to web content, and the Cache and CacheStorage are now available behind a flag.

    There’s lots more changes and improvements in Firefox 39 – check out the Developer Release Notes for developer-oriented changes or the full list of bugs fixed in this release. Enjoy!

    about:communityFirefox 39 new contributors

    With the release of Firefox 39, we are pleased to welcome the 64 developers who contributed their first code change to Firefox in this release, 55 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:

  • agrigas: 1135270
  • bmax1337: 967319
  • leo: 1134993
  • schtroumps31: 1130045
  • zmiller12: 1138873
  • George Duan: 1135293
  • Abhinav Koppula: 732688, 951695, 1127337
  • Alex Verstak: 1113431, 1144816
  • Alexandre Ratchov: 1144087
  • Andrew Overholt: 1127552
  • Anish: 1135091, 1135383
  • Anush: 418517, 1113761
  • Bhargav Chippada: 1112605, 1130372
  • Boris Kudryavtsev: 1135364, 1144613
  • Cesar Guirao: 1139132
  • Chirag Bhatia: 1133211
  • Danilo Cesar Lemes de Paula: 1146020
  • Daosheng Mu: 1133391
  • Deepak: 1039540
  • Felix Janda: 1130164, 1130175
  • Gareth Aye: 1145310
  • Geoffroy Planquart: 942475, 1042859
  • Gerald Squelart: 1121774, 1135541, 1137583
  • Greg Arndt: 1142779
  • Henry Addo: 1084663
  • Jason Gersztyn: 1132673
  • Jeff Griffiths: 1138545
  • Jeff Lu: 1098415, 1106779, 1140044
  • Johan K. Jensen: 1096294
  • Johannes Vogel: 1139594
  • John Giannakos: 1134568
  • John Kang: 1144782, 1146252
  • Jorg K: 756984
  • Kyle Thomas: 1137004
  • Léon McGregor: 1115925, 1130741, 1136708
  • Manraj Singh [:manrajsingh|Away till 21st June]: 1120408
  • Mantaroh Yoshinaga: 910634, 1106905, 1130614
  • Markus Jaritz: 1139174
  • Massimo Gervasini: 1137756, 1144695
  • Matt Hammerly: 1124271
  • Matt Spraggs: 1036454
  • Michael Weisz : 736572, 782623, 935434
  • Mitchell Field: 987902
  • Mohamed Waleed: 1106938
  • NiLuJe: 1143411
  • Perry Wagle: 1122941
  • Ponç Bover: 1126978
  • Quentin Pradet: 1092544
  • Ravi Shankar: 1109608
  • Rishi Baldawa: 1143196
  • Stéphane SCHMIDELY: 935259, 1144619
  • Sushrut Girdhari (sg345): 1137248
  • Thomas Baquet: 1132078
  • Titi_Alone : 1133063
  • Tyler St. Onge: 1134927
  • Vaibhav Bhosale: 1135009
  • Vidit23: 1121317
  • Wickie Lee: 1136253
  • Zimon Dai: 983469, 1135435
  • atlanto: 1137615
  • farhaan: 1073234
  • pinjiz: 1124943, 1142260, 1142268
  • qasim: 1123431
  • ronak khandelwal: 1122767
  • uelis: 1047529
  • Meeting NotesMozilla Project: 2015-06-29

    • Every Monday @ 11:00am Pacific Time (19:00 UTC)
    • http://air.mozilla.org/ to watch and listen
    • join irc.mozilla.org #airmozilla for backchannel discussion
    • Presenters only: Vidyo room “Brownbags”. Do not use this room if you’re not planning to speak.
    • Dial-in: conference# 8600
      • US/Toll-free: +1 800 707 2533, (pin 369) Conf# 8600
      • US/California/Mountain View: +1 650 903 0800, x92 Conf# 8600
      • US/California/San Francisco: +1 415 762 5700, x92 Conf# 8600
      • US/Oregon/Portland: +1 971 544 8000, x92 Conf# 8600
      • CA/British Columbia/Vancouver: +1 778 785 1540, x92 Conf# 8600
      • CA/Ontario/Toronto: +1 416 848 3114, x92 Conf# 8600
      • UK/London: +44 (0)207 855 3000, x92 Conf# 8600
      • FR/Paris: +33 1 44 79 34 80, x92 Conf# 8600

    All-hands Status Meeting Agenda

    Items in this section will be shared during the live all-hand status meeting.

    Friends of Mozilla

    • Mozilla Rep Michaela R Brown for coming to SF to support our presence at the Library Freedom Project: Digital Rights in Libraries happening today and tomorrow at Noisebridge (Want to attend? it’s free, you can just drop by the NoiseBridge space at 2169 Mission, 1-7pm)

    Upcoming Events

    Wednesday, 01 July
    • Homebrew Website Club Meetup (every other Wednesday)
    • Be independent with your web browser and your web site.

      • San Francisco (@MozSF)
      • 17:30-18:30 Writing Hour
      • 18:30-19:30 IndieWeb meetup & hack night

        Create or update your personal web site — wherever you host it, shared, VPS, or at home; static, dynamic, WordPress, or other software.

        Join a community with like-minded interests. Bring friends that want a personal site!

        Any questions? See the wiki page for details
        or join IRC: http://indiewebcamp.com/irc/today?beta#bottom

    Project Status Updates (voice updates)

    Mozilla Advocacy

    Non-verbal update: Check out this Washington Post op-ed authored by Mozilla’s Dave Steer, which spotlights the Ford-Mozilla Open Web Fellows.

    Speakers

    The limit is 3 minutes per topic. It’s like a lightning talk, but don’t feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week.

    Presenter Title Topic Location Share? Media More Details
    Who Are You? What Do You Do? What are you going to talk about? Where are you presenting from? (Moz Space, your house, space) Will you be sharing your screen? (yes/no, other info) Links to slides or images you want displayed on screen Link to where audience can find out more information
    Jess Amann HRBP – People Team Setting Q3 Deliverables Mountain View No Deliverables Mana Page N/A

    Welcome!

    Let’s say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.

    Introducing New Volunteers

    New Volunteer Introduced by Speaker location New Volunteer location Will be working on
    Who is the new volunteer? Who will be introducing that person? Where is the introducer? Where will the new person be contributing from? What will the new person be working on?

    Introducing New Hires

    New Hire Introduced by Speaker location New Hire location Will be working on
    Jason Bradford Sean Rich Mountain View Mountain View Helping Mozilla procure and manage SaaS
    Phil Booth Ryan Kelly San Francisco London Firefox Accounts
    Dylan Roeh James Willcox Vidyo (Kentucky) Chicago Android Platform
    Mahendranadh Potharaju Pallavi Yaramada Remote Mountain View Senior Release Manager

    Introducing New Interns

    New Intern Introduced by Speaker location New Hire location Will be working on
    Robert Bindar Candice Serran San Francisco San Francisco FFX OS
    Anthony Miyaguchi Chris Cooper Mountain View San Francisco RelEng
    Sajjad Taheri Sean Stangl Mountain View Mountain View JS Eng.
    Vaibhav Agrawal Chris Manchester Mountain View San Francisco Auto & Tools
    Catalin Badea Daniel Holbert (for Nikhil) Mountain View San Francisco Platform Eng.
    Riadh Chtara Chris Karlof Mountain View San Francisco Cloud Services
    Sam Scott Eric Rescorla Mountain View Mountain View Research

    <meta>

    Notes and non-voice status updates that aren’t part of the live meeting go here.

    Status Updates By Team (*non-voice* updates)

    Engagement

    Air MozillaDXR 2.0 (Part 2: Discussion)

    DXR 2.0 (Part 2: Discussion) A discussion of the roadmap for DXR after 2.0

    Air MozillaDXR 2.0 (Part 1: Dog & Pony Show)

    DXR 2.0 (Part 1: Dog & Pony Show) Demo of features new in the upcoming 2.0 release of DXR, Mozilla's search and analysis tool for large codebases

    Mozilla SecurityDharma


    dharma

    As soon as a developer at Mozilla starts integrating a new WebAPI feature, the Mozilla Security team begins working to help secure that API. Subtle programming mistakes in new code can introduce annoying crashes and even serious security vulnerabilities that can be triggered by malformed input which can lead to headaches for the user and security exposure.

    WebAPIs start life as a specification in the form of an Interface Description Language, or IDL. Since this is essentially a grammar, a grammar-based fuzzer becomes a valuable tool in finding security issues in new WebAPIs because it ensures that expected semantics are followed most of the time, while still exploring enough undefined behavior to produce interesting results.

    We came across a grammar fuzzer Ben Hawkes released in 2011 called “Dharma.” Sadly, only one version was ever made public. We liked Ben’s approach, but Dharma was missing some features which were important for us and its wider use for API fuzzing. We decided to sit down with our fuzzing mates at BlackBerry and rebuild Dharma, giving the results back to the public, open source and licensed as MPL v2.

    We redesigned how Dharma parses grammars and optimized the speed of parsing and the generating of fuzzed output, added new grammar features to the grammar specification, added support for serving testcases over a WebSocket server, and made it Python 3 ready. It comes with no dependencies and runs out of the box.

    In theory Dharma can be used with any data that can be represented as a grammar. At Mozilla we typically use it for APIs like WebRTC, WebAudio, or WebCrypto.


    dharma_demo

    Dharma has no integrated harness. Feel free to check out the Quokka project which provides an easy way for launching a target with Dharma, monitoring the process and bucketing any faults.

    Dharma is actively in use and maintained at Mozilla and more features are planned for the future. Ideas for improvements are always greatly welcomed.

    Dharma is available via GitHub (preferred and always up-to-date) or via PyPi by running “pip install dharma”.

    References
    https://github.com/mozillasecurity/dharma
    https://github.com/mozillasecurity/quokka
    https://code.google.com/p/dharma/

    Air MozillaMozilla Weekly Project Meeting

    Mozilla Weekly Project Meeting The Monday Project Meeting

    Mozilla Web DevelopmentBeer and Tell – June 2015

    Once a month, web developers from across the Mozilla Project get together to try and transmute a fresh Stanford graduate into a 10x engineer. Meanwhile, we find time to talk about our side projects and drink, an occurrence we like to call “Beer and Tell”.

    There’s a wiki page available with a list of the presenters, as well as links to their presentation materials. There’s also a recording available courtesy of Air Mozilla.

    Osmose: SpeedKills and Advanced Open File

    First up was Osmose (that’s me!) presenting two packages for Atom, a text editor. SpeedKills is a playful package that plays a guitar solo and sets text on fire when the user types fast enough. Advanced Open File is a more useful package that adds a convenient dialog for browsing the file system and opening files by path rather than using the fuzzy finder. Both are available for install through the Atom package repository.

    new_one: Tab Origin

    Next was new_one, who shared Tab Origin, a Firefox add-on that lets you return to the webpage that launched the current tab, even if the parent tab has since been closed. It’s activated via a keyboard shortcut that can be customized.

    Potch: WONTFIX and Presentation Mode

    Continuing a fine tradition of batching projects, Potch stopped by to show off two Firefox add-ons. The first was WONTFIX, which adds a large red WONTFIX stamp to any Bugzilla bug that has been marked as WONTFIX. The second was Presentation Mode, which allows you to full-screen any content in a web page while hiding the browser chrome. This is especially useful when giving web-based presentations.

    Peterbe: premailer.io

    Peterbe shared premailer.io, which is a service wrapping premailer. Premailer takes a block of HTML with a style tag and applies the styles within as style attributes on each matching tag. This is mainly useful for HTML emails, which generally don’t support style tags that apply to the entire email.

    ErikRose: Spam-fighting Tips

    ErikRose learned a lot about the current state of spam-fighting while redoing his mail server:

    • Telling Postfix to be picky about RFCs is a good first pass. It eliminates some spam without having to do much computation.
    • spamassassin beats out dspam, which hasn’t seen an update since 2012.
    • Shared-digest detectors like Razor help a bit but aren’t sufficient on their own without also greylisting to give the DBs a chance to catch up.
    • DNS blocklists are a great aid: they reject 3 out of 4 spams without taking much CPU.
    • Bayes is still the most reliable (though the most CPU-intense) filtration method. Bayes poisoning is infeasible, because poisoners don’t know what your ham looks like, so don’t worry about hand-picking spam to train on. Train on an equal number of spams and hams: 400 of each works well. Once your bayes is performing well, crank up your BAYES_nn settings so spamassassin believes it.
    • Crank up spamc’s –max-size to 1024000, because spammers are now attaching images > 512K to mails to bypass spamc’s stock 512K threshold. This will cost extra CPU.

    With this, he gets perhaps a spam a week, with over 400 attempts per day.


    We were only able to get a 3x engineer this month, but at least they were able to get a decent job working on enterprise software.

    If you’re interested in attending the next Beer and Tell, sign up for the dev-webdev@lists.mozilla.org mailing list. An email is sent out a week beforehand with connection details. You could even add yourself to the wiki and show off your side-project!

    See you next month!

    about:communityRecap of Participation at Whistler

    <noscript>[<a href="https://storify.com/lucyeharris/participation-at-whistler" target="_blank">View the story &#8220;Participation at Whistler&#8221; on Storify</a>]</noscript>

    SeaMonkeyNew seamonkey-2.35.en-US.win32-20150626.zip available

    NewNightly35Build details:

    • Built of mozilla-esr38 + THUNDERBIRD_38_VERBRANCH. Note Official 2.35 release will be built off mozilla-release 38 (Probably 38.0.6)
    • DOM Inspector built off changeset 80c195824f1e. Version shows as 2.0.16pre. I have uploaded 2.0.16 to AMO so SeaMonkey should update to that version if configured.
      • http://hg.mozilla.org/dom-inspector/graph/80c195824f1e
    • Chatzilla built off changeset c65366e47dd2. Version shows as 0.9.91.1 . This is a problem because SeaMonkey may update to the version on AMO (0.9.91.1.1-signed).
      • http://hg.mozilla.org/chatzilla/graph/c65366e47dd2

    Download here!

    @Phil: Thank you for adding build info to the readme.txt!

    SUMO BlogWhat’s up with SUMO – 26th June

    Hello, SUMO Nation! Today, for a change, just a quick “hello”, as we are wrapping up a very busy Work Week… The regular blog will be back next week with a lot of updates (and some fun photos). Keep on … Continue reading

    hacks.mozilla.orgPerformance Testing Firefox OS With Raptor

    When we talk about performance for the Web, a number of familiar questions may come to mind:

    • Why does this page take so long to load?
    • How can I optimize my JavaScript to be faster?
    • If I make some changes to this code, will that make this app slower?

    I’ve been working on making these types of questions easier to answer for Gaia, the UI layer for Firefox OS, a completely web-centric mobile device OS. Writing performant web pages for the desktop has its own idiosyncrasies, and writing native applications using web technologies takes the challenge up an order of magnitude. I want to introduce the challenges I’ve faced in making performance an easier topic to tackle in Firefox OS, as well as document my solutions and expose holes in the Web’s APIs that need to be filled.

    From now on, I’ll refer to web pages, documents, and the like as applications, and while web “documents” typically don’t need the performance attention I’m going to give here, the same techniques could still apply.

    Fixing the lifecycle of applications

    A common question I get asked in regard to Firefox OS applications:

    How long did the app take to load?

    Tough question, as we can’t be sure we are speaking the same language. Based on UX and my own research at Mozilla, I’ve tried at adopt this definition for determining the time it takes an application to load:

    The amount of time it takes to load an application is measured from the moment a user initiates a request for the application to the moment the application appears ready for user interaction.

    On mobile devices, this is generally from the time the user taps on an icon to launch an app, until the app appears visually loaded; when it looks like a user can start interacting with the application. Some of this time is delegated to the OS to get the application to launch, which is outside the control of the application in question, but the bulk of the loading time should be within the app.

    So window load right?

    With SPAs (single-page applications), Ajax, script loaders, deferred execution, and friends, window load doesn’t hold much meaning anymore. If we could merely measure the time it takes to hit load, our work would be easy. Unfortunately, there is no way to infer the moment an application is visually loaded in a predictable way for everyone. Instead we rely on the apps to imply these moments for us.

    For Firefox OS, I helped develop a series of conventional moments that are relevant to almost every application for implying its loading lifecycle (also documented as a performance guideline on MDN):

    navigation loaded (navigationLoaded)

    The application designates that its core chrome or navigation interface exists in the DOM and has been marked as ready to be displayed, e.g. when the element is not display: none or any other functionality that would affect the visibility of the interface element.

    navigation interactive (navigationInteractive)

    The application designates that the core chrome or navigation interface has its events bound and is ready for user interaction.

    visually loaded (visuallyLoaded)

    The application designates that it is visually loaded, i.e., the “above-the-fold” content exists in the DOM and has been marked as ready to be displayed, again not display: none or other hiding functionality.

    content interactive (contentInteractive)

    The application designates that it has bound the events for the minimum set of functionality to allow the user to interact with “above-the-fold” content made available at visuallyLoaded.

    fully loaded (fullyLoaded)

    The application has been completely loaded, i.e., any relevant “below-the-fold” content and functionality have been injected into the DOM, and marked visible. The app is ready for user interaction. Any required startup background processing is complete and should exist in a stable state barring further user interaction.

    The important moment is visually loaded. This correlates directly with what the user perceives as “being ready.” As an added bonus, using the visuallyLoaded metric pairs nicely with camera-based performance verifications.

    Denoting moments

    With a clearly-defined application launch lifecycle, we can denote these moments with the User Timing API, available in Firefox OS starting with v2.2:

    window.performance.mark( string markName )
    

    Specifically during a startup:

    performance.mark('navigationLoaded');
    performance.mark('navigationInteractive');
    ...
    performance.mark('visuallyLoaded');
    ...
    performance.mark('contentInteractive');
    performance.mark('fullyLoaded');
    

    You can even use the measure() method to create a measurement between start and another mark, or even 2 other marks:

    // Denote point of user interaction
    performance.mark('tapOnButton');
    
    loadUI();
    
    // Capture the time from now (sectionLoaded) to tapOnButton
    performance.measure('sectionLoaded', 'tapOnButton');
    

    Fetching these performance metrics is pretty straightforward with getEntries, getEntriesByName, or getEntriesByType, which fetch a collection of the entries. The purpose of this article isn’t to cover the usage of User Timing though, so I’ll move on.

    Armed with the moment an application is visually loaded, we know how long it took the application to load because we can just compare it to—oh, wait, no. We don’t know the moment of user intent to launch.

    While desktop sites may be able to easily procure the moment at which a request was initiated, doing this on Firefox OS isn’t as simple. In order to launch an application, a user will typically tap an icon on the Homescreen. The Homescreen lives in a process separate from the app being launched, and we can’t communicate performance marks between them.

    Solving problems with Raptor

    Without the APIs or interaction mechanisms available in the platform to be able to overcome this and other difficulties, we’ve build tools to help. This is how the Raptor performance testing tool originated. With it, we can gather metrics from Gaia applications and answer the performance questions we have.

    Raptor was built with a few goals in mind:

    • Performance test Firefox OS without affecting performance. We shouldn’t need polyfills, test code, or hackery to get realistic performance metrics.
    • Utilize web APIs as much as possible, filling in gaps through other means as necessary.
    • Stay flexible enough to cater to the many different architectural styles of applications.
    • Be extensible for performance testing scenarios outside the norm.
    Problem: Determining moment of user intent to launch

    Given two independent applications — Homescreen and any other installed application — how can we create a performance marker in one and compare it in another? Even if we could send our performance mark from one app to another, they are incomparable. According to High-Resolution Time, the values produced would be monotonically increasing numbers from the moment of the page’s origin, which is different in each page context. These values represent the amount of time passed from one moment to another, and not to an absolute moment.

    The first breakdown in existing performance APIs is that there’s no way to associate a performance mark in one app with any other app. Raptor takes a simplistic approach: log parsing.

    Yes, you read that correctly. Every time Gecko receives a performance mark, it logs a message (i.e., to adb logcat) and Raptor streams and parses the log looking for these log markers. A typical log entry looks something like this (we will decipher it later):

    I/PerformanceTiming( 6118): Performance Entry: clock.gaiamobile.org|mark|visuallyLoaded|1074.739956|0.000000|1434771805380
    

    The important thing to notice in this log entry is its origin: clock.gaiamobile.org, or the Clock app; here the Clock app created its visually loaded marker. In the case of the Homescreen, we want to create a marker that is intended for a different context altogether. This is going to need some additional metadata to go along with the marker, but unfortunately the User Timing API does not yet have that ability. In Gaia, we have adopted an @ convention to override the context of a marker. Let’s use it to mark the moment of app launch as determined by the user’s first tap on the icon:

    performance.mark('appLaunch@' + appOrigin)
    

    Launching the Clock from the Homescreen and dispatching this marker, we get the following log entry:

    I/PerformanceTiming( 5582): Performance Entry: verticalhome.gaiamobile.org|mark|appLaunch@clock.gaiamobile.org|80081.169720|0.000000|1434771804212
    

    With Raptor we change the context of the marker if we see this @ convention.

    Problem: Incomparable numbers

    The second breakdown in existing performance APIs deals with the incomparability of performance marks across processes. Using performance.mark() in two separate apps will not produce meaningful numbers that can be compared to determine a length of time, because their values do not share a common absolute time reference point. Fortunately there is an absolute time reference that all JS can access: the Unix epoch.

    Looking at the output of Date.now() at any given moment will return the number of milliseconds that have elapsed since January 1st, 1970. Raptor had to make an important trade-off: abandon the precision of high-resolution time for the comparability of the Unix epoch. Looking at the previous log entry, let’s break down its output. Notice the correlation of certain pieces to their User Timing counterparts:

    • Log level and tag: I/PerformanceTiming
    • Process ID: 5582
    • Base context: verticalhome.gaiamobile.org
    • Entry type: mark, but could be measure
    • Entry name: appLaunch@clock.gaiamobile.org, the @ convention overriding the mark’s context
    • Start time: 80081.169720,
    • Duration: 0.000000, this is a mark, not a measure
    • Epoch: 1434771804212

    For every performance mark and measure, Gecko also captures the epoch of the mark, and we can use this to compare times from across processes.

    Pros and Cons

    Everything is a game of tradeoffs, and performance testing with Raptor is no exception:

    • We trade high-resolution times for millisecond resolution in order to compare numbers across processes.
    • We trade JavaScript APIs for log parsing so we can access data without injecting custom logic into every application, which would affect app performance.
    • We currently trade a high-level interaction API, Marionette, for low-level interactions using Orangutan behind the scenes. While this provides us with transparent events for the platform, it also makes writing rich tests difficult. There are plans to improve this in the future by adding Marionette integration.

    Why log parsing

    You may be a person that believes log parsing is evil, and to a certain extent I would agree with you. While I do wish for every solution to be solvable using a performance API, unfortunately this doesn’t exist yet. This is yet another reason why projects like Firefox OS are important for pushing the Web forward: we find use cases which are not yet fully implemented for the Web, poke holes to discover what’s missing, and ultimately improve APIs for everyone by pushing to fill these gaps with standards. Log parsing is Raptor’s stop-gap until the Web catches up.

    Raptor workflow

    Raptor is a Node.js module built into the Gaia project that enables the project to do performance tests against a device or emulator. Once you have the project dependencies installed, running performance tests from the Gaia directory is straightforward:

    1. Install the Raptor profile on the device; this configures various settings to assist with performance testing. Note: this is a different profile that will reset Gaia, so keep that in mind if you have particular settings stored.
      make raptor
    2. Choose a test to run. Currently, tests are stored in tests/raptor in the Gaia tree, so some manual discovery is needed. There are plans to improve the command-line API soon.
    3. Run the test. For example, you can performance test the cold launch of the Clock app using the following command, specifying the number of runs to launch it:
      APP=clock RUNS=5 node tests/raptor/launch_test
    4. Observe the console output. At the end of the test, you will be given a table of test results with some statistics about the performance runs completed. Example:
    [Cold Launch: Clock Results] Results for clock.gaiamobile.org
    
    Metric                            Mean     Median   Min      Max      StdDev  p95
    --------------------------------  -------  -------  -------  -------  ------  -------
    coldlaunch.navigationLoaded       214.100  212.000  176.000  269.000  19.693  247.000
    coldlaunch.navigationInteractive  245.433  242.000  216.000  310.000  19.944  274.000
    coldlaunch.visuallyLoaded         798.433  810.500  674.000  967.000  71.869  922.000
    coldlaunch.contentInteractive     798.733  810.500  675.000  967.000  71.730  922.000
    coldlaunch.fullyLoaded            802.133  813.500  682.000  969.000  72.036  928.000
    coldlaunch.rss                    10.850   10.800   10.600   11.300   0.180   11.200
    coldlaunch.uss                    0.000    0.000    0.000    0.000    0.000   n/a
    coldlaunch.pss                    6.190    6.200    5.900    6.400    0.114   6.300
    

    Visualizing Performance

    Access to raw performance data is helpful for a quick look at how long something takes, or to determine if a change you made causes a number to increase, but it’s not very helpful for monitoring changes over time. Raptor has two methods for visualizing performance data over time, in order to improve performance.

    Official metrics

    At raptor.mozilla.org, we have dashboards for persisting the values of performance metrics over time. In our automation infrastructure, we execute performance tests against devices for every new build generated by mozilla-central or b2g-inbound (Note: The source of builds could change in the future.) Right now this is limited to Flame devices running at 319MB of memory, but there are plans to expand to different memory configurations and additional device types in the very near future. When automation receives a new build, we run our battery of performance tests against the devices, capturing numbers such as application launch time and memory at fullyLoaded, reboot duration, and power current. These numbers are stored and visualized many times per day, varying based on the commits for the day.

    Looking at these graphs, you can drill down into specific apps, focus or expand your time query, and do advanced query manipulation to gain insight into performance. Watching trends over time, you can even pick out regressions that have sneaked into Firefox OS.

    Local visualization

    The very same visualization tool and backend used by raptor.mozilla.org is also available as a Docker image. After running the local Raptor tests, data will report to your own visualization dashboard based on those local metrics. There are some additional prerequisites for local visualization, so be sure to read the Raptor docs on MDN to get started.

    Performance regressions

    Building pretty graphs that display metrics is all well and fine, but finding trends in data or signal within noise can be difficult. Graphs help us understand data and make it accessible for others to easily communicate around the topic, but using graphs for finding regressions in performance is reactive; we should be proactive about keeping things fast.

    Regression hunting on CI

    Rob Wood has been doing incredible work in our pre-commit continuous integration efforts surrounding the detection of performance regressions in prospective commits. With every pull request to the Gaia repository, our automation runs the Raptor performance tests against the target branch with and without the patch applied. After a certain number of iterations for statistical accuracy, we have the ability to reject patches from landing in Gaia if a regression is too severe. For scalability purposes we use emulators to run these tests, so there are inherent drawbacks such as greater variability in the metrics reported. This variability limits the precision with which we can detect regressions.

    Regression hunting in automation

    Luckily we have the post-commit automation in place to run performance tests against real devices, and is where the dashboards receive their data from. Based on the excellent Python tool from Will Lachance, we query our historical data daily, attempting to discover any smaller regressions that could have crept into Firefox OS in the previous seven days. Any performance anomalies found are promptly reported to Bugzilla and relevant bug component watchers are notified.

    Recap and next steps

    Raptor, combined with User Timing, has given us the know-how to ask questions about the performance of Gaia and receive accurate answers. In the future, we plan on improving the API of the tool and adding higher-level interactions. Raptor should also be able to work more seamlessly with third-party applications, something that is not easily done right now.

    Raptor has been an exciting tool to build, while at the same time helping us drive the Web forward in the realm of performance. We plan on using it to keep Firefox OS fast, and to stay proactive about protecting Gaia performance.

    Meeting NotesSeaMonkey: 2015-06-23

    Agenda

    • Who’s taking minutes? -> TBD
    • Nominees for Friends of the Fish Tank:
      • TBD

    Action Items

    (who needs to do what that hasn’t been recorded in a bug)
    We should assign people to the open items.

    NEW

    OPEN

    • bug 1150082 SeaMonkey Donation Page is using the PayPal all or nothing version, instead of the usual either/or one. Mcsmurf is investigating.
    • bug 1121281 tracks the RelEng automation migration off CVS. Currently two option patches awaiting for Callek’s decision. Once settled, ewong will follow up with RelEng patches based on that decision.

    CLOSED

    Status of the SeaMonkey Buildbot Master and Tree

    • Notes:
      • Windows nightly trunk builds are unavailable due to various bugs such as bug 1092468 and bug 1108970. Migrating our Windows builders to Win2008 and our compiler toolchain to VS2013 would likely solve this and other bustages.
      • Ratty has put up some win32 contributed builds on http://seamonkey.callek.net/contrib/.
      • There are also some upcoming changes to L10n build system in Q1 2015 (bug 1107635).
      • Buildmaster is up and running, and produces en-US builds, see 9/16 meeting’s Friends of the Fish Tank. Builds and langpacks in 18 languages including en-US are available unofficially thanks to A.Kalla.
      • bug 1083689 Langpacks aren’t updated when auto-updating SeaMonkey because they aren’t uploaded to AMO. The solution requires changes in SeaMonkey RelEng (and possibly AMO).
      • For various reasons we don’t have a working SeaMonkey Treeherder.
      • wrt bug 1155011, we already have a Soccoro token. The patches require approval and then pushed and the work-around patches backed out.
    • [23th June 2015]
      • All trees:
        • Windows platform still busted due to needing Win2008R2 installed.
        • We have a loaner which ewong is working on (see Release Train section).
    • See RelEng page for the RelEng status history.

    Release Train

    SeaMonkey 2.35 Release
    • We plan to release SeaMonkey 2.35 by the end of June.
      • For windows builds, we have a loaner win machine from Mozilla for us (i.e. ewong) to do manual window builds.
        • [ewong:] doing the buildbot steps manually on a Windows machine is proving to be a bit more involved as there are bits missing(these bits are normally created within the buildmaster so manually creating these bits is slow going) and it doesn’t help that I’ve been swamped elsewhere.

    TODO:

    • Patches to uplift to comm-release: status-seamonkey2.35: affected
    • Create a relbranch on mozilla-release. Uplift the following patches:
      • bug 1151345 [OSX Widget] Firefox app menu contains only “Quit” on Firefox 38 beta (“About Firefox” and all other items are missing)
      • bug 1165732 Firefox running very slow on Windows starting with version 38 due to hardware acceleration
      • bug 1169996 Changing the spell check language in the message subject of a recycled message via right-click changes the composition language preference.
      • Need to check that the following bug 1166924 bug 1167356 bug 1171540 bug 1172397 bug 1172076 are fixed on what ever branch we use.
    • Alternatively use the existing THUNDERBIRD_38_VERBRANCH on mozilla-esr38.
    • [Ratty] Are we basing our 2.35 release on mozilla-38.0.x or mozilla-38.1.x? Notes that mozilla-release is now at FIREFOX_39_0_BUILD3.

    Extensions and Plugins Compatibility Tracking

    • See Basics page. Please only list current changes here.
    • Addon Compatibility Listings
    • We are looking for a new place to host the Addon Compatibility Listings for the Add-on Converter in order to make it easy to maintain and to serve as the main database for the AMO browsing extension in the future. The details are in this post.
    • Lightning (other extensions with binary XPCOM components) was broken on trunk due to bug 1159737, fixed (at least for now) in bug 1165428 introducing MOZ_BINARY_EXTENSIONS build-time switch, enabled in bug 1166842.
    • Firefox & Thunderbird Add-on Converter for SeaMonkey http://addonconverter.fotokraina.com/
      This tool goes a little further beyond simply modifying install.rdf – it also identifies a few more other things in the code that are Firefox or Thunderbird specific and attempts to change them. Of course, not all extensions can be ported so easily to SeaMonkey since there’s only so much an automated tool like that can do.
      • Lemon Juice continues to improve his already impressive Addon Converter. The source is now available on GitHub [1].
      • looking for a better(?) home for extension-converter pages, along with a way to track successful and conversion-failed add-ons, and respective integration into SeaMonkey by add-on or manager overlay [2], bug 1145026.
      • Rainer Bielefeld together with other community members have been updating the list of Firefox addons that have been successfully converted by the Addon Converter.
      • Ratty filed bug 1130390 to add a link on seamonkey-projects.org to the Firefox & Thunderbird Add-on Converter for SeaMonkey.
    • The Thunderbird team is now shipping Lightning with Thunderbird. IanN will work on shipping lightning too. Related bugs:
      • bug 516026 Integrate Lightning Into SeaMonkey by Default and Ship SeaMonkey with Lightning Enabled
      • bug 1130854 Package Lightning with Thunderbird for c-c and c-a builds.
      • bug 1113183 Integrate Lightning Into Thunderbird by Default.
      • bug 1130852 Add opt-in dialog to promote Calendar integration [Thunderbird].
    • Proposed replacement for Venkman for shipping with SeaMonkey: Tiny JavaScript Debugger. TinyJSD is a JavaScript debugger for privileged code running Mozilla products like Firefox, Thunderbird, SeaMonkey. It serves to debug the application as well as extensions written in JavaScript.
      • IanN filed bug 1133723 Investigate options for replacing Venkman with the TinyJSDebugger.
    • Our build team needs to automate DOMI branch selection rather than having to tweak the client.py every 6 weeks. bug 763506

    2.x (Last, Current, Next)

    • SeaMonkey Statistics can be viewed at https://dataviz.mozilla.org Across all channels we have an approximate ADU of 120k.
      • Ratty suggests embedding these graphs somewhere on seamonkey-projects.org or https://dev.seamonkey.at
      • bug 1133728 Look at embedding dataviz information into the SeaMonkey website.
      • Links are broken again. Dataviz views now needs a SSO login. We need to find out how to expose a limited view for public consumption.
    • See Basics page for the usual reminders.
    2.33

    open tracking (0)
    tracking requests (1)
    targeted (0)
    fixed (20)

    2.35
    • Mozilla-central bugs that affect us:
      • Current 38.0-branch releases are subject to Logjam weak-encryption downgrade attack [3] due to security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha being enabled by default
        • bug 1138554 fixed in NSS 3.19.1, uplifted to branches for 39.0+ with bug 1166031, and verified fixed for SM 2.36
        • Can 2.35 ship with NSS 3.19.1? [4]
          • bug 1172917 filed to explore the options, possibly building this version from mozilla-esr38 instead of mozilla-release.
    • one week left to get a 2.35 release done, merge scheduled for next week
    2.Next
    • Stalled. Needs a kick.
      • bug 815954 Click-to-Play: Port bug 812562 (click-to-play blocklisted plugins: reshow urlbar notification as with normal click-to-play).
      • bug 476108 GetShortPathNameW fails under some NTFS junctions [patchlove].
    • Current breakages:
    • Mozilla-central bugs that affect us:
      • Firefox is currently changing styles of several Toolkit pages
        • already affected: config.xul for about:config, bug 1125636
        • Toolkit meta bug for about:* pages: bug 1097111 – SeaMonkey tracking in bug 1133743
        • Modern may need updating as IDs are changing, Default needs forking if we want to roll back to previous styles
        • Fallout thus far: bug 1133380 about:privatebrowsing (Default), bug 1133582 about:config (Modern)
      • Our front end Sync UI needs to be updated as the old backend is going away in Gecko/Firefox 31. See: New Firefox Sync has landed in Firefox Nightly. Tracked in:
        • bug 998807 Sync account creation or device pairing fails with exception in BrowserIDManager.
        • bug 1003434 Add support for about:sync-progress.
        • SeaMonkey won’t be allowed to use the Firefox Sync 1.5 servers. Ewong has set up a FxA 1.5 server and is looking into hosting our own FxAccounts server on a community machine or VPS.
      • A lot of these bugs are due to mozilla-central switching from synchronous APIs to Asynchronous APIs.
      • bug 566746 (asyncFormHistory) Form history should use asynchronous storage API. Tracked in:
        • bug 912031 Use Asynchronous FormHistory.jsm in place of nsIFormHistory2 in Suite.
      • bug 769764 move proxy resolution to separate thread and remove sync api. Tracked in:
        • MailNews bug 791645 Rewrite calls to synchronous nsIProtocolProxyService::DeprecatedBlockingResolve with Async code before DeprecatedBlockingResolve disappears as well.
      • The C++ downloads manager backend nsIDownloadManager is being decommissioned. Firefox and Thunderbird have migrated to jsdownloads.
      • bug 825588 Asynchronous JavaScript API for downloads and bug 851471 Decommission nsIDownloadManager. Tracked in:
        • bug 888915 Move SeaMonkey to the new JavaScript API for downloads when nsIDownloadManager is decommissioned. Neil has a WIP patch on hand.
      • Removal of SSL 3.0 support after POODLE Attack with 2.36, see bug 1106470.
        • bug 1137991 has removed SSL 3.0 checkbox from SSL preferences
        • bug 1149581 covers removal of the related strings
        • Firefox will likely proceed with the removal in 39.0 given that Chrome goes the same way [5]
      • We’ve picked up he default for security.tls.version.min from Mozilla Core, but security.tls.version.fallback-limit is new. So we need to consider adding the latter to our preferences UI (bug 1123673).
        • Currently unclear whether or not this should be done after bug 1084025 disable insecure TLS version fallback entirely by default [6]
        • alternative proposal is to make whitelist for acceptable fallback sites available in the UI, which seems to make more sense.

    Feature List, Planning

    Bug statistics for the last two (full) weeks: 16 new, 3 fixed, 14 triaged.

    • Medium triaging effort, lower than average number of new bugs filed.
    • IanN thinks it would be useful to remind people on the newsgroups / forums that they can contribute by triaging. Tonymec will post a reminder to newsgroups / forums. See bug 1092632 (Sm_tri_HowTo) Document how to triage SeaMonkey bugs.
      • The draft is currently at https://wiki.mozilla.org/User:Tonymec/Triage_HowTo
      • Progress is stalled due to hardware/firmware problems with Tonymec’s current computer. Current ETA for newer computer is after Easter but this is a rough estimate. Anyone with a wikimoz account can edit the page (and is welcome to). — Tonymec (talk) 17:35, 21 January 2015 (PST)

    Open reviews/flags:
    43 review
    5 super-review
    5 ui-review
    10 feedback

    • See Feature List page for major wanted/needed features.
    • TODO:
      • bug 1127784 proposes to add a preference and UI to enable/disable playback of Encrypted Media Extensions.

    Roundtable – Personal Status Updates

    Status Updates from developers – what are you working on, what’s the progress, any other comments? (feel free to add yourself to the list if your name is missing and you have interesting status).

    ewong
    • Fixed:
      • bug 1099585 – Make JS callers of ios.newChannel call ios.newChannel2 in suite/
    • Working on:
      • manually creating builds on the loaner.
    IanN
    • Usual testing, reviewing and commenting.
    • Fixed:
      • bug 1163442 Use FINAL_TARGET_FILES and PP_TARGETS for SeaMonkey themes
      • bug 1168525 Port |bug 1166538 – Use mozbuild.jar-based zip tool instead of $(ZIP) for simple cases| to Calendar
    • Fixed for c-c:
    • Fixed for m-c:
    • Fixed for m-i:
    • Pending tree opening:
    • Pending approval for check in:
    • Checked in pending review:
    • Waiting for feedback/review/information:
      • bug 1061348 Port |bug 575283 – Cleanup mozconfig files on all platforms| to SeaMonkey
      • bug 1163441 Use FINAL_TARGET_FILES and DIST_FILES for Thunderbird themes
    • Fixing review comments before checkin:
      • bug 757230 When using add button for permissions in Data Manager set a displayHost
      • bug 798147 Switch to correct pref pane if pref window already open
    • Working on:
      • bug 1051642 Allow for flat chrome format when packaging extensions
      • bug 943335 [TB] Update icons used in searchplugins (Yahoo, eBay, Wikipedia, Amazon, Bing, Twitter)
      • Various SM Council documents.
      • bug 606683 Allow customization of toolbar in Composer and MailNews Composition
      • bug 639690 [META] Re-arrange code between editor and editorOverlay
      • bug 773979 [META] Switch to new drag and drop api in SeaMonkey
      • bug 657234 Move pasteQuote and pasteNoFormatting into contentAreaContextOverlay
      • File/Folder selection in windows.
    • To Do:
      • bug 639395 Get cmd_fontSize to reflect current state of selected content / content at caret.
      • Prefs-in-a-tab.
      • Create FAQ for Friends of the Fish Tank.
      • Help get composer standalone builds working with –enable-tests.
    Neil

    I didn’t get much done over the last fortnight because I was too busy with work and other stuff. Hopefully I can catch up over the next couple of months.
    Still needs uplift(s):

    • bug 1170002 Display name with comma does not get properly quoted in From field.
    • bug 1165316 Replace Livemark callback function usage.

    Still hoping for feedback:

    • bug 888915 Convert SeaMonkey Downloads Manager to Downloads.jsm

    Still waiting for review:

    Ratty

    WONTFIX:

    • bug 1176055 Re-implement keyword.URL (search from the locationbar) unsync it from the default search engine.

    Waiting on check-in on CLOSED TREE:

    • bug 1040910 Support XHTML in feed titles.
    • bug 1158496 JavaScript error: …/nsSuiteGlue.js, line 291: NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow].

    Needs uplift to comm-aurora:

    • bug 1163395 Port bug 967494 to SeaMonkey (Preference Composition/Spelling/Language is ignored, and changing spellcheck language in one composition window affects all open and new compositions).

    Working on:

    • bug 507676 Port bug 435804 Remaining rdf cleanup for FilterListDialog| to SeaMonkey.
    • bug 1011857 Implement CustomizableUI for SeaMonkey.
    • bug 1153577 Users should be able to hide the menubar and show it with the ALT key.
    • bug 1174601 Copy nsDragAndDrop.js from toolkit to SeaMonkey because it will be removed in bug 1162050.

    TODO:

    • bug 1176602 In message compose make sure that the dictionary stored in spellchecker.dictionary is valid (Adapt Thunderbird Bug 1175908).
    • Packaging updates.
    • Safe Browsing updates.
    • According to John-Galt the reason we have a blank space in the discovery pane of the addons manager is that our carousel is empty. So we can fill it with links to the addon converter etc (we may need admin access). Need to ask Mossop who in Firefox land is responsible for updating their Carousel and what the procedure is.

    Other stuff:

    • Did some reviews and approvals.
    • Bug triage and Bug discussions.
    • Usual end user support and PR in newsgroups and Mozillazine.
    rsx11m

    Still waiting for checkin:

    • bug 1141324 Upgrade the SSL panel in Privacy & Security preferences to refer to TLS {instead,too}.

    Still waiting for ui-review or review:

    • bug 1152644 Add UI in Notifications preference pane whether or not to use libnotify for new-mail alerts on Linux.
    • bug 1032302 8BITMIME keyword ignored in EHLO greeting, BODY=8BITMIME absent in MAIL request for 8-bit transfers. (MailNews)

    Still waiting for feedback:

    • bug 1127784 [EME] Add a preference and UI to enable/disable playback of Encrypted Media Extensions. (prefpane part)

    Filed:

    May need retargeting:

    • bug 1123673 Consider exposing security.tls.version.fallback-limit in SSL prefpane to accommodate SSL 3.0 legacy sites.

    Waiting for dependencies:

    • bug 1149581 Remove SSLv3 strings from SSL panel in Privacy & Security preferences.
      • to be reviewed once bug 1137991 has hit the releases (timing depends on the Firefox/Core side but seems to become effective as planned with 39.0).

    Other:

    • Bug triage, testing, and commenting for SeaMonkey and MailNews Core.
    • End-user information and discussion on MozillaZine.

    Any other business?


    SeaMonkey Meeting Details

    about:communityMozilla Tech Speakers: A pilot for technical evangelism

    The six-week pilot version of the Mozilla Tech Speakers program wrapped up at the end of May. We learned a lot, made new friends on several continents, and collected valuable practical feedback on how to empower and support volunteer Mozillians who are already serving their regional communities as technical evangelists and educators. We’ve also gathered some good ideas for how to scale a speaker program that’s relevant and accessible to technical Mozillians in communities all over the world. Now we’re seeking your input and ideas as well.

    During the second half of 2015, we’ll keep working with the individuals in our pilot group (our pilot pilots) to create technical workshops and presentations that increase developer awareness and adoption of Firefox, Mozilla, and the Open Web platform. We’ll keep in touch as they submit talk proposals and develop Content Kits during the second half of the year, work with them to identify relevant conferences and events, fund speaker travel as appropriate, make sure speakers have access to the latest information (and the latest swag to distribute), and offer them support and coaching to deliver and represent!

    Why we did it

    Our aim is to create a strong community-driven technical speaker development program in close collaboration with Mozilla Reps and the teams at Mozilla who focus on community education and participation. From the beginning we benefited from the wisdom of Rosana Ardila, Emma Irwin, Soumya Deb, and other Mozillian friends. We decided to stand up a “minimum viable” program with trusted, invited participants—Mozillians who are active technical speakers and are already contributing to Mozilla by writing about and presenting Mozilla technology at events around the world. We were inspired by the ongoing work of the Participation Team and Speaker Evangelism program that came before us, thanks to the efforts of @codepo8, Shezmeen Prasad, and many others.

    We want this program to scale and stay sustainable, as individuals come and go, and product and platform priorities evolve. We will incorporate the feedback and learnings from the current pilot into all future iterations of the Mozilla Tech Speaker program.

    What we did

    Participants met together weekly on a video call to practice presentation skills and impromptu storytelling, contributed to the MDN Content Kit project for sharing presentation assets, and tried out some new tools for building informative and inspiring tech talks.

    Each participant received one session of personalized one-to-one speaker coaching, using “techniques from applied improvisation and acting methods” delivered by People Rocket’s team of coaching professionals. For many participants, this was a peak experience, a chance to step out of their comfort zone, stretch their presentation skills, build their confidence, and practice new techniques.

    In our weekly meetings, we worked with the StoryCraft technique, and hacked it a little to make it more geek- and tech speaker-friendly. We also worked with ThoughtBox, a presentation building tool to “organize your thoughts while developing your presentation materials, in order to maximize the effectiveness of the content.” Dietrich took ThoughtBox from printable PDF to printable web-based form, but we came to the conclusion it would be infinitely more usable if it were redesigned as an interactive web app. (Interested in building this? Talk to us on IRC. You’ll find me in #techspeakers or #devrel, with new channels for questions and communication coming soon.)

    We have the idea that an intuitive portable tool like ThoughtBox could be useful for any group of Mozillians anywhere in the world who want to work together on practicing speaking and presentation skills, especially on topics of interest to developers. We’d love to see regional communities taking the idea of speaker training and designing the kind of programs and tools that work locally. Let’s talk more about this.

    What we learned

    The pilot was ambitious, and combined several components—speaker training, content development, creating a presentation, proposing a talk—into an aggressive six-week ‘curriculum.’ The team, which included participants in eight timezones, spanning twelve+ hours, met once a week on a video call. We kicked off the program with an introduction by People Rocket and met regularly for the next six weeks.

    Between scheduled meetings, participants hung out in Telegram, a secure cross-platform messaging app, sharing knowledge, swapping stickers (the virtual kind) and becoming friends. Our original ambitious plan might have been feasible if our pilots were not also university students, working developers, and involved in multiple projects and activities. But six weeks turned out to be not quite long enough to get it all done, so we focused on speaking skills—and, as it turned out, on building a global posse of talented tech speakers.

    What’s next

    We’re still figuring this out. We collected feedback from all participants and discovered that there’s a great appetite to keep this going. We are still fine-tuning some of the ideas around Content Kits, and the first kits are becoming available for use and re-use. We continue to support Tech Speakers to present at conferences organize workshops and trainings in their communities. And create their own Mozilla Tech Speakers groups with local flavor and focus.

    Stay tuned: we’ll be opening a Discourse category shortly, to expand the conversation and share new ideas.

    And now for some thank yous…

    I’d like to quickly introduce you to the Mozilla Tech Speakers pilot pilots. You’ll be hearing from them directly in the days, weeks, months ahead, but for today, huge thanks and hugs all around, for the breadth and depth of their contributions, their passion, and the friendships we’ve formed.

    Adrian Crespo, Firefox Marketplace reviewer, Mozilla Rep, student, and technical presenter from Madrid, Spain, creator of the l10n.js Content Kit, for learning and teaching localization through the native JavaScript method.

    Ahmed Nefzaoui, @AhmedNefzaoui, recent graduate and active Mozillian, Firefox OS contributor, Arabic Mozilla localizer, RTL (right-to-left) wizard, and web developer from Tozeur, Tunisia.

    Andre Garzia, @soapdog, Mozilla Rep from Rio de Janeiro, Brazil, web developer, app developer and app reviewer, who will be speaking about Web Components at Expotec at the end of this month. Also, ask him about the Webmaker team LAN Houses program just getting started now in Rio.

    Andrzej Mazur, @end3r, HTML5 game developer, active Hacks blog and MDN contributor, creator of a content kit on HTML5 Game Development for Beginners, active Firefox app developer, Captain Rogers creator, and frequent tech speaker, from Warsaw, Poland.

    István “Flaki” Szmozsánszky, @slsoftworks, Mozillian and Mozilla Rep, web and mobile developer from Budapest, Hungary. Passionate about Rust, Firefox OS, the web of things. If you ask him anything “mildly related to Firefox OS, be prepared with canned food and sleeping bags, because the answer might sometimes get a bit out of hand.”

    Kaustav Das Modak, @kaustavdm, Mozilla Rep from Bengalaru, India; web and app developer; open source evangelist; co-founder of Applait. Ask him about Grouphone. Or, catch his upcoming talk at the JSChannel conference in Bangalore in July.

    Michaela R. Brown, @michaelarbrown, self-described “feisty little scrapper,” Internet freedom fighter, and Mozillian from Michigan. Michaela will share skills in San Francisco next week at the Library Freedom Project: Digital Rights in Libraries event.

    Rabimba Karanjai, @rabimba, a “full-time graduate researcher, part-time hacker and FOSS enthusiast,” and 24/7 Mozillian. Before the month is out, Rabimba will speak about Firefox OS at OpenSourceBridge in Portland and at the Hong Kong Open Source conference.

    Gracias. شكرا. धन्यवाद. Köszönöm. Obrigada. Dziękuję. Thank you. #FoxYeah.

    Meeting NotesMozilla Project: 2015-06-22

    SUMO BlogScreen sharing experiment

    Hello, SUMO peeps! A couple of months ago we have started thinking about ways of expanding the way we’re doing forum support to a more personalized experience. This crazy idea came along: how about doing live screen-sharing? With the new … Continue reading

    QMOFirefox 39 Beta 7 Testday Results

    Hey Mozillians!

    As you already may know, last Friday – June 19th – we held another Testday event, Firefox 39 Beta 7.

    We’d like to take this opportunity to thank everyone for getting involved in the proposed testing activities and in general, for helping us make Firefox better.
    Many thanks go out to Bangladesh QA Community, which gets bigger and better everyday (Hossain Al Ikram, Nazir Ahmed Sabbir, Forhad Hossain, Ashickur Rahman, Meraj  Kazi, Md. Ehsanul Hassan, Wahiduzzaman Hridoy, Rezaul Huque Nayeem, Towkir Ahmed, Md. Rahimul Islam, Mohammad Maruf Islam, Fahmida Noor, Sayed Mohammad Amir, Saheda reza Antora), Moin, nt, Vairus and AaronRaimist for their efforts and contributions, and to all our moderators. Thanks a bunch!

    Keep an eye on QMO for the upcoming events! :)

    SeaMonkeyImprovements for the Blog

    engineroom_battleship-389274_1280News from the machinery compartment

    I am happy that we now have the blog. After some weeks experience with it, we should think about some improvements. Most of the following suggestions are also discussed in Bug 1147825 (meta) Revive SeaMonkey blog and accomplished in the Inofficial German Language SeaMonkey Blog.

    A) Show author’s name

    Currently the postings only show a time stamp, but not author’s name. Because of that postings look rather impersonal, what unfortunately is a problem with many SeaMonkey Web Pages. Se should add some personal touch to SeaMonkey Web Pages (and so to the blog), and one possible measure for this is to show author’s name.

    B) Do not waste page width

    waste of width3The screenshot shows the Blog how it appears in my SeaMonkey on a 16:9 screen. As you can see 50 % of width are not at all used, additionally 15 % for menus, so only 35% of page width are used for the contents or a posting. We should check whether the Coraline theme allows a more lean utilization of room.

    C) More blog Functions

    We should think about adding Blog functions what are used in most other blogs:

    C1) Tag Cloud

    Allows user to find blog postings concerning his special interest.

    C2) Category Cloud

    Allows user to find blog postings concerning his special interest.

    C3) Like and Share Buttons

    So users see what postings were interesting for other users and what ones were not

    C4) Follow Button

    So that interested users can follow easily.

    C5) Counter

    for page visitors

    D) “About” page

    With some basics:

    • Who is responsible for contents (legal notice)
    • copyright
    • introduction of the authors

     E) Blog Roll

    With links to related blogs, SeaMonkey blogs in other languages and so on.

    F) Publish SeaMonkey Blog on Mozilla Blog Planet

    I already published Bug 1176562 Please add SeaMonkey Blog to planet.mozilla.org

    BTW, I myself can do none of the sugessted improvements.

    What are your thoughts, do you have additional suggestions?

    about:communityBringing Participation to Whistler

    Mozilla at Whistler 2010

    Mozilla at Whistler 2010

    The Participation Team is heading to Whistler this week where we’ll be running an innovative series of discussions, presentations, and workshops all centered around creating an approach to participation that is massive and diverse, local and global, strategic and impactful.

    Whether you will be joining us in person or following along online. Here’s an overview of what we’ll be up to this week and how you can get involved:

    Skills Building: Human Centered Design
    Tuesday July 23rd 3:30pm-5pm

    The Participation Team will be participation in an open session about design thinking and problem solving both generally and as they relate to specific projects. Please arrive promptly at 3:30pm if you’d like to participate!

    Join in person: 3:30pm in the Participation Room in the Delta Whistler Village Suites hotel.
    Join remotely: Follow us on discourse and Twitter using the hashtag #MozParticipation to find out what we’re learning during this session.

    TED Style Talks: Exploring Radical Participation at Whistler
    Wednesday June 24th at 4:30pm

    A series of invited experts on participation will challenge us in short TED-style talks, bringing thought-provoking ideas on Radical Participation. Then join over one hundred Mozillians who care about participation as we come up with some rough designs for what radical participation could look like at Mozilla in the years ahead. Confirmed speakers include:

    • Natalie Foster – Co-founder and Executive Director of Peers, the world’s largest independent sharing economy community, and former digital director for President Obama’s Organizing for America (OFA) and the Democratic National Committee.
    • Jono Bacon – Senior Director of Community at XPrize where he leads community development and growth XPRIZE Foundation. He is the author of The Art of Community and the former Ubuntu Community Manager.
    • Jeremy Bird – is a founding Partner at 270 Strategies and a longtime strategist. He also was the National Field Director for the 2012 re-election camapgin of President Barack Obama where he was  dubbed the campaign’s  “Field General” by Rolling Stone Magazine.
    • See the full list of speakers  here

    Join in person: Wednesday June 24th at 4:30pm in Sea to Sky Ballroom C at the Whistler Conference Center
    Join remotely: Watch live on AirMozilla at 11:30pm UTC on June 24th, join the discussion on discourse and read the  blog afterwards for a synthesis of the most poignant ideas.

    Personalized Design: 26 Participation Lab Sessions
    Wednesday June 24th – Thursday June 25 9:30am – 9:00pm

    We’re hosting customized sessions throughout the work week to help teams solve problems and capture opportunities related to contributor or volunteer engagement, user/supporter/contributor participation, and many other topics related to participation. With over 26 projects registered we’ll be meeting with teams throughout the week.

    View the full schedule and the description of each project below.

    Join us in person: Registration is now closed for customized Lab sessions, however the Participation Room (Raven A + B at Delta Whistler Village Suites hotel) will be open to all throughout the week.
    Join remotely: What do you think of the sessions? Send us your thoughts and questions on discourse.

    Participation Moving Forward – Strategy Session
    Friday July 26th 8:30am-10am

    On the last day of Whistler the Participation Team will be gathering with volunteers, staff, and experts to think about what participation might look like at Mozilla 10, 15, 20 years in the future.

    Join in person: Participation Room (Raven A + B) at Delta Whistler Village Suites. Please arrive promptly at 8:30am if you’d like to participate.
    Join remotely: Share your thoughts/visions for the future of participation at Mozilla on discourse here.

    Read more about the Lab and what we’ve been up to in Emma Irwin’s post “Participation Lab, What We’re Learning”.

     

    about:communityParticipation Lab, What We’re Learning

    Photo from Securing Web @ZAP Day 1

     

    In recent months the Participation Lab has been tracking multiple experiments across the project that demonstrate fresh approaches to participation.  To really understand and bring strategic value to Mozilla, our focus in these experiments has been to encourage human centered design and a deliberate setting of ‘milestones for learning ‘  and measuring success.

    Learning milestones are places in a project’s execution where we stop and evaluate the initial hypothesis about participation: do these goals still make sense? Are we still on track to learn about participation?  What are we already learning? Where can we help?

    What we’re finding is that ‘learning check-ins’ are a critical opportunity to recalibrate, and advance the depth and success of project and contributor success.  Participation shifts, and evolves with the project, it only makes sense to pay attention to those subtle changes. As a result of these conversations, and  analysis we’re starting to see a shift towards a new innovative approaches.

    The lab has also observed a number of trends in terms of what people struggle with most in establishing and measuring their participation experiments, and themes in how we’re trying to solve for better participation.  All of this is leading to more insightful prototyping and execution of participation goals, and in the spirit of the virtuous circle : amplifying impact on contributor success and sense of value, and project goals.

    Education & Training, Evangelism and Representation, and Market Research were identified as our top three themes in the nearly fifty projects we’re following. Learn more about these themes and how they’re being implemented below.

    Education & Training

    Community Education was at the heart of many initiatives we’re following. Many working hypothesis include education and training as a connective tissue for community building and  development of future leaders.  Almost all had a working theory, that through education and training we can build content and generate meaningful outcomes to project as part of learning outcomes.

    Marketpulse

    By building and training a community of core contributors in Market Research, Marketpulse aims to collect data about phone sales in target markets. This project encourages contribution through a series of participation steps, each with complementary training. Marketpulse also recently completed a four-week online course “Interviewing Users for Mozilla” which taught contributors this qualitative research skill in user research.  As a result of this project, Mozilla has gained user research on the “Large Screen Experience”.

    By “Interviewing Users for Mozilla” course participant: Sukanta Pal

    MDN Fellowship

    The Developer Fellowship program provides a model for Mozilla and advanced developers to work together more extensively, allowing Mozilla to gain outside expertise and influence to help build our curriculum, shape our products and evangelize our programs.

    Mozilla Security Project – Securing Web @ZAP

    Is a volunteer-lend series of workshops for students and security enthusiasts. During  the workshop, participants are trained in ways to detect the threats  by performing security attacks using the ZAP security tool.  At it’s core this project is about teaching people about security by contributing to Zap.  Each week focuses on a different method of contribution: source code, creating extensions and addons, documentation and localization. Hypothesis is that by teaching participation as part of curriculum we can gain a greater base of contributors as a result. Very cool!

    Sumath’s Hypothesis is that by embedding contribution opportunities in education & training we can improve the number of, and quality of contributions, and help spread Mozilla’s mission to more people.

    Evangelism and Representation

    Mozilla’s community reaches around the globe, with diversity so great it’s an exciting to imagine the potential of volunteers empowered to share, speak and advocate for Mozilla’s mission.  It makes a lot of sense to work on mechanisms for this type participation. Common hypothesis are that word of mouth marketing is an extremely valuable tool for promotion and that empowering community members with more skills and avenues to share their passion for Mozilla will help raise awareness of Mozilla and Firefox.

    Firefox Friends

    Firefox Friends a program that take advantage of the existing passion of the Mozilla community to make it easier for people to share their love of Mozilla and Firefox within their social networks. Firefox Friends is exploring the hypothesis that providing the community with a tool for collecting and sharing Firefox oriented content will increase awareness and growth of Firefox.  To make it easier for community members to spread the word about Firefox and Firefox initiative,

    Tech Speakers

    Tech Speakers was a six week program combining group speaking practice and technical content development. A fantastic curriculum, combined with live mentorship opportunities is resulting in a growing base of high-quality volunteer speakers.

    Market Understanding

    Mozilla serves users in markets all over the world.  To deliver useful insights and research that will help product and functional teams be successful we’re seeing deep investment in  Mozilla’s global community to bring a competitive edge.

    Firefox OS Core Team Africa

    With Fx OS launching in 21 African countries in 2015 , there is an opportunity to test a new approach to building new relationships and new communities of supporters/volunteers across the continent.  A series of experiments. Goals have been to build out programs that to get new contributors involved in Firefox OS activities to increase awareness on the product and make an impact on product goals

    Webmaker Research

    By creating a launch playbook modeled after Firefox OS we will be able to create launch teams in target markets, this will result in a number of new users. Supporting local content leads we will be able to generate original content and learn from local communities in order to deliver and build a more effective localized product and content.

    Marketpulse

    The Firefox OS team has embarked on many different initiatives and campaigns to bring Firefox OS to market without always having sufficient understanding and knowledge of the reality on the ground, due to a lack of local market data. This local market data is extremely difficult to obtain, let alone, update regularly if you’re not actually on the ground. Leveraging the Marketpulse tool  community regularly collects price and user data for Firefox OS phones in their local market and web stores providing this much needed data.

    You can see there’s a lot going on,  and that even within each of these projects multiple experiments are taking place.  There’s a lot to be excited about in the coming months for participation at Mozilla. You can track the this and other Participation Team activity through our Heartbeat tool, or by reaching out to us directly.  In the near future, we’ll surface more concrete examples of what we’re learning,  and we expect, celebrating the new successes in participation at Mozilla.

    We’re in Whistler next week, check out for Lucy’s post on what we’ll be up to there!

    Air MozillaWebdev Beer and Tell: June 2015

    Webdev Beer and Tell: June 2015 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 in...

    Mozilla Add-ons BlogNew add-on community forum

    For a few years we have been running a forum for add-on developers. It’s linked to from the Developer Hub on AMO and has been a good place for discussions about add-ons, particularly add-on development. Unfortunately, we haven’t had the time or resources to keep it properly running and up to date. The software it runs on (phpBB) is notoriously unstable and difficult to manage. It’s time for a change.

    We’ve set up an Add-ons category in the Mozilla Community forum. This is the new official home for discussions about add-ons. Its main benefits are better integration with the larger Mozilla community, authentication with Persona (also used on Bugzilla, MDN, and others), reliable maintenance by Community IT, and running on a more modern forum platform called Discourse. With Discourse you can subscribe to posts or entire categories and interact with them like you would with a mailing list, which great for those who (like me) prefer a more old school approach.

    This is the current plan for the forum move:

    1. On July 1st, the old forum will be switched to read-only mode. In the meantime we’ll encourage all current forum users to move to the new one.
    2. On September 1st, the old forum will be decommissioned. We might try to keep a static copy of its contents somewhere, but for now you should assume that all content will be lost. We looked into migrating the old content to the new forum, but getting all the right sign-offs (legal, IT, security, etc.) proved to be too much for it to be worthwhile.

    There are more details about the move in this announcement.

    We’re very excited to join the rest of the Mozilla community in the new Discourse forum. Please give it a try and join the discussion!

    SUMO BlogWhat’s up with SUMO – 19th June

    Hello, SUMO Nation! Another Friday, another chance to update you about all things big and small happening in SUMOland. Welcome to SUMO, Wherever You Are! Tirtha4 adejong shaunmbg FriendlyMatrix MD. AL EMRAN Tajmin Artful jakamusic jar92 premm krishna shenoy animegz … Continue reading

    hacks.mozilla.orgES6 In Depth: Collections

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    Earlier this week, the ES6 specification, officially titled ECMA-262, 6th Edition, ECMAScript 2015 Language Specification, cleared the final hurdle and was approved as an Ecma standard. Congratulations to TC39 and everyone who contributed. ES6 is in the books!

    Even better news: it will not be six more years before the next update. The standard committee now aims to produce a new edition roughly every 12 months. Proposals for the 7th Edition are already in development.

    It is appropriate, then, to celebrate this occasion by talking about something I’ve been eager to see in JS for a long time—and which I think still has some room for future improvement!

    Hard cases for coevolution

    JS isn’t quite like other programming languages, and sometimes this influences the evolution of the language in surprising ways.

    ES6 modules are a good example. Other languages have module systems. Racket has a great one. Python too. When the standard committee decided to add modules to ES6, why didn’t they just copy an existing system?

    JS is different, because it runs in web browsers. I/O can take a long time. Therefore JS needs a module system that can support loading code asynchronously. It can’t afford to serially search for modules in multiple directories, either. Copying existing systems was no good. The ES6 module system would need to do some new things.

    How this influenced the final design is an interesting story. But we’re not here to talk about modules.

    This post is about what the ES6 standard calls “keyed collections”: Set, Map, WeakSet, and WeakMap. These features are, in most respects, just like the hash tables in other languages. But the standard committee made some interesting tradeoffs along the way, because JS is different.

    Why collections?

    Anyone familiar with JS knows that there’s already something like a hash table built into the language: objects.

    A plain Object, after all, is pretty much nothing but an open-ended collection of key-value pairs. You can get, set, and delete properties, iterate over them—all the things a hash table can do. So why add a new feature at all?

    Well, many programs do use plain objects to store key-value pairs, and for programs where this works well, there is no particular reason to switch to Map or Set. Still, there are some well-known issues with using objects this way:

    • Objects being used as lookup tables can’t also have methods, without some risk of collision.

    • Therefore programs must either use Object.create(null) (rather than plain {}) or exercise care to avoid misinterpreting builtin methods (like Object.prototype.toString) as data.

    • Property keys are always strings (or, in ES6, symbols). Objects can’t be keys.

    • There’s no efficient way to ask how many properties an object has.

    ES6 adds a new concern: plain objects are not iterable, so they will not cooperate with the forof loop, the ... operator, and so on.

    Again, there are plenty of programs where none of that really matters, and a plain object will continue to be the right choice. Map and Set are for the other cases.

    Because they are designed to avoid collisions between user data and builtin methods, the ES6 collections do not expose their data as properties. This means that expressions like obj.key or obj[key] cannot be used to access hash table data. You’ll have to write map.get(key). Also, hash table entries, unlike properties, are not inherited via the prototype chain.

    The upside is that, unlike plain Objects, Map and Set do have methods, and more methods can be added, either in the standard or in your own subclasses, without conflict.

    Set

    A Set is a collection of values. It’s mutable, so your program can add and remove values as it goes. So far, this is just like an array. But there are as many differences between sets and arrays as there are similarities.

    First, unlike an array, a set never contains the same value twice. If you try to add a value to a set that’s already in there, nothing happens.

    > var desserts = new Set("🍪🍦🍧🍩");
    > desserts.size
        4
    > desserts.add("🍪");
        Set [ "🍪", "🍦", "🍧", "🍩" ]
    > desserts.size
        4
    

    This example uses strings, but a Set can contain any type of JS value. Just as with strings, adding the same object or number more than once has no added effect.

    Second, a Set keeps its data organized to make one particular operation fast: membership testing.

    > // Check whether "zythum" is a word.
    > arrayOfWords.indexOf("zythum") !== -1  // slow
        true
    > setOfWords.has("zythum")               // fast
        true
    

    What you don’t get with a Set is indexing:

    > arrayOfWords[15000]
        "anapanapa"
    > setOfWords[15000]   // sets don't support indexing
        undefined
    

    Here are all the operations on sets:

    • new Set creates a new, empty set.

    • new Set(iterable) makes a new set and fills it with data from any iterable value.

    • set.size gets the number of values in the set.

    • set.has(value) returns true if the set contains the given value.

    • set.add(value) adds a value to the set. If the value was already in the set, nothing happens.

    • set.delete(value) removes a value from the set. If the value wasn’t in the set, nothing happens. Both .add() and .delete() return the set object itself, so you can chain them.

    • set[Symbol.iterator]() returns a new iterator over the values in the set. You won’t normally call this directly, but this method is what makes sets iterable. It means you can write for (v of set) {...} and so on.

    • set.forEach(f) is easiest to explain with code. It’s like shorthand for:

      for (let value of set)
          f(value, value, set);
      

      This method is analogous to the .forEach() method on arrays.

    • set.clear() removes all values from the set.

    • set.keys(), set.values(), and set.entries() return various iterators. These are provided for compatibility with Map, so we’ll talk about them below.

    Of all these features, the constructor new Set(iterable) stands out as a powerhouse, because it operates at the level of whole data structures. You can use it to convert an array to a set, eliminating duplicate values with a single line of code. Or, pass it a generator: it will run the generator to completion and collect the yielded values into a set. This constructor is also how you copy an existing Set.

    I promised last week to complain about the new collections in ES6. I’ll start here. As nice as Set is, there are some missing methods that would make nice additions to a future standard:

    • Functional helpers that are already present on arrays, like .map(), .filter(), .some(), and .every().

    • Non-mutating set1.union(set2) and set1.intersection(set2).

    • Methods that can operate on many values at once: set.addAll(iterable), set.removeAll(iterable), and set.hasAll(iterable).

    The good news is that all of these can be implemented efficiently using the methods provided by ES6.

    Map

    A Map is a collection of key-value pairs. Here’s what Map can do:

    • new Map returns a new, empty map.

    • new Map(pairs) creates a new map and fills it with data from an existing collection of [key, value] pairs. pairs can be an existing Map object, an array of two-element arrays, a generator that yields two-element arrays, etc.

    • map.size gets the number of entries in the map.

    • map.has(key) tests whether a key is present (like key in obj).

    • map.get(key) gets the value associated with a key, or undefined if there is no such entry (like obj[key]).

    • map.set(key, value) adds an entry to the map associating key with value, overwriting any existing entry with the same key (like obj[key] = value).

    • map.delete(key) deletes an entry (like delete obj[key]).

    • map.clear() removes all entries from the map.

    • map[Symbol.iterator]() returns an iterator over the entries in the map. The iterator represents each entry as a new [key, value] array.

    • map.forEach(f) works like this:

      for (let [key, value] of map)
        f(value, key, map);
      

      The odd argument order is, again, by analogy to Array.prototype.forEach().

    • map.keys() returns an iterator over all the keys in the map.

    • map.values() returns an iterator over all the values in the map.

    • map.entries() returns an iterator over all the entries in the map, just like map[Symbol.iterator](). In fact, it’s just another name for the same method.

    What is there to complain about? Here are some features not present in ES6 that I think would be useful:

    • A facility for default values, like Python’s collections.defaultdict.

    • A helper function, Map.fromObject(obj), to make it easy to write maps using object-literal syntax.

    Again, these features are easy to add.

    OK. Remember how I started this article with a bit about how unique concerns about running in the browser affect the design of JS language features? This is where we start to talk about that. I’ve got three examples. Here are the first two.

    JS is different, part 1: Hash tables without hash codes?

    There’s one useful feature that the ES6 collection classes do not support at all, as far as I can tell.

    Suppose we have a Set of URL objects.

    var urls = new Set;
    urls.add(new URL(location.href));  // two URL objects.
    urls.add(new URL(location.href));  // are they the same?
    alert(urls.size);  // 2
    

    These two URLs really ought to be considered equal. They have all the same fields. But in JavaScript, these two objects are distinct, and there is no way to overload the language’s notion of equality.

    Other languages support this. In Java, Python, and Ruby, individual classes can overload equality. In many Scheme implementations, individual hash tables can be created that use different equality relations. C++ supports both.

    However, all of these mechanisms require users to implement custom hashing functions and all expose the system’s default hashing function. The committee chose not to expose hash codes in JS—at least, not yet—due to open questions about interoperability and security, concerns that are not as pressing in other languages.

    JS is different, part 2: Surprise! Predictability!

    You would think that deterministic behavior from a computer could hardly be surprising. But people are often surprised when I tell them that Map and Set iteration visits entries in the order they were inserted into the collection. It’s deterministic.

    We’re used to certain aspects of hash tables being arbitrary. We’ve learned to accept it. But there are good reasons to try to avoid arbitrariness. As I wrote in 2012:

    • There is evidence that some programmers find arbitrary iteration order surprising or confusing at first. [1][2][3][4][5][6]
    • Property enumeration order is unspecified in ECMAScript, yet all the major implementations have been forced to converge on insertion order, for compatibility with the Web as it is. There is, therefore, some concern that if TC39 does not specify a deterministic iteration order, “the web will just go and specify it for us”.[7]
    • Hash table iteration order can expose some bits of object hash codes. This imposes some astonishing security concerns on the hashing function implementer. For example, an object’s address must not be recoverable from the exposed bits of its hash code. (Revealing object addresses to untrusted ECMAScript code, while not exploitable by itself, would be a bad security bug on the Web.)

    When all this was being discussed back in February 2012, I argued in favor of arbitrary iteration order. Then I set out to show by experiment that keeping track insertion order would make a hash table too slow. I wrote a handful of C++ microbenchmarks. The results surprised me.

    And that’s how we ended up with hash tables that track insertion order in JS!

    Strong reasons to use weak collections

    Last week, we discussed an example involving a JS animation library. We wanted to store a boolean flag for every DOM object, like this:

    if (element.isMoving) {
      smoothAnimations(element);
    }
    element.isMoving = true;
    

    Unfortunately, setting an expando property on a DOM object like this is a bad idea, for reasons discussed in the original post.

    That post showed how to solve this problem using symbols. But couldn’t we do the same thing using a Set? It might look like this:

    if (movingSet.has(element)) {
      smoothAnimations(element);
    }
    movingSet.add(element);
    

    There is only one drawback: Map and Set objects keep a strong reference to every key and value they contain. This means that if a DOM element is removed from the document and dropped, garbage collection can’t recover that memory until that element is removed from movingSet as well. Libraries typically have mixed success, at best, in imposing complex clean-up-after-yourself requirements on their users. So this could lead to memory leaks.

    ES6 offers a surprising fix for this. Make movingSet a WeakSet rather than a Set. Memory leak solved!

    This means it is possible to solve this particular problem using either a weak collection or symbols. Which is better? A full discussion of the tradeoffs would, unfortunately, make this post a little too long. If you can use a single symbol across the whole lifetime of the web page, that’s probably fine. If you end up wanting many short-lived symbols, that’s a danger sign: consider using WeakMaps instead to avoid leaking memory.

    WeakMap and WeakSet

    WeakMap and WeakSet are specified to behave exactly like Map and Set, but with a few restrictions:

    • WeakMap supports only new, .has(), .get(), .set(), and .delete().

    • WeakSet supports only new, .has(), .add(), and .delete().

    • The values stored in a WeakSet and the keys stored in a WeakMap must be objects.

    Note that neither type of weak collection is iterable. You can’t get entries out of a weak collection except by asking for them specifically, passing in the key you’re interested in.

    These carefully crafted restrictions enable the garbage collector to collect dead objects out of live weak collections. The effect is similar to what you could get with weak references or weak-keyed dictionaries, but ES6 weak collections get the memory management benefits without exposing the fact that GC happened to scripts.

    JS is different, part 3: Hiding GC nondeterminism

    Behind the scenes, the weak collections are implemented as ephemeron tables.

    In short, a WeakSet does not keep a strong reference to the objects it contains. When an object in a WeakSet is collected, it is simply removed from the WeakSet. WeakMap is similar. It does not keep a strong reference to any of its keys. If a key is alive, the associated value is alive.

    Why accept these restrictions? Why not just add weak references to JS?

    Again, the standard committee has been very reluctant to expose nondeterministic behavior to scripts. Poor cross-browser compatibility is the bane of Web development. Weak references expose implementation details of the underlying garbage collector—the very definition of platform-specific arbitrary behavior. Of course applications shouldn’t depend on platform-specific details, but weak references also make it very hard to know just how much you’re depending on the GC behavior in the browser you’re currently testing. They’re hard to reason about.

    By contrast, the ES6 weak collections have a more limited feature set, but that feature set is rock solid. The fact that a key or value has been collected is never observable, so applications can’t end up depending on it, even by accident.

    This is one case where a Web-specific concern has led to a surprising design decision that makes JS a better language.

    When can I use collections in my code?

    All four collection classes are currently shipping in Firefox, Chrome, Microsoft Edge, and Safari. To support older browsers, use a polyfill, like es6-collections.

    WeakMap was first implemented in Firefox by Andreas Gal, who went on to a stint as Mozilla’s CTO. Tom Schuster implemented WeakSet. I implemented Map and Set. Thanks to Tooru Fujisawa for contributing several patches in this area.

    Next week, ES6 In Depth starts a two-week summer break. This series has covered a lot of ground, but some of ES6’s most powerful features are yet to come. So please join us when we return with new content on July 9.

    Mozilla Add-ons BlogAdd-on Compatibility for Firefox 40

    Firefox 40 will be released on August 11th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 40 for Developers, so you should also give it a look.

    Extension signing

    • This is the first version of Firefox that will enforce our new signing requirements. All AMO add-ons have already been signed and we’re in the process of reviewing non-AMO add-ons. In this version, there’s a preference to disable the signing requirement (xpinstall.signatures.required), which will be removed in 41.

    General

    XPCOM

    Themes

    Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 40, I’d like to know.

    The automatic compatibility validation and upgrade for add-ons on AMO will happen in the coming weeks, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 39.

    Air MozillaGerman speaking community bi-weekly meeting

    German speaking community bi-weekly meeting Zweiwöchentliches Meeting der deutschsprachigen Community. ==== German speaking community bi-weekly meeting.

    hacks.mozilla.orgES6 In Depth: Using ES6 today with Babel and Broccoli

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    ES6 is here, and people are already talking about ES7, what the future holds, and what shiny features a new standard can offer. As web developers, we wonder how we can make use of it all. More than once, in previous ES6 In Depth posts, we’ve encouraged you to start coding in ES6, with a little help from some interesting tools. We’ve teased you with the possibility:

    If you’d like to use this new syntax on the Web, you can use Babel or Google’s Traceur to translate your ES6 code to web-friendly ES5.

    Today we’re going to show you step-by-step how it is done. The above-mentioned tools are called transpilers. A transpiler is also known as a source-to-source compiler—a compiler that translates between programming languages operating at comparable levels of abstraction. Transpilers let us write code using ES6 while also guaranteeing that we’ll be able to execute the code in every browser.

    Transpilation our salvation

    A transpiler is very easy to use. You can describe what it does in only two steps:

    1. We write code with ES6 syntax.

    let q = 99;
    let myVariable = `${q} bottles of beer on the wall, ${q} bottles of beer.`;
    

    2. We use the code above as input for the transpiler, which will process it and produce the following output:

    "use strict";
    
    var q = 99;
    var myVariable = "" + q + " bottles of beer on the wall, " + q + " bottles of beer."
    

    This is the good old JavaScript we know. It can be used in any browser.

    The internals of how a transpiler goes from input to output are highly complex and fall out of scope for this article. Just as we can drive a car without knowing all the internal engine mechanics, today we’ll leave the transpiler as a black box that is able to process our code.

    Babel in action

    There are a couple of different ways to use Babel in a project. There is a command line tool, which you can use with commands of the form:

    babel script.js --out-file script-compiled.js
    

    A browser-ready version is also available. You can include Babel as a regular JS library and then you can place your ES6 code in script tags with the type "text/babel".

    <script src="node_modules/babel-core/browser.js"></script>
    <script type="text/babel">
    // Your ES6 code
    </script>
    

    These methods do not scale when your code base starts to grow and you start splitting everything into multiple files and folders. At that moment, you’ll need a build tool and a way to integrate Babel with a build pipeline.

    In the following sections, we’ll integrate Babel into a build tool, Broccoli.js, and we’ll write and execute our first lines of ES6 through a couple of examples. In case you run into trouble, you can review the complete source code here: broccoli-babel-examples. Inside the repository you’ll find three sample projects:

    1. es6-fruits
    2. es6-website
    3. es6-modules

    Each one builds on the previous example. We start with the bare minimum and progress to a general solution, which can be used as the starting point of an ambitious project. In this post, we’ll cover the first two examples in detail. After we are done, you’ll be able to read and understand the code in the third example on your own.

    If you are thinking —I’ll just wait for browsers to support the new features— you’ll be left behind. Full compliance, if it ever happens, will take a long time. Transpilers are here to stay; new ECMAScript standards are planned to be released yearly. So, we’ll continue to see new standards released more often than uniform browser platforms. Hop in now and take advantage of the new features.

    Our first Broccoli & Babel project

    Broccoli is a tool designed to build projects as quickly as possible. You can uglify and minify files, among many other things, through the use of Broccoli plugins. It saves us the burden of handling files, directories, and executing commands each time we introduce changes to a project. Think of it as:

    Comparable to the Rails asset pipeline in scope, though it runs on Node and is backend-agnostic.

    Project setup

    Node

    As you might have guessed, you’ll have to install Node 0.11 or later.

    If you are in a unix system, avoid installing from the package manager (apt, yum). That is to avoid using root privileges during installation. It’s best to manually install the binaries, provided at the previous link, with your current user. You can read why using root is not recommended in Do not sudo npm. In there you’ll find other installation alternatives.

    Broccoli

    We’ll set up our Broccoli project first with:

    mkdir es6-fruits
    cd es6-fruits
    npm init
    # Create an empty file called Brocfile.js
    touch Brocfile.js
    

    Now we install broccoli and broccoli-cli

    # the broccoli library
    npm install --save-dev broccoli
    # command line tool
    npm install -g broccoli-cli
    

    Write some ES6

    We’ll create a src folder and inside we’ll put a fruits.js file.

    mkdir src
    vim src/fruits.js
    

    In our new file we’ll write a small script using ES6 syntax.

    let fruits = [
      {id: 100, name: 'strawberry'},
      {id: 101, name: 'grapefruit'},
      {id: 102, name: 'plum'}
    ];
    
    for (let fruit of fruits) {
      let message = `ID: ${fruit.id} Name: ${fruit.name}`;
    
      console.log(message);
    }
    
    console.log(`List total: ${fruits.length}`);
    

    The code sample above makes use of three ES6 features:

    1. let for local scope declarations (to be discussed in an upcoming blog post)
    2. for-of loops
    3. template strings

    Save the file and try to execute it.

    node src/fruits.js
    

    It won’t work yet, but we are about to make it executable by Node and any browser.

    let fruits = [
        ^^^^^^
    SyntaxError: Unexpected identifier
    

    Transpilation time

    Now we’ll use Broccoli to load our code and push it through Babel. We’ll edit the file Brocfile.js and add this code to it:

    // import the babel plugin
    var babel = require('broccoli-babel-transpiler');
    
    // grab the source and transpile it in 1 step
    fruits = babel('src'); // src/*.js
    
    module.exports = fruits;
    

    Notice that we require broccoli-babel-transpiler, a Broccoli plugin that wraps around the Babel library, so we must install it with:

    npm install --save-dev broccoli-babel-transpiler
    

    Now we can build our project and execute our script with:

    broccoli build dist # compile
    node dist/fruits.js # execute ES5
    

    The output should look like this:

    ID: 100 Name: strawberry
    ID: 101 Name: grapefruit
    ID: 102 Name: plum
    List total: 3
    

    That was easy! You can open dist/fruits.js to see what the transpiled code looks like. A nice feature of the Babel transpiler is that it produces readable code.

    Writing ES6 code for a website

    For our second example we’ll take it up a notch. First, exit the es6-fruits folder and create a new directory es6-website using the steps listed under Project setup above.

    In the src folder we’ll create three files:

    src/index.html

    <!DOCTYPE html>
    <html>
      <head>
        <title>ES6 Today</title>
      </head>
      <style>
        body {
          border: 2px solid #9a9a9a;
          border-radius: 10px;
          padding: 6px;
          font-family: monospace;
          text-align: center;
        }
        .color {
          padding: 1rem;
          color: #fff;
        }
      </style>
      <body>
        <h1>ES6 Today</h1>
        <div id="info"></div>
        <hr>
        <div id="content"></div>
    
        <script src="//code.jquery.com/jquery-2.1.4.min.js"></script>
        <script src="js/my-app.js"></script>
      </body>
    </html>
    

    src/print-info.js

    function printInfo() {
      $('#info')
      .append('<p>minimal website example with' +
              'Broccoli and Babel</p>');
    }
    
    $(printInfo);
    

    src/print-colors.js

    // ES6 Generator
    function* hexRange(start, stop, step) {
      for (var i = start; i < stop; i += step) {
        yield i;
      }
    }
    
    function printColors() {
      var content$ = $('#content');
    
      // contrived example
      for ( var hex of hexRange(900, 999, 10) ) {
        var newDiv = $('<div>')
          .attr('class', 'color')
          .css({ 'background-color': `#${hex}` })
          .append(`hex code: #${hex}`);
        content$.append(newDiv);
      }
    }
    
    $(printColors);
    

    You might have noticed this bit: function* hexRange — yes, that’s an ES6 generator. This feature is not currently supported in all browsers. To be able to use it, we’ll need a polyfill. Babel provides this and we’ll put it to use very soon.

    The next step is to merge all the JS files and use them within a website. The hardest part is writing our Brocfile. This time we install 4 plugins:

    npm install --save-dev broccoli-babel-transpiler
    npm install --save-dev broccoli-funnel
    npm install --save-dev broccoli-concat
    npm install --save-dev broccoli-merge-trees
    

    Let’s put them to use:

    // Babel transpiler
    var babel = require('broccoli-babel-transpiler');
    // filter trees (subsets of files)
    var funnel = require('broccoli-funnel');
    // concatenate trees
    var concat = require('broccoli-concat');
    // merge trees
    var mergeTrees = require('broccoli-merge-trees');
    
    // Transpile the source files
    var appJs = babel('src');
    
    // Grab the polyfill file provided by the Babel library
    var babelPath = require.resolve('broccoli-babel-transpiler');
    babelPath = babelPath.replace(/\/index.js$/, '');
    babelPath += '/node_modules/babel-core';
    var browserPolyfill = funnel(babelPath, {
      files: ['browser-polyfill.js']
    });
    
    // Add the Babel polyfill to the tree of transpiled files
    appJs = mergeTrees([browserPolyfill, appJs]);
    
    // Concatenate all the JS files into a single file
    appJs = concat(appJs, {
      // we specify a concatenation order
      inputFiles: ['browser-polyfill.js', '**/*.js'],
      outputFile: '/js/my-app.js'
    });
    
    // Grab the index file
    var index = funnel('src', {files: ['index.html']});
    
    // Grab all our trees and
    // export them as a single and final tree
    module.exports = mergeTrees([index, appJs]);
    

    Time to build and execute our code.

    broccoli build dist
    

    This time you should see the following structure in the dist folder:

    $> tree dist/
    dist/
    ├── index.html
    └── js
        └── my-app.js
    

    That is a static website you can serve with any server to verify that the code is working. For instance:

    cd dist/
    python -m SimpleHTTPServer
    # visit http://localhost:8000/
    

    You should see this:

    simple ES6 website

    More fun with Babel and Broccoli

    The second example above gives an idea of how much we can accomplish with Babel. It might be enough to keep you going for a while. If you want to do more with ES6, Babel, and Broccoli, you should check out this repository: broccoli-babel-boilerplate. It is also a Broccoli+Babel setup, that takes it up at least two notches. This boilerplate handles modules, imports, and unit testing.

    You can try an example of that configuration in action here: es6-modules. All the magic is in the Brocfile and it’s very similar to what we have done already.


    As you can see, Babel and Broccoli really do make it quite practical to use ES6 features in web sites right now. Thanks to Gastón I. Silva for contributing this week’s post!

    Next week, ES6 In Depth starts a two-week summer break. This series has covered a lot of ground, but some of ES6’s most powerful features are yet to come. So please join us when we return with new content on July 9.

    Jason Orendorff

    ES6 In Depth Editor

    Meeting NotesMobile: 2015-06-17

    Schedule

    Topics for This Week

    Tracking Review

    Release

    • Next Build:
    ID Summary Status Assigned to Last change time
    1159049 x86 Android is sent the OpenH264 plugin for ARM Android NEW Chris AtLee [:catlee] (catlee) 2015-06-10T16:48:06Z
    1172347 Homescreen search widget not usable with physical keyboard ASSIGNED :Sebastian Kaspari (s.kaspari) 2015-06-17T23:33:11Z


    2 Total;
    2 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Beta

    • Next Build:
    ID Summary Status Assigned to Last change time
    1150284 [Browser] Unable to zoom in/out on Google Maps ASSIGNED Robert O’Callahan (:roc) (Mozilla Corporation) (roc) 2015-06-17T17:02:38Z
    1173388 Cookies settings are not always kept after browser restart ASSIGNED Chenxia Liu [:liuche] (liuche) 2015-06-16T14:15:51Z


    2 Total;
    2 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Aurora

    • Next Build:
    ID Summary Status Assigned to Last change time
    789193 AMI_startup() takes 200ms on mobile, 26ms on desktop at startup NEW Jim Chen [:jchen] [:darchons] (nchen) 2015-04-21T19:20:16Z
    1120511 Autophone – Twitter Throbber stop regression 2015-01-15 REOPENED Seth Fowler [:seth] (seth) 2015-05-01T02:34:20Z
    1153844 Can’t select tracking flags on new bugs submitting page NEW 2015-04-24T12:19:40Z
    1163937 Downloads are not cleared from about:downloads when “Clear on exit” is used ASSIGNED :Margaret Leibovic (margaret.leibovic) 2015-05-27T16:43:42Z
    1169359 Investigate Fx Android interactions with Android M permission disabling ASSIGNED :Sebastian Kaspari (s.kaspari) 2015-06-12T09:25:11Z


    5 Total;
    5 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Nightly

    • Next Build:
    ID Summary Status Assigned to Last change time
    1047127 Panning very stuttery on this page with overflow-x NEW 2015-06-10T18:43:44Z
    1114096 Wrong tab got mirrored NEW 2015-06-17T18:30:58Z
    1126244 Create a maximum reader mode cache size and evict records when necessary ASSIGNED Vivek Balakrishnan[:vivek] (vivekb.balakrishnan) 2015-04-30T17:08:28Z
    1131084 Can not mirror tab to Chromecast device NEW Randall Barker [:rbarker] (rbarker) 2015-06-17T18:31:14Z
    1148391 Tapping the bottom of the screen will make the reader mode toolbar bounce up and down NEW 2015-05-28T17:18:33Z
    1156553 Tab queue makes captive portal use annoying ASSIGNED Martyn Haigh (:mhaigh) (mhaigh) 2015-05-27T16:59:23Z
    1171860 Tapping the tab queue notification will open the link in normal browsing with “Open links in Private browsing” pref enabled NEW 2015-06-08T17:30:23Z


    7 Total;
    7 Open (100%);
    0 Resolved (0%);
    0 Verified (0%);

    Friends of the Mobile Team

    Give a shoutout/thanks to people for helping fix and test bugs. Make sure friends also get awarded a badge. New contributors are highlighted in bold.

    Stand ups

    Suggested format:

    • What did you do last week?
    • What are working on this week?
    • Anything blocking you?

    Please keep your update to under 2 minutes!

    James W. (snorp)

    • Worked on some build system junk to enable colorized warnings/errors, bug 1171610 (need to push)
    • Got a couple patches up for feedback for paint throttling, bug 1150172
      • Dramatically improves page load speed (up to 50%)
      • Reduces power consumption
      • Needs some tweaks still, but I hope to land before or during Whistler

    JChen

    Fixed
    Working on

    GCP

    • Last week
      • Video sandboxing: Mac and Windows failures fixed, all green on try now, patches up for review
    • Next week
      • bug 1175562 Persist last update time for updates/gethash completion
      • Whistler prep work

    Randall Barker

    Last Week:

    • Landed: bug 1163664 Don’t check for plugin blocklist state on Android.
    • Uplifted to beta and aurora: bug 1159830 Autophone – webappstartup should not use console.log to output WEBAPP STARTUP COMPLETE
    • Working through review: bug 1173844 – Video would not playback after seek seekbar if media.autoplay.enabled = false
    • Investigating: bug 1171337 – black window during browsing

    Next Week:

    • Continue examining bug 1171337 – black window during browsing
    • Get reviewed: bug 1166961 Re-enable missing video UI when element does not have controls.
    • Land: bug 1173844 – Video would not playback after seek seekbar if media.autoplay.enabled = false
    • Work Week.

    Note: Will be on PTO June 29 -July 20.

    Eugen Sawin

    • MP3 demuxer
      • Looking into intermittent initialization issues
    • Startup performance optimization
      • Landed on-demand loading of Webapps.jsm (1171013)
      • Looking into on-demand loading of heavy modules (XPIProvider.jsm, GMPProvider.jsm)
    Fixed
    Working on

    Bryan Munar

    1. Sad that Brian is on PTO for forever (3 weeks) :(
    2. Happy that Whistler!!!!!

    Finished:

    Working On:

    WesJ

    • Family visiting
    • Still pounding on sqlcipher. bug 1147071 – Use encrypted database storage for passwords
    • Reviews

    liuche

    Highlights:

    • More doorhangers work
    • Apparently testSettingsMenuItems is turned off – trying to fix it to re-enable

    Present:

    Past:

    karim

    Past:

    • WWDC!

    Present:

    • 602818 – Integrate QR code scanner into Fennec
    • 1132125 – show voice input UI in New Tab’s default URL bar

    Margaret

    Highlights:

    • Add-on signing UI
    • Planning for privacy-focused Fx42
    • Talking with participation team about effort to promote Fennec in India
    • PTO Thursday afternoon/Friday

    Past:

    Present:

    jonalmeida

    mcomella

    Past:

    Present:

    rnewman

    Fixed
    Working on

    nalexander

    <Read Only>

    • Partners
    • Contributors: working with Ahmed and vivek this week.
      • vivek is leading the push for Firefox Account profile avatars in Firefox 42 \o/
      • First ticket landed: bug 1055264, next in review: bug 1171141
    • Testing:
      • Still need a blog post for mach gradle runBrowserTests
      • Still need a blog post mach robocop --serve
    • mach package-frontend: pushed for re-review but gps is busy (?)
      • Using taskcluster and the local pushlog database to seamlessly fetch binaries
      • Working very well locally \o/

    Sebastian

    All:

    Martyn Haigh

    Past:

    Present:

    Stefan

    Past:

    Present:

    Steph

    Last week: Desktop/Android URL Bar Highlight algorithm

    Coming week:

    Ally

    • 1170786 about:logins v1 minimum shippable product
      • Part 2 of 1136477 Unify terminology of Passwords/Logins for about:logins (nee about:passwords) waiting on review
      • 1148524 Add “edit login” option in about:passwords context menu
      • Bug 1144413 – Remove “details” page from about:passwords (done)
    • Other
      • 1174878 Update robocop test testSettingsMenuItems.java to use StringHelper.java in all cases
      • 1141769 Implement new style(unified) FHR/Telemetry password manager probes (waiting on 2nd r+)
      • reviews

    Emily

    Highlights:

    • WWDC
    • Jetlag
    • Getting into Sync

    Closed:

    Current:

    BLassey

    Fixed
    Working on

    Antlam

    • Past
      • Partner stuff
      • On-boarding for Android
      • Doorhangers bug triage
      • Passwords follow up
      • Private browsing improvements
      • Cleaning up about:addons
    • Upcoming
      • More of the same!
      • Prep for Whistler

    Robin

    Went to Palm Springs for YxYY, did all the things.

    iOS

    • Continuing to find any bugs, specifically UI-related.
    • Improve CSS for Reader View on iPad
    • Finalize spinner for loading Reading View/pull-to-refresh

    Android

    • Kinderfox: still reading all the research.

    Darrin

    Past:

    • WWDC!

    Present + Future:

    QA

    Feature Focus

    <Read Only>

    • Android Roadmap in Aha!
      • Not much changed this week.
      • ‘Option to always use private browsing’ holding on nightly channel pending outcome of user testing
    • Suggest new features for the Android Roadmap Here
    • iOS Roadmap in Aha!
    • Suggest new features for the iOS Roadmap Here
    • Priority #1/Biggest concern right now – finalizing our end-game plan to push V1.0 out the door! This is a goal for Whistler.
    • 2nd Priority – Start discussion/planning for V1.1 & V2.0… may get into this at Whistler if we can knock out Priority #1 above!

    Details

    • Wednesdays – 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
    • Dial-in: conference# 99998
      • US/Toll-free: +1 800 707 2533, (pin 369) Conf# 99998
      • US/California/Mountain View: +1 650 903 0800, x92 Conf# 99998
      • US/California/San Francisco: +1 415 762 5700, x92 Conf# 99998
      • US/Oregon/Portland: +1 971 544 8000, x92 Conf# 99998
      • CA/British Columbia/Vancouver: +1 778 785 1540, x92 Conf# 99998
      • CA/Ontario/Toronto: +1 416 848 3114, x92 Conf# 99998
      • UK/London: +44 (0)207 855 3000, x92 Conf# 99998
      • FR/Paris: +33 1 44 79 34 80, x92 Conf# 99998
    • irc.mozilla.org #mobile for backchannel
    • Mobile Vidyo Room

    Meeting NotesFirefox/Gecko Delivery Planning: 2015-06-17

    Schedule & Progress onUpcoming Releases (Liz/Sylvestre/Lawrence)

    • 39 beta 7 will release this Friday.
    • RC (release candidate) will be on the beta channel next Monday
    • still on track for June 30 release date.

    Firefox Desktop & Platform (Javaun/Chad/Martin)

    Current Releases

    • No update on runtime testing of GPU 1156135. Hasn’t landed yet.
    • Priv/sec team kicked off yesterday for 42 cycle (Control Center Security Block + TP in PBM)
    • 42 Nightly closes on Aug 10. We’re mindful of this and Dave Camp said we can’t be doing uplifts for anything but bug fixes. We’re also mindful of the L10N deadline.
    • We’re coordinating w/ android

    Firefox Mobile (Mark/Brad/Jenn)

    Firefox for iOS

    • Still waiting on go-ahead to add the large group of external testers. Hoping to kick off shortly with build 21.
    • Whistler Goal is to solidify End-Game plan with target dates

    Firefox for Android

    • No major juggling in the funnel this week. In general, no major risks to any of the features currently in development.
    Beta (39)
    • Planned Features On Track/Ready to Ship
    Aurora (40)
    • Planned Features On Track/Ready to Ship
    Nightly (41)

    Feedback Summary (Rob/Tyler/Matt)

    No updates


    Planning Meeting Details

    • Wednesdays – 11:00am PT, 18:00 UTC
    • Mountain View Offices: Warp Core Conference Room
    • Toronto Offices: Finch Conference Room
    • irc.mozilla.org #planning for backchannel
    • (the developer meeting takes place on Tuesdays)

    Video/Teleconference Details – NEW

    Air MozillaBrownbag: Interactive Documentary Screening of 'Do Not Track'

    Brownbag: Interactive Documentary Screening of 'Do Not Track' Join director Brett Gaylor for a screening and discussion of 'Do Not Track' (https://donottrack-doc.com), a personalized documentary series about privacy and the web economy.

    Air MozillaTech Talk: Adaptive Bitrate Streaming

    Tech Talk: Adaptive Bitrate Streaming Nick Desaulniers will be speaking on, "Adaptive Bitrate Streaming: Let's build a Netflix clone."

    Air MozillaProduct Coordination Meeting

    Product Coordination Meeting Duration: 10 minutes This is a weekly status meeting, every Wednesday, that helps coordinate the shipping of our products (across 4 release channels) in order...

    Meeting NotesChannel: 2015-06-16

    Attendees

    lmandel, sylvestre, kglazko, lizzard, kbrosnan, gfritzsche, thuelbert, kparlante, hwine, jorge, milan, mschmidt, rolandtanglao, ritu

    Schedule Update

    • 39 Beta 6 releases today for mobile and desktop
    • 39 beta 7 gtb Thursday, release Friday
    • RC gtb, beta to release migration, next Monday just before the workweek. Who from releng, (rail), QE, sheriffs, will be around in Whistler on Monday?
      • We can ask for the merge on Friday

    Signoffs should happen over email on release-drivers during the work week as the channel meeting will be cancelled.

    Add-ons

    • No updates.

    Stability

    RelEng

    • minor TCW this Saturday (june 20)
    • hope for change freeze during whistler

    User Advocacy

    Preliminary Pocket survey results look optimistic

    • Most people are neutral on Pocket, more positive than negative
    • Most people are neutral on 3rd party integration, more positive than negative

    Final Report by EOW

    Roundtable

    • Whistler sessions
      • Wed 10am Release Model/Process Feedback and post-mortem (tentative)
      • Fri 9am meet SoftVision
      • Fri 9:30am Firefox Rapid Release Review
      • Fri 10am Intermittent Oranges
      • Fri 11am Firefox updates: Balrog and Funsize

    Special Topics

    Aurora/Beta Feature Review


    Channel Meeting Details

    Video/Teleconference Details – NEW

    • 650-903-0800 or 650-215-1282 x92 Conf# 99951 (US/INTL)
    • 1-800-707-2533 (pin 369) Conf# 99951 (US)
    • Vidyo Room: ReleaseCoordination
    • Vidyo Guest URL

    Meeting NotesThunderbird: 2015-06-16

    Thunderbird meeting notes 2015-06-16. NOON PT (Pacific). Check https://wiki.mozilla.org/Thunderbird/StatusMeetings for meeting time conversion, previous meeting notes and call-in details

    Attendees

    rkent, wsmwk, sshagarwal, jorgk, joes1, jcranmer, mkmelin, rolandtanglao, makemyday

    Current status and discussions

    Critical Issues

    Leave critical bugs here until confirmed fixed. If confirmed, then remove.

    • see tb38 etherpad
    • tracking-tb38 flags – approved(+): http://tinyurl.com/nk3vbhl nominated(?): http://tinyurl.com/pgwflyg
    • Do we unthrottle updates for TB38?
      • suggest 10% for a couple days so we get more data, if there are no objections (wsmwk). we are roughly at 200k users or 1% of user population
      • JoeS1 FWIW Firefox unthrottles immediately to 25 for info, I think we should do the same
        • But I guess they do that because they are ready to do a point release if necessary, and we are not that ready
      • What is state of addons? (generally we don’t decide based on this, except maybe calendar)
      • Are there tracked bugs we want fixed before full unthrottle? (means waiting for 38.1.0)
    • rkent list of critical issues blocking even partial unthrottling:
      • broken Simplified Chinese bug 1174580 – Not display GB2312 encoded texts correctly
        • It might be possible to simply change the encoding mapping to fix this?
      • proxy not working bug 1175051 and probably related crashes
    • rkent list of other critical issues
      • Outlook/Eudora import completely busted: bug 1175055.
        • I suggest that for the next dot release, if we cannot get the crash fixed, we should disable the menu item that promotes this. Does not block unthrottling since mostly affects new users.
        • Someone needs to add additional main thread proxies to the migration code.
      • bug 1174797 Add a cookie exception for GMail OAuth
        • Does not affect unthrottling since no effect unless someone tries to use OAuth. Lightning has an example of how to fix this, so should not be difficult.

    Releases

    • Past
      • 31.6.0 shipped
      • 38.0b3 shipped 2015-04-26 Sunday
      • 38.0b4 shipped 2015-05-03 Sunday
      • 31.7.0 2015-05-18 Monday (lots of issues – Tues 5-12 was target)
      • 38.0b5 shipped 2015-05-19 Tuesday
      • 38.0b6 shipped 2015-05-23
      • 38.0.1 nominally shipped 2015-06-12
    • Upcoming
      • 31.8.0 ~2015-06-20 GTB
      • 38.1.0 FF GTB on June 22 release June 30.
        • Would it be possible to continue to use the beta channel for TB 38 until post-38.2.0? So maybe we could do a 38.1.0b1?

    Lightning to Thunderbird Integration

    See https://calendar.etherpad.mozilla.org/thunderbird-integration

    • As underpass has pointed out repeatedly (thanks for your patience!) , we need to rewrite / heavily modify the lightning articles on support.mozilla.org. let me know irc: rolandtanglao on #tb-support-crew or rtanglao AT mozilla.com OR simply start editing the articles
    • We need to fill the “Learn More” page with content, possibly point it to something more specific bug 1159682
    • Opt-out dialog: change “disable” to “remove” bug 1159698
    • tracking bug for lightning 4.0 bug 1153752

    Round Table

    wsmwk

    jorgk

    • bug 345852 – Personal dictionary, waiting for Ehsan
    • bug 209189 – delete, delete, undo -> corruption, waiting for Neil/Kent
    • bug 368915 – spell check in subject, ongoing.
    • bug 1175055 – Import (Eudora/Outlook) busted.

    rkent

    My availability will be limited from June 20 – June 29. If there is going to be progress on fixing TB 38 releases in that time, someone else would have to drive it.

    • Monitoring issues appearing in TB 38.0.1
    • Previously there were issues getting TB 38 to build with current mozilla-esr38 (which resulted in THUNDERBIRD_38_0_20150603_RELBRANCH) and I suspect there may be some fixes needed to get the merge of mozilla-esr38 into THUNDERBIRD_38_VERBRANCH to work.

    jcranmer

    • Huge backlog, being more or less processed in stack order unfortunately
      • Ping me on IRC if you have anything really important to look at something
    • Following up on some releng future issues
    • I have some discussions to start after 38 is finally out the door

    sshagarwal

    • At step one of the project: Setting up a dummy protocol to understand how a protocol

    is added to TB using addon approach (using Skinkglue).

    • I have taken too much time to do this mostly due to health issues continuing for over a month now. Will pick up soon.

    Question Time

    Jorg K:
    When will JSMime take over all RFC2047 decoding? Looking at bug 1146099 I found RFC2047 code used in comm-central/mozilla/netwerk/mime.
    Also, while Joshua is here: Will we fix whatever we did wrong in bug 1154521

    Support team

    • Roland’s last day is June 30, 2015 – please needinfo :rolandtanglao or email rtanglao AT mozilla.com if you need my help starting July 1, 2015

    Other

    • PLEASE PUT THE NEXT MEETING IN YOUR (LIGHTNING) CALENDAR
    • Note – meeting notes must be copied from etherpad to wiki before 5AM CET next day so that they will go public in the meeting notes blog.

    SUMO BlogWhat’s up with… SUMO Buddies?

    Hello, SUMO Nation! Since some of you asked what exactly is going on with SUMO Buddies, here is a post to refresh your memory and take another step towards a nicer, more connected and global SUMO community. Back in January, … Continue reading

    Firebug BlogFirebug 2.0.11

    The Firebug team released Firebug 2.0.11. This is a maintenance release ensuring compatibility with latest Firefox.

     

    The beta channel on AMO is not updated due to a new signing process (support for beta channels is currently in open beta phase). It’s recommended to use standard release channel on AMO (if you don’t know what AMO beta channel is, you are most likely using the right release channel.

     

    Firebug 2.0.11 is compatible with Firefox 30 – 41

    Firebug 2.0.11 fixes the monitor() and unmonitor() commands (issue 7907) as well as source code pretty printing (issue 7906).

     

    Please post feedback in the newsgroup, thanks.

    Jan ‘Honza’ Odvarko

     

    Rumbling Edge - Thunderbird2015-06-15 Calendar builds

    Common (excluding Website bugs)-specific: (6)

    • Fixed: 696334 – Sometimes sort order of calenders list changes
    • Fixed: 964175 – thunderbird-24.2.0: lightning incorrect|/incomplete Russian localization
    • Fixed: 1159699 – Calendar tab toolbar buttons are missing tooltips
    • Fixed: 1162380 – Drop down list in Customize Toolbar is too small
    • Fixed: 1168536 – Events with timezone get moved on a wrong day after a drag and drop in month view
    • Fixed: 1168569 – Incorrect color for the day-off part of the selected day in week view

    Sunbird will no longer be actively developed by the Calendar team.

    Windows builds Official Windows

    Linux builds Official Linux (i686), Official Linux (x86_64)

    Mac builds Official Mac

    Rumbling Edge - Thunderbird2015-06-15 Thunderbird comm-central builds

    Thunderbird-specific: (18)

    • Fixed: 1001535 – Investigate UI issues/changes for the find bar on OS X.
    • Fixed: 1090553 – create filter from doesn’t create filter while in Unified Inbox, and no error message
    • Fixed: 1133264 – DELete (like Shift+DELete) should warn when deleting from Trash (implement confirmation/pref mail.warn_on_delete_from_trash)
    • Fixed: 1150627 – Use SVG graphics for the toolbar buttons in main window
    • Fixed: 1155545 – Advanced Preferences doesn’t fit in the window on Retina displays on OS X 10.9
    • Fixed: 1160822 – Zoom button gets cut off after hiding/unhiding search results visualisation
    • Fixed: 1165946 – Follow the changes of bug 1161156 (about:support uses common.css)
    • Fixed: 1166206 – Display-name with comma in it does not get properly quoted in From: field in Tb38.0b5..
    • Fixed: 1166482 – troubleshooting account, identity information is missing
    • Fixed: 1167929 – Windows 10: The whole titlebar uses the accent color when window is active
    • Fixed: 1168181 – Errors when changing in prefs the “Show only display name for people in my address book”
    • Fixed: 1168945 – Inline spell check behaving strangely on reply, regression from bug 967494
    • Fixed: 1169686 – Package error: Missing file(s): bin/components/dom_devicestorage.xpt, bin/components/pipboot.xpt
    • Fixed: 1169697 – Error: formatURLPref: Couldn’t get pref: extensions.getAddons.link.url
    • Fixed: 1170181 – Take “Bug 1169996 – Changing the spell check language in the message subject of a recycled message via right-click changes the composition language preference” in Thunderbird 38
    • Fixed: 1170918 – Add UI to configure the “fonts for mathematics” preferences
    • Fixed: 1171064 – Configuration error under mailnews/intl (C-C TB): Script for generating charsetalias.properties.h does not exist …
    • Fixed: 1173084 – port bug 1115480 (XPCOM module for mDNSProvider) to thunderbird – TEST-UNEXPECTED-FAIL | dom/presentation/tests/xpcshell/test_multicast_dns_device_provider.js

    MailNews Core-specific: (6)

    • Fixed: 912465 – Opening files for writing can destroy data on full disk
    • Fixed: 1158774 – Port |Bug 1155776 – move USE_EXTENSION_MANIFEST to moz.build| to comm-central
    • Fixed: 1159775 – Port |Bug 870891 – Move DIST_FILES to moz.build| to comm-central
    • Fixed: 1163331 – Update /mailnews/ for PLDHashTable API changes
    • Fixed: 1169399 – Path specified in LOCAL_INCLUDES does not exist: /mozilla/security/manager/ssl/src
    • Fixed: 1171663 – bustage: mailnews/local/src/nsPop3Sink.cpp:63:85: error: ‘PR_LOG’ was not declared in this scope

    Windows builds Official Windows, Official Windows installer

    Linux builds Official Linux (i686), Official Linux (x86_64)

    Mac builds Official Mac

    Meeting NotesMozilla Project: 2015-06-15

    • Every Monday @ 11:00am Pacific Time (19:00 UTC)
    • Dial-in: conference# 8600
      • US/Toll-free: +1 800 707 2533, (pin 369) Conf# 8600
      • US/California/Mountain View: +1 650 903 0800, x92 Conf# 8600
      • US/California/San Francisco: +1 415 762 5700, x92 Conf# 8600
      • US/Oregon/Portland: +1 971 544 8000, x92 Conf# 8600
      • CA/British Columbia/Vancouver: +1 778 785 1540, x92 Conf# 8600
      • CA/Ontario/Toronto: +1 416 848 3114, x92 Conf# 8600
      • UK/London: +44 (0)207 855 3000, x92 Conf# 8600
      • FR/Paris: +33 1 44 79 34 80, x92 Conf# 8600

    All-hands Status Meeting Agenda

    Items in this section will be shared during the live all-hand status meeting.

    Friends of Mozilla

    • Big thanks to all the Mozilla Hacks blog authors of May & June (staff and volunteers in no particular order): Benjamin Peterson, Francesco Iovine, Szmozsánszky István (Flaki), Jason Orendorff, Sean Lin, Jan Odvarko, Potch, Piotr Zalewa, Chris Mills, Brian Grinstead, Nick Desaulniers, Wilson Page, George Politis, Maire Reavy, Dave Camp, Jason Weathersby, Jeff Griffiths, Harald Kirschner. THANK YOU!

    Upcoming Events

    Monday, 15 June
    Wednesday, 17 June
    • Homebrew Website Club Meetup (every other Wednesday)

      Be independent with your web browser and your web site.

      • San Francisco (@MozSF 1st fl Java room) and Portland
      • 17:30-18:30 Writing Hour
      • 18:30-19:30 IndieWeb meetup & hack night

        Create or update your personal web site — wherever you host it, shared, VPS, or at home; static, dynamic, WordPress, or other software.

        Join a community with like-minded interests. Bring friends that want a personal site!

        Any questions? See the wiki page for details
        or join IRC: http://indiewebcamp.com/irc/today?beta#bottom

    Friday, 19 June
    Saturday, 20 June
    • Community Pune Meetup
      • The Community Pune meetup is an annual meetup for all Pune (and other nearby regions) Mozillians to be able to come together, recognize and appreciate the work each one of us is putting in for this community and for Mozilla as a whole and also plan out our activities for 2015 in a way that our efforts can be in sync with Mozilla’s mission for 2015.
      • More info on the Reps Event page
    Next Week
    • OpenSource Bridge, in Portland, OR. From 23rd to 26th
      • Open Source Bridge is a conference for developers working with open source technologies and for people interested in learning the open source way.
    • Hong Kong OpenSource Conference, 26th, and 27th.
      • MozTW and Mozilla Hong Kong members are going to developing Mozilla present in HKOSC, with related sessions/workshops and a Mozilla demonstration booth.

    Project Status Updates (voice updates)

    CTO Update

    Lars Bergstrom: Remote

    We are holding two 3-hour training sessions during the Whistler workweek. One is on Servo, the new web rendering engine, and one is on the new programming language, Rust. Neither requires previous experience, and both will have a substantial, mentored, hands-on hacking portion.

    Servo – Wednesday, 1–4 PM: http://sched.co/3ZQn

    Rust – Thursday, 1–4 PM: http://sched.co/3ZQp

    Please sign up using the Sched links so we make sure we have sufficient space and mentors!

    Webmaker

    Andrew Sliwinski (Portland)

    http://mzl.la/changelog

    • Webmaker for Android
    • Launch activities now underway
      • Bangladesh
      • Kenya
      • Indonesia
      • Brazil

    Speakers

    The limit is 3 minutes per topic. It’s like a lightning talk, but don’t feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week.

    Presenter Title Topic Location Share? Media More Details
    Who Are You? What Do You Do? What are you going to talk about? Where are you presenting from? (Moz Space, your house, space) Will you be sharing your screen? (yes/no, other info) Links to slides or images you want displayed on screen Link to where audience can find out more information
    Liz Compton Legal Affairs Manager A couple of announcements from Legal Mountain View No
    Josh Carpenter VR Demos! Vancouver No

    Welcome!

    Let’s say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.

    Introducing New Volunteers

    New Volunteer Introduced by Speaker location New Volunteer location Will be working on
    Who is the new volunteer? Who will be introducing that person? Where is the introducer? Where will the new person be contributing from? What will the new person be working on?

    Introducing New Hires

    New Hire Introduced by Speaker location New Hire location Will be working on
    Shraddha Patil Sheeri Cabral Mountain View US Remote (CA) Data Integration Engineer
    Pallavi Yaramada Faramarz Rashed Mountain View Mountain View Engineering Manager
    Alexander Fridman Sylvie Veilleux Mountain View San Francisco Sr. Director, IT Service Operations
    Andreas Wagner Amy Tsay Mountain View Germany Remote Add-ons Technical Editor
    Kristine Solon Lenae Lukens Mountain View Mountain View Accountant
    Connor Imes Lars Bergstrom US Remote (Chicago) US Remote (Chicago) Research
    Jamie Nicol Milan Sreckovic Toronto London Platform Graphics

    Introducing New Interns

    New Intern Introduced by Speaker location New Hire location Will be working on
    Andrei Oprea Dan Mosedale Mountain View San Francisco FFX OS
    Steven Englehardt Tanvi Vyas Mountain View San Francisco Security Engineering
    Jonathan Almeida Michael Comella Mountain View San Francisco Mobile
    Huon Wilson Alex Chrichton Mountain View San Francisco Research
    Koki Yoshida Peter deHaan Mountain View Mountain View Cloud Services

    <meta>

    Notes and non-voice status updates that aren’t part of the live meeting go here.

    Status Updates By Team (*non-voice* updates)

    Content Services

    Content Services will hold a Brownbag for Suggested Tiles at Whistler on Friday June 26, 10:30 – 11:30am. Please visit Sched for location details. All are invited!

    IT

    The IT team is standing up a new capability for Mozilla: Cloud Service Broker. Is your data stuck in a SaaS silo? Do you wish your SaaS app had single sign-on? Is your SaaS vendor working hard enough for you? Learn more about how IT can help SaaS owners at Mozilla during Whistler. Join us Tues 4pm, Summit Room at Aava or see Sched for more (http://sched.co/3fV1).

    Engagement
    Social Support

    Bringing Kids to Whistler? there are a few of us and it might be fun to coordinate… sign up here and we’ll try to get the kids together with their grownups for some fun. Please DONT share this list outside Mozillians for security reasons. Anyone who doesn’t have mozilla.com email can contact lshapiro@mozilla.com for access (please tell me who you are in the request, Mozillian, spouse or grandparent or childcare person or whatever)

    Air MozillaDnet Global Launch: Scaling Tech Innovations for the Social Bottom Line

    Dnet Global Launch: Scaling Tech Innovations for the Social Bottom Line Dnet's founder and CEO will give a short talk celebrating the launch of their new US operation, and we'll have a live chat with an...

    Mozilla Add-ons BlogNew AMO t-shirt design chosen!

    Congratulations to Erick León Bolinaga, whose design was chosen by the community to be printed on the new AMO developer t-shirt. Erick has been a Mozilla contributor for 8 years and is the co-founder and leader of the Mozilla Cuba community. He says:

    “It was a pleasure to participate in this contest. I would like to thank Mozilla for making this participatory. I would also like to thank all the community members who voted for my design. The biggest reward will be seeing the design printed on t-shirts for add-on developers. They have contributed in making Firefox the best browser ever.”

    Big thanks to everyone who submitted a design, and congratulations to the two runners up, Avishek Gangopadhyay and Drack Wave.

    And here is Erick’s design!

    Design1

    To qualify for a shirt, you must be one of the following:

    1. A developer with an add-on listed on AMO
    2. A developer with an add-on that is not listed on AMO, but is signed
    3. A background theme designer with 10,000 or more users

    If you pass one of these qualifications, please sign up here to reserve your shirt! The deadline to sign up is Weds, July 8, 2015.

    The shirt will be printed after the deadline, and we’ll start mailing them out in August.

    Thank you to everyone who participated!

    WebmakerWebmaker for Android: Now Available in the Google Play Store

    Today, Mozilla’s efforts to empower Web users around the globe are taking an exciting step forward: we’re debuting Webmaker for Android in the Google Play Store.

    You can download the beta version for free at mzl.la/webmaker.

    Screen Shot 2015-06-15 at 4.53.39 PM

    Webmaker is a tool to help smartphone users of any skill level read, write and participate on the Web. The app makes creating original content in your local language simple — you can drag, drop and personalize photos, text and more to build unique projects like interactive scrapbooks, comic strips, games and memes. While Webmaker is designed first and foremost to be fun and easy-to-use, we’ve already seen the community leverage it in very practical ways as well. Teachers can build lesson plans for their students, students can create class projects, and communities can launch a platform for sharing local happenings.

    Creating on Webmaker is just the beginning. You can also share your projects with friends and neighbors, who are able to remix and add their own additions. You can discover cool projects around you through Webmaker’s discovery gallery, and experience local content made by your community and in your language. And Webmaker is free and open, always.

    We built Webmaker with the hopes of creating a fun, hands-on tool for helping individuals move beyond a read-only version of the Web. And our community played a vital role in this process: volunteers in Bangladesh, Kenya, Brazil, India and elsewhere pitched in to help. When you have a minute, try out Webmaker Beta and share your experiences — we’d love to hear what you think. Reach us at help@webmaker.org or @Webmaker.

    Stay tuned for more exciting news and updates: we’ll be unveiling Webmaker for Android 1.0 later this month and a desktop browser version and code editor are on the way!

    Air MozillaBrownbag: Inequality in global app marketplaces and what Mozilla can do about it

    Brownbag: Inequality in global app marketplaces and what Mozilla can do about it A presentation by Caribou Digital on the app economy and the role of digital marketplaces.

    Mozilla IndiaAnnouncing Policy and Advocacy Task Force

    Many Mozillians in India have been active in Internet related policy and advocacy issues in their individual capacities in the past few years. We have fended off threats to the open Web by forming ad-hoc groups and joining hands with like minded groups and individuals. The debate surrounding net neutrality was a learning experience for our community. There are two major insights to be taken from this:

    • We need to actively participate in and lead policy related discussions in India.
    • We should educate the Mozilla community in India and the public in general about topics related to the Internet and the open Web and build a team who can advocate the same.

    Based on these ideas, the Mozilla India Policy and Advocacy Task Force was formed in the task force meetup recently held at Bangalore from May 8 to 10, 2015.

    Key Focus of this task force:

    • Addressing and engaging with Government and institutional policies related to the Internet, open source software, open standards, privacy, security, etc. in alignment with the Mozilla Manifesto.
    • Spreading awareness on Internet related policy issues to mozillians and the public.
    • Building and running an education program surrounding Internet related policy & advocacy issues and increasing awareness.

    You can find More details of the task force at https://wiki.mozilla.org/India/task_force/Policy_and_Advocacy

    We request all community members to dedicate a slot in all Mozilla events happening in the country towards policy and advocacy. Let us pro-actively build a strong community who understands and value the open Web

    Join

    If you are interested in joining the Policy and advocacy task force, please follow the instructions on the wiki

    Community Calls

    Join us on our monthly community calls on every second saturday 10 PM (starting 13th June, Saturday)

    Follow

    Follow us on twitter https://twitter.com/mozinadvocacy
    Discourse https://discourse.mozilla-advocacy.org/c/advocacy-task-forces/india

    CalendarThere is no Lightning 4.0

    …but of course there is is a release for Thunderbird 38! Since the release date for Thunderbird has been postponed and in the meanwhile Firefox has released 38.0.1, Thunderbird will also be released as Thunderbird 38.0.1. Since the Lightning version is automatically generated at build time, we have just released Lightning 4.0.0.1. If you are still using Thunderbird 31 and Lightning 3.3.3, you will be getting an update in the next days.

    The exciting thing about this release is that Lightning has been integrated into Thunderbird. I expect there will be next to no issues during upgrade this time, because Thunderbird includes the Lightning addon already.

    If you can’t wait, you can get Thunderbird in your language directly from mozilla.org. If you do happen to have issues with upgrading, you can also get Lightning from addons.mozilla.org. The latest Seamonkey version is 2.33.1 at the time of writing, you need to use Lightning 3.8b2 in this case. For more information on compatibility, check out the calendar versions page.

    As mentioned in a previous blog post, most fixed issues are backend fixes that won’t be very visible. We do however have a great new feature to save copies of invitations to your calendar. This helps in case you don’t care about replying to the invitation but would still like to see it in your calendar. We also have more general improvements in invitation compatibility, performance and stability and some slight visual enhancements. The full list of changes can be found on bugzilla.

    If you are upgrading manually, you might want to make a backup. Although I don’t anticipate any major issues, you never know.

    If you have questions, would like support, or have found a bug, feel free to leave a comment here and I’ll get back to you as soon as possible.

    The Mozilla Thunderbird BlogThunderbird 38 Released

    Thunderbird 38 is now released (actual initial version is 38.0.1 to maintain compatibility with equivalent Firefox releases). This release has some significant new features, as well as many, many bug fixes. Some of the new features include:

    • Calendaring is now shipped by default. This continues to be implemented as the Lightning extension, but that is now enabled and installed by default.
    • Chat now supports Yahoo Messenger.
    • Messages can be filtered when sent and when archived.
    • You can now search multiple address books.
    • Gmail users can now authenticate using Google’s preferred OAuth2 authentication (which means that new GMail users should work with Thunderbird without special configuration).

    This is a significant milestone for the Thunderbird team, as it is the first release that has been fully managed by our volunteer team rather than by Mozilla staff.

    Mozilla is still heavily involved with this release, as we still use Mozilla infrastructure for the build and release process. Thanks to the many Mozilla staff who helped out to fix issues!

    Thanks to all of the volunteers who have contributed to make this release possible!

    (Note that while general comments on Thunderbird 38 are welcome, please do not use the comment section of this blog as a place to make bug reports, or to request support for specific issues).

    SUMO BlogWhat’s Up With SUMO 12th June

    Hello there, SUMO fans and creators – how are you doing? Time to update you with the latest from our team. We’re happy to see more of you joining! Abdulla lpraba Ahmadzai Luis fannceface If you joined us recently, don’t … Continue reading

    hacks.mozilla.orgES6 In Depth: Symbols

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    What are ES6 symbols?

    Symbols are not logos.

    They’re not little pictures you can use in your code.

    let 😻 = 😺 × 😍;  // SyntaxError
    

    They’re not a literary device that stands for something else.

    They’re definitely not the same thing as cymbals.

    (It is not a good idea to use cymbals in programming. They have a tendency to crash.)

    So, what are symbols?

    The seventh type

    Since JavaScript was first standardized in 1997, there have been six types. Until ES6, every value in a JS program fell into one of these categories.

    • Undefined
    • Null
    • Boolean
    • Number
    • String
    • Object

    Each type is a set of values. The first five sets are all finite. There are, of course, only two Boolean values, true and false, and they aren’t making new ones. There are rather more Number and String values. The standard says there are 18,437,736,874,454,810,627 different Numbers (including NaN, the Number whose name is short for “Not a Number”). That’s nothing compared to the number of different possible Strings, which I think is (2144,115,188,075,855,872 − 1) ÷ 65,535 …though I may have miscounted.

    The set of Object values, however, is open-ended. Each object is a unique, precious snowflake. Every time you open a Web page, a rush of new objects is created.

    ES6 symbols are values, but they’re not strings. They’re not objects. They’re something new: a seventh type of value.

    Let’s talk about a scenario where they might come in handy.

    One simple little boolean

    Sometimes it would be awfully convenient to stash some extra data on a JavaScript object that really belongs to someone else.

    For example, suppose you’re writing a JS library that uses CSS transitions to make DOM elements zip around on the screen. You’ve noticed that trying to apply multiple CSS transitions to a single div at the same time doesn’t work. It causes ugly, discontinuous “jumps”. You think you can fix this, but first you need a way to find out if a given element is already moving.

    How can you solve this?

    One way is to use CSS APIs to ask the browser if the element is moving. But that sounds like overkill. Your library should already know the element is moving; it’s the code that set it moving in the first place!

    What you really want is a way to keep track of which elements are moving. You could keep an array of all moving elements. Each time your library is called upon to animate an element, you can search the array to see if that element is already there.

    Hmm. A linear search will be slow if the array is big.

    What you really want to do is just set a flag on the element:

    if (element.isMoving) {
      smoothAnimations(element);
    }
    element.isMoving = true;
    

    There are some potential problems with this too. They all relate to the fact that your code isn’t the only code using the DOM.

    1. Other code using for-in or Object.keys() may stumble over the property you created.

    2. Some other clever library author may have thought of this technique first, and your library would interact badly with that existing library.

    3. Some other clever library author may think of it in the future, and your library would interact badly with that future library.

    4. The standard committee may decide to add an .isMoving() method to all elements. Then you’re really hosed!

    Of course you can address the last three problems by choosing a string so tedious or so silly that nobody else would ever name anything that:

    if (element.__$jorendorff_animation_library$PLEASE_DO_NOT_USE_THIS_PROPERTY$isMoving__) {
      smoothAnimations(element);
    }
    element.__$jorendorff_animation_library$PLEASE_DO_NOT_USE_THIS_PROPERTY$isMoving__ = true;
    

    This seems not quite worth the eye strain.

    You could generate a practically unique name for the property using cryptography:

    // get 1024 Unicode characters of gibberish
    var isMoving = SecureRandom.generateName();
    
    ...
    
    if (element[isMoving]) {
      smoothAnimations(element);
    }
    element[isMoving] = true;
    

    The object[name] syntax lets you use literally any string as a property name. So this will work: collisions are virtually impossible, and your code looks OK.

    But this is going to lead to a bad debugging experience. Every time you console.log() an element with that property on it, you’ll be looking a huge string of garbage. And what if you need more than one property like this? How do you keep them straight? They’ll have different names every time you reload.

    Why is this so hard? We just want one little boolean!

    Symbols are the answer

    Symbols are values that programs can create and use as property keys without risking name collisions.

    var mySymbol = Symbol();
    

    Calling Symbol() creates a new symbol, a value that’s not equal to any other value.

    Just like a string or number, you can use a symbol as a property key. Because it’s not equal to any string, this symbol-keyed property is guaranteed not to collide with any other property.

    obj[mySymbol] = "ok!";  // guaranteed not to collide
    console.log(obj[mySymbol]);  // ok!
    

    Here is how you could use a symbol in the situation discussed above:

    // create a unique symbol
    var isMoving = Symbol("isMoving");
    
    ...
    
    if (element[isMoving]) {
      smoothAnimations(element);
    }
    element[isMoving] = true;
    

    A few notes about this code:

    • The string "isMoving" in Symbol("isMoving") is called a description. It’s helpful for debugging. It’s shown when you write the symbol to console.log(), when you convert it to a string using .toString(), and possibly in error messages. That’s all.

    • element[isMoving] is called a symbol-keyed property. It’s simply a property whose name is a symbol rather than a string. Apart from that, it is in every way a normal property.

    • Like array elements, symbol-keyed properties can’t be accessed using dot syntax, as in obj.name. They must be accessed using square brackets.

    • It’s trivial to access a symbol-keyed property if you’ve already got the symbol. The above example shows how to get and set element[isMoving], and we could also ask if (isMoving in element) or even delete element[isMoving] if we needed to.

    • On the other hand, all of that is only possible as long as isMoving is in scope. This makes symbols a mechanism for weak encapsulation: a module that creates a few symbols for itself can use them on whatever objects it wants to, without fear of colliding with properties created by other code.

    Because symbol keys were designed to avoid collisions, JavaScript’s most common object-inspection features simply ignore symbol keys. A for-in loop, for instance, only loops over an object’s string keys. Symbol keys are skipped. Object.keys(obj) and Object.getOwnPropertyNames(obj) do the same. But symbols are not exactly private: it is possible to use the new API Object.getOwnPropertySymbols(obj) to list the symbol keys of an object. Another new API, Reflect.ownKeys(obj), returns both string and symbol keys. (We’ll discuss the Reflect API in full in an upcoming post.)

    Libraries and frameworks will likely find many uses for symbols, and as we’ll see later, the language itself is using of them for a wide range of purposes.

    But what are symbols, exactly?

    > typeof Symbol()
    "symbol"
    

    Symbols aren’t exactly like anything else.

    They’re immutable once created. You can’t set properties on them (and if you try that in strict mode, you’ll get a TypeError). They can be property names. These are all string-like qualities.

    On the other hand, each symbol is unique, distinct from all others (even others that have the same description) and you can easily create new ones. These are object-like qualities.

    ES6 symbols are similar to the more traditional symbols in languages like Lisp and Ruby, but not so closely integrated into the language. In Lisp, all identifiers are symbols. In JS, identifiers and most property keys are still considered strings. Symbols are just an extra option.

    One quick caveat about symbols: unlike almost anything else in the language, they can’t be automatically converted to strings. Trying to concatenate a symbol with strings will result in a TypeError.

    > var sym = Symbol("<3");
    > "your symbol is " + sym
    // TypeError: can't convert symbol to string
    > `your symbol is ${sym}`
    // TypeError: can't convert symbol to string
    

    You can avoid this by explicitly converting the symbol to a string, writing String(sym) or sym.toString().

    Three sets of symbols

    There are three ways to obtain a symbol.

    • Call Symbol(). As we already discussed, this returns a new unique symbol each time it’s called.

    • Call Symbol.for(string). This accesses a set of existing symbols called the symbol registry. Unlike the unique symbols defined by Symbol(), symbols in the symbol registry are shared. If you call Symbol.for("cat") thirty times, it will return the same symbol each time. The registry is useful when multiple web pages, or multiple modules within the same web page, need to share a symbol.

    • Use symbols like Symbol.iterator, defined by the standard. A few symbols are defined by the standard itself. Each one has its own special purpose.

    If you still aren’t sure if symbols will be all that useful, this last category is interesting, because they show how symbols have already proven useful in practice.

    How the ES6 spec is using well-known symbols

    We’ve already seen one way that ES6 uses a symbol to avoid conflicts with existing code. A few weeks ago, in the post on iterators, we saw that the loop for (var item of myArray) starts by calling myArray[Symbol.iterator](). I mentioned that this method could have been called myArray.iterator(), but a symbol is better for backward compatibility.

    Now that we know what symbols are all about, it’s easy to understand why this was done and what it means.

    Here are a few of the other places where ES6 uses well-known symbols. (These features are not implemented in Firefox yet.)

    • Making instanceof extensible. In ES6, the expression object instanceof constructor is specified as a method of the constructor: constructor[Symbol.hasInstance](object). This means it is extensible.

    • Eliminating conflicts between new features and old code. This is seriously obscure, but we found that certain ES6 Array methods broke existing web sites just by being there. Other Web standards had similar problems: simply adding new methods in the browser would break existing sites. However, the breakage was mainly caused by something called dynamic scoping, so ES6 introduces a special symbol, Symbol.unscopables, that Web standards can use to prevent certain methods from getting involved in dynamic scoping.

    • Supporting new kinds of string-matching. In ES5, str.match(myObject) tried to convert myObject to a RegExp. In ES6, it first checks to see if myObject has a method myObject[Symbol.match](str). Now libraries can provide custom string-parsing classes that work in all the places where RegExp objects work.

    Each of these uses is quite narrow. It’s hard to see any of these features by themselves having a major impact in my day-to-day code. The long view is more interesting. Well-known symbols are JavaScript’s improved version of the __doubleUnderscores in PHP and Python. The standard will use them in the future to add new hooks into the language with no risk to your existing code.

    When can I use ES6 symbols?

    Symbols are implemented in Firefox 36 and Chrome 38. I implemented them for Firefox myself, so if your symbols ever act like cymbals, you’ll know who to talk to.

    To support browsers that do not yet have native support for ES6 symbols, you can use a polyfill, such as core.js. Since symbols are not exactly like anything previously in the language, the polyfill isn’t perfect. Read the caveats.

    Next week, we’ll have two new posts. First, we’ll cover some long-awaited features that are finally coming to JavaScript in ES6—and complain about them. We’ll start with two features that date back almost to the dawn of programming. We’ll continue with two features that are very similar, but powered by ephemerons. So please join us next week as we look at ES6 collections in depth.

    And, stick around for a bonus post by Gastón Silva on a topic that isn’t an ES6 feature at all, but might provide the nudge you need to start using ES6 in your own projects. See you then!

    Meeting NotesChannel: 2015-06-11

    Attendees

    lmandel, sylvestre, lizzard, kglazko, tyler, hwine, aklotz, elan, jorge,, ritu, kairo, rolandtanglao, frios

    Schedule Update

    • Desktop 39 beta 4 shipped on Wednesday
      • a day late because of the build infrastructure outages
    • Still waiting for mobile beta 4 signoff, should be soon.
    • I think we should ship mobile beta 5, to turn off async stacks. https://bugzilla.mozilla.org/show_bug.cgi?id=1158133
    • 39 Beta 6 will go to build next Monday.

    Add-ons

    • No updates.

    Stability

    • Kairo is on PTO next week so we will likely have smaller stability updates
    • Marc Schiffer is covering for update testing and dmajor for stability

    Aurora / Dev edition

    Overall rate: 3.1 (target: <1.5)

    • Pretty unchanged to Tuesday.

    Beta

    Overall rate: 1.9; plugin crashes/hangs: 0.11/0.40 (target: <1.4, 0.8/0.12)

    • In early 39.0b4 data, we see our famous AMD crash (bug 772330) again, 3.8% of all crashes, this time as js::LifoAlloc::getOrCreateChunk (and dmajor’s patch doesn’t help in that location).
    • bug 1159751 (new gfx shutdown hang) is 2.6%
    • bug 1170141 (real player, startup) is still visible in stats, despite blocklist (still outstanding: 1172560)
    • bug 1170143 (Intel gfx, a lot on startup) is not gone but down to 0.9%
    • bug 1146313 seems to be fixed by the gfx patches that landed!
    • async plugin init is probably not ready to be shipped, see still high hang rate

    Release

    Overall rate: 1.25

    • No news.

    RelEng

    • problems were double filer failure, causing some db corruption

    Special Topics

    Aurora/Beta Feature Review

    Aurora:

    Beta:

    • status report on NSS 3.19.1
       Logjam. Response, update NSS. this broke some other things (also for chrome and redhat)
       the NSS team is working to fix that. 
       https://bugzilla.mozilla.org/show_bug.cgi?id=1172128
    
    • RC4. It should remain in the state it was in in 38. But is it? Not sure. Working with rbarnes to ensure that.
    • turning off async plugin init. Will be turned off in beta 5 or 6. Status report (aklotz)
    • url sharing in hello is still on track for release.
    • async stacks turned off in beta/release. Coming in beta 5.
    • supporting hotfixes with new addon signing requirements. Still needs verification. bug 1151537
    • soft launch of windows 64 builds. (Done)

    Channel Meeting Details

    Video/Teleconference Details – NEW

    • 650-903-0800 or 650-215-1282 x92 Conf# 99951 (US/INTL)
    • 1-800-707-2533 (pin 369) Conf# 99951 (US)
    • Vidyo Room: ReleaseCoordination
    • Vidyo Guest URL

    Air MozillaBrown Bag Talk: Passwords and Login Problems

    Brown Bag Talk: Passwords and Login Problems How can Mozilla improve the user experience around logins and passwords? Over the past six weeks, the Passwords team, joined by Amelia Abreu, has spent...