mconley livehacks on real Firefox bugs while thinking aloud.

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

This is the sumo weekly call

https://air.mozilla.org/weekly-sumo-community-meeting-august-17-2016/

Hello Mozillians!

As you may already know, last Friday – August 12th – we held a new Testday event, for Firefox 49 Beta 3.

Thank you all for helping us making Mozilla a better place – Logicoma, Julie Myers, Moin Shaikh, Ilse Mac'ias, Iryna Thompson.

From Bangladesh: Rezaul Huque Nayeem, Raihan Ali, Md. Rahimul Islam, Rabiul Hossain Bablu, Hossain Al Ikram, Azmina Akter Papeya, Saddam Hossain, Sufi Ahmed Hamim, Fahim, Maruf Rahman, Hossain Ahmed Sadi, Tariqul Islam Chowdhury, Sajal Ahmed, Md.Majedul islam, Amir Hossain Rhidoy, Toki Yasir, Jobayer Ahmed Mickey, Sayed Ibn Masud, kazi Ashraf hossain, Sahab Ibn Mamun, Kazi Nuzhat Tasnem, Sourov Arko, Sauradeep Dutta, Samad Talukder, Kazi Sakib Ahmad, Sajedul Islam, Forhad hossain, Syed Nayeem Roman, Md. Faysal Alam Riyad, Tanvir Rahman, Oly Roy, Akash, Fatin Shahazad.

From India: Paarttipaabhalaji, Surentharan, Bhuvana Meenakshi.K, Nagaraj V, Md Shahbaz Alam, prasanthp96, Selva Makilan, Jayesh Ram, Dhinesh Kumar M, B.AISHWARYA, Ashly Rose, Kamlesh Vilpura, Pavithra.

A big thank you goes out to all our active moderators too!

Results:

• there were 24 verified bugs:
  • 1276116, 1205330, 1060732, 1272208, 1268466, 1290527, 1134073, 1221545 1288964, 1198648, 1292519, 1008225, 1289827, 1272500, 1104054,  1279224, 1292870, 1270148, 1246313, 1226548, 1285328, 1202458,  1249362, 1258212
• there were 9 new issues found:
  • 1294761, 1294765, 1294961, 1294962, 1294970, 1294976, 1294981, 1294974 1294711
• some failures were mentioned in the etherpad; therefore, please add the requested details in the etherpad or, even better, join us on #qa IRC channel and let’s figure them out

https://quality.mozilla.org/2016/08/49658/

In my previous post "Embedding Google Cardboard Camera VR Photosphere with A-Frame", I wrote that some talented programmer would probably create a better solution for embedding Google Cardboard camera photosphere using A-Frame.

I didn't know that Chris Car had already created a sophisticated solution for this problem. You can view it here on A-Frame blog.

You first might have to use Google Cardboard camera converter tool to make your Google Cardboard photosphere.

http://playingwithsid.blogspot.com/2016/08/google-cardboard-360-photosphere-viewer.html

Since joining the Platform Graphics team as a QA engineer several months ago I’ve dabbled in visualizing Graphics crash data using the Socorro supersearch API and the MetricsGraphics.js visualization library.

After I gained a better understanding of the API and MG.js I set up a github repo as sandbox to play around with visualizing different types of crash data. Some of these experiments include a tool to visualize top crash signatures for vendor/device/driver combinations, a tool to compare crash rates between Firefox and Fennec, a tool to track crashes from the graphics startup test, and a tool to track crashes with a WebGL context.

Top graphics crash for Intel HD 4000 w/driver 10.18.10.4276

Fast forward to June,  I had the opportunity to present some of this work at the Mozilla All-hands in London. As a result of this presentation I had a fruitful conversation with Benoit Girard, fellow engineer on the Graphics team. We talked about integrating my visualization tool with Bugzilla by way of a Bugzilla Tweaks add-on; this would both improve the functionality of Bugzilla and improve awareness of my tool. To my surprise this was actually pretty easy and I had a working prototype within 24 hours.

Since then I’ve iterated a few times, fixing some bugs based on reviews for the AMO Editors team. With version 0.3 I am satisfied enough to publicize it as an experimental add-on.

Bugzilla Socorro Lens (working title) appends a small snippet into the Crash Signatures field of bug reports, visualizing 365 days worth of aggregate crash data for the signatures in the bug.  With BSL installed it becomes more immediately evident when a crash started being reported, if/when it was fixed, how the crash is trending, or if the crash is spiking; all without having to manually search Socorro.

Socorro snippet integration on https://bugzil.la/1241921

Of course if you want to see the data in Socorro you can. Simply click a data-point on the visualization and a new tab will be opened to Socorro showing the crash reports for that date. This is particularly useful when you want to see what may be driving a spike.

At the moment BSL is an experimental add-on. I share it with you today to see if it’s useful and collect feedback. If you encounter a bug or have a feature request I invite you to submit an issue on my github repo. Since this project is a learning experience for me, as much as it is a productivity exercise, I am not accepting pull requests at this time. I welcome your feedback and look forward to improving my coding skills by resolving your issues.

You can get the add-on from addons.mozilla.org.

[Update] Nicholas Nethercote informed me of an issue where the chart won’t display if you have the “Experimental Interface” enabled in Bugzilla. I have filed an issue in my github repo and will take a look at this soon. In the meantime, you’ll have to use the default Bugzilla interface to make use of this add-on. Sorry for the inconvenience.

https://ashughes.com/?p=360

Group 4 of the interns will be presenting on what they worked on this summer. Andrew Comminos- TOR Benton Case- PDX Josephine Kao- SF Steven...

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

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community

News & Blog Posts

• Security Advisory for crates.io, 2016-08-15. Please read, especially if you've renamed your GitHub account.
• Shape of errors to come. A sneak peek at new & improved error formats in Rust.
• What’s new with “The Rust Programming Language”? Second edition of TRPL book is coming up with Carol (Nichols || Goulding) as a co-author.
• Zero-cost futures in Rust. futures-rs is now ready for prime time!
• Futures in Rust. Writing an Async Web API Wrapper - An excercise in learning Rust.
• Rust compiler walk-through: Introduction.
• Asynchronous servers in Rust. Using tokio-rs to build an asynchronous server.
• Parsing strategies in Rust. Comparing two competing parsing frameworks in Rust: nom, a parser combinator, and LALRPOP, an LR(1) parser generator.
• Xero and Sandstorm.io have been added to the Friends of Rust page. Xero is using Rust for infrastructure, and Sandstorm.io has a collections application in Rust.

New Crates & Project Updates

• error-chain 0.5.0 released, changing how backtraces are handled.
• rust-skeptic 0.6.1 released, with fixes and optimizations.
• The official nano-config repo is undeprecated. It now contains a configuration that is compatible with older versions of the editor.
• Way Cooler. Customizable Wayland compositor (window manager) written in Rust.
• ring. Safe, fast, small crypto using Rust.
• ralloc. A fast & memory efficient pure-Rust memory allocator.
• Threshold Secret Sharing. A pure-Rust implementation of various threshold secret sharing schemes.
• WS-RS. Lightweight, event-driven WebSockets for Rust.
• alexa-rs. Rust library for building Alexa skills.
• Tantivy. A text search engine library written in Rust.
• filters - a crate for building predicates/filters with the builder pattern.
• derive_builder. Derive builder implementation for Rust structs.
• This week in Servo 74.
• This week in Rust docs 17.
• TiKV weekly 2016-08-12.
• Talking Tock week 1. Tock is a safe, multitasking operating system for low-power, low-memory microcontrollers.
• Talking Tock week 2.
• What's coming up in imag 13.

Crate of the Week

This week's Crate of the Week is Raph Levien's font-rs, yet another pure Rust font renderer, which is incomplete, but very fast. Thanks StefanoD for the suggestion.

Submit your suggestions for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• [moderate] rust-www: Add a section to the front page with 3 rotating 'friends'. This is an important change to how we present Rust that everybody will see.
• [easy] rust: Error code list which need to be updated to new format.
• [easy] servo: Do not define Pipeline::setup_common when on Windows.
• [easy] rustup: Don't capture backtraces without RUST_BACKTRACE=1. An easy fix, done in two steps, first modifying error-chain, then upgrading it in rustup.
• [easy] rustup: Add command to install shell completions.
• [moderate] rust: improve error message when resolution via Deref actually required DerefMut. Good first type system bug.
• [hard] imag: implement bindings to lua/lisp (ketos)/rhai for the filter library

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

Updates from Rust Core

135 pull requests were merged in the last two weeks.

• impl trait in return type position Yay! @eddyb, you're a hero!
• It is now an error to use private items in public code (formerly a warning)
• Also, private_in_public checker now substitutes type aliases
• --test-threads=N argument for tests
• Slow test warning
• Extend MIR to emit LLVM lifetime statements
• MIR: new statement kind for enum deaggregation
• Incremental Compilation: Fixed some ICEs
• Strict Version Hashes for Crates improved
• Improved {H,C}ashing for dep-graphs
• Some artificial restrictions regarding zero-sized structs/enum variants lifted (RFC 1506)
• std::vec::intoIter::as_<mut_>slice()
• Optimize std::panic::catch_unwind(_) slightly (don't use it anyway unless you have to)
• impl From for {

https://this-week-in-rust.org/blog/2016/08/16/this-week-in-rust-143/

one of the most useful skills i’m learning this summer is the ability to take seemingly seamless big problems and chisel them into smaller chunks.

the most recent example of this was adding support for min-vid from google’s main page. as i’m writing about in more depth shortly, min-vid uses the urlcontext and selectorcontext to parse a link to an mp4 to send to the min-vid player. but google LIES about its hrefs! for shame! this means that if you “inspect element” on a google search result, you’ll see a bunch of crap that is not a direct link to the resource you want. so i had to spend some time looking through all the gunk to find the link i wanted.

when i looked at the actual href in its entirety, i noticed something interesting:

"/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwiG0vnbxLTOAhWRMx4KHdzBBPgQuAIILzAC&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJTEFKFiXSx4&usg=AFQjCNF438a2Zz3VtIMKRz-eeipzzPal0A&sig2=YgRw9Ej3ER3CIPU5Wyg64w&bvm=bv.129389765,d.dmo"

do you see it? the youtube link is in there, surrounded by a bunch of %2F‘s and %3D‘s. initially, i thought this was some kind of weird google cipher and that i needed to write a bunch of vars to convert these strange strings to the punctuation marks my link-parsing function expected. i wrote a regular expression to get rid of everything before https, then started the converting. it looked something like this:

cm.Item({
 label: contextMenuLabel,
 context: cm.URLContext(['*.google.com']),
 contentScript: contextMenuContentScript,
 onMessage: function(url) {
   const regex = /url=(https[^;]*)/;
   const match = regex.exec(url)[1];
  
   const getColons = match.replace(/%3A/g, ':');
   const getSlashes = match.replace(/%2F/g, '/');
   const getQuestion = match.replace(/%3F/g, '?');
   const getEqual = match.replace(/%3D/g, '=');

   launchVideo({url: url,
               domain: 'tbdstring',
               getUrlFn: getTbdUrl});
 }
});

at this point, i made myself a little to-do list. to-do lists make my life easier because i have a short attention span and am highly prone to rabbit holes, but am also really impatient and like to feel like i’m actually accomplishing things. the ability to cross tiny things off my list keeps me engaged and makes it much more likely that i’ll actually finish a thing i start. so. the list:

thankfully, after cursing my fate at having to deconstruct and reconstruct such a ridiculous string, i found out about a thing called URI encoding. those weird symbols are not google-specific, and there are special functions to deal with them. decodeURIComponent took care of my first two to-do items. indexOf took care of my third. adding forward slashes to all my other selectorcontexts, to distinguish between the encoded hrefs on google and the un-encoded hrefs on other sites, took care of my last to-do.

ta-da:

cm.Item({
  label: contextMenuLabel,
  context: [
    cm.URLContext(['*.google.com']),
    //TODO?: create a variable with all supported hrefs and reference it in this SelectorContext
    cm.SelectorContext('[href*="youtube.com%2F"], [href*="youtu.be%2F"], [href*="vine.co%2F"], [href*="vimeo.com%2F"]')
  ],
  contentScript: contextMenuContentScript,
  onMessage: function(url) {
    const regex = /url=(https[^;]*)/;
    const match = regex.exec(url)[1];
    const decoded = decodeURIComponent(match).split('&usg')[0];
    let getUrlFn;
    if (decoded.indexOf('youtube.com' || 'youtu.be') > -1) {
      getUrlFn = getYouTubeUrl;
      var domain = 'youtube.com';
    } else if (decoded.indexOf('vimeo.com')  > -1) {
      getUrlFn = getVimeoUrl;
      var domain = 'vimeo.com';
    } else if (decoded.indexOf('vine.co') > -1) {
      getUrlFn = getVineUrl;
      var domain = 'vine.co';
    }
    if (domain && getUrlFn) {
      launchVideo({url: decoded,
        domain: domain,
        getUrlFn: getUrlFn});
    } else console.error('Decoding failed');
  }
});

i am 1000% positive i would not have completed this task without a to-do list. thanks to mentor jared for teaching me how!

http://www.jkitppit.com/2016/08/16/to-do-lists-for-big-problems-small-pieces/

I’ve been acting as the owner for the add-ons manager for the past little while and while I have always cared a lot about the add-ons space it is time to formerly pass over the torch. So I was pleased that Rob Helmer was willing to take it over from me.

Rob has been doing some exceptional work on making system add-ons (used as part of the go faster project) more robust and easier for Mozilla to use. He’s also been thinking lot about improvements we can make to the add-ons manager code to make it more friendly to approach.

As my last act I’m updating the suggested reviewers in bugzilla to be him, Andrew Swan (who in his own right has been doing exceptional work on the add-ons manager) and me as a last resort. Please congratulate them and direct any questions you may have about the add-ons manager towards Rob.

https://www.oxymoronical.com/blog/2016/08/A-new-owner-for-the-add-ons-manager

Information flow between leaders and individual contributors is critical to an effective organization. The ability to better understand the needs of the organization, to gather input across different domains, getting other perspectives before we make a decision and change management, help create a clueful and informed organisation.

This quarter we are piloting a number of untypical discussion sessions between leaders and individuals across Mozilla, whereby leaders will engage with participants who are not usually in their domain. There are hypotheses we’d like to test.  One is that cross-team, multiple-level discussion and information flow will: prevent us from being blind-sided, increase our shared understanding, and empower people to participate and lead in productive ways.  A second hypothesis is that there is an appetite for this type of discussion and some templates and structure would make it easier for people to know how to approach it.

We have 9 leaders who have agreed to host a discussion session this quarter, and we’re currently in the process of inviting participants from across the organization. Currently, there are 4 types of discussions we’ve identified that could take place, there are likely more:

• Pulse (“Taking the Pulse”) – allow a leader to quickly test an idea and/or get insights from the wider community about the current state of Mozilla, or their domain area.
• Ideation – to generate insights from a targeted and diverse group of participants.
• Decision – to ask for feedback regarding a decision from a broad group of people beyond the typical domain to ensure they are not blind-sided, and to provide key diverse input.
• Change Management – creates a shared understanding for a decision already made.

If these sessions prove useful, we may create a useful toolkit for leadership on how to run disperse discussion sessions, and gather input from across Mozilla. And in addition, create a toolkit for individual contributors for understanding and contributing to important topics across Mozilla.

We’ll plan to share more updates next month.

http://blog.lizardwrangler.com/2016/08/15/increasing-information-flow-at-mozilla/

When add-ons were first introduced as a way to personalize Firefox, they required a restart of Firefox upon installation. Then came “restartless” extensions, which made the experience of installing an add-on much smoother. Every iteration of extensions APIs since then has similarly supported restartless add-ons, up to WebExtensions.

To indicate that an add-on was restartless, we added “No Restart” badges next to them on addons.mozilla.org (AMO). This helped people see which add-ons would be smoother to install, and encouraged developers to implement them for their own add-ons. However, two things happened recently that prompted us to reverse this badge. Now, rather than using a “No Restart” badge to indicate that an add-on is restartless, we will use a “Restart Required” badge to indicate that an add-on requires a restart.

One reason for this change is because we reached a tipping point: now that restartless add-ons are more common, and the number of WebExtensions add-ons is increasing, there are now more extensions that do not require a restart than those that do.

Another reason is that we encountered an unexpected issue with the recent introduction of multiprocess Firefox. In Firefox 48, multiprocess capability was only enabled for people with no add-ons installed. If you are one of these people and you now install an add-on, you’ll be asked to restart Firefox even if the add-on is restartless. This forced restart will only occur over the next few versions as multiprocess Firefox is gradually rolled out. This is not because of the add-on, but because Firefox needs to turn multiprocess off in order to satisfy the temporary rule that only people without add-ons installed have multiprocess Firefox enabled. So a “No Restart” badge may be confusing to people.

Restartless add-ons becoming the norm is a great milestone and a huge improvement in the add-on experience, and one we couldn’t have reached without all our add-on developers—thank you!

https://blog.mozilla.org/addons/2016/08/15/restart-required/

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20160815/

When building interfaces, it is important to also consider those who can only use a keyboard to use your products. This is a basic accessibility need, and in most cases it isn’t hard to allow for a basic keyboard access. It means first and foremost using keyboard accessible elements for interaction:

• anchors with a valid href attribute if you want the user to go somewhere
• buttons when you want to execute your own code and stay in the document

You can make almost everything keyboard accessible using the roving tab index technique, but why bother when there are HTML elements that can do the same?

Making it visual

Using the right elements isn’t quite enough though; you also need to make it obvious where a keyboard user is in a collection of elements. Browsers do this by putting an outline around active elements. Whilst dead useful this has always been a thorn in the side of people who want to control the whole visual display of any interaction. You can remove this visual aid by setting the CSS outline property to none, which is a big accessibility issue unless you also provide an alternative.

By using the most obvious HTML elements for the job and some CSS to ensure that not only hover but also focus states are defined we can make it easy for our users to navigate a list of items by tabbing through them. Shift-Tab allows you to go backwards. You can try it here and the HTML is pretty straight forward.

>
  >>1>>
  >>2>>
  >>3>>
  …
  >>20>>
>

Using a list gives our elements a hierarchy and a way to navigate with accessible technology that a normal browser doesn’t have. It also gives us a lot of HTML elements to apply styling to. With a few styles, we can turn this into a grid, using less vertical space and allowing for more content in a small space.

ul, li {
  margin: 0;
  padding: 0;
  list-style: none;
}
button {
  border: none;
  display: block;
  background: goldenrod;
  color: white;
  width: 90%;
  height: 30px;  
  margin: 5%;
  transform: scale(0.8);
  transition: 300ms;
}
button:hover, button:focus {
  transform: scale(1);
  outline: none;
  background: powderblue;
  color: #333;
}
 
li {
  float: left;
}
 
/* 
  grid magic by @heydonworks 
  https://codepen.io/heydon/pen/bcdrl
*/
 
li {
  width: calc(100% / 4);
}
li:nth-child(4n+1):nth-last-child(1) {
  width: 100%;
}
li:nth-child(4n+1):nth-last-child(1) ~ li {
  width: 100%;
}
li:nth-child(4n+1):nth-last-child(2) {
  width: 50%;
}
li:nth-child(4n+1):nth-last-child(2) ~ li {
  width: 50%;
}
li:nth-child(4n+1):nth-last-child(3) {
  width: calc(100% / 4);
}
li:nth-child(4n+1):nth-last-child(3) ~ li {
  width: calc(100% / 4);
}

The result looks pretty fancy and it is very obvious where we are in our journey through the list.

Enhancing the keyboard access – providing shortcuts

However, if I am in a grid, wouldn’t it be better if I could move in two directions with my keyboard?

Using a bit of JavaScript for progressive enhancement, we get this effect and can navigate the grid either with the cursor keys or by using WASD:

It is important to remember here that this is an enhancement. Our list is still fully accessible by tabbing and should JavaScript fail for any of the dozens of reasons it can, we lost a bit of convenience instead of having no interface at all.

I’ve packaged this up in a small open source, vanilla, dependency free JavaScript called gridnav and you can get it on GitHub. All you need to do is to call the script and give it a selector to reach your list of elements.

span> id="links" data-amount="5" data-element="a">
  >span> href="#">1>>
  >span> href="#">2>>
…
  >span> href="#">25>>
>
 
span> src="gridnav.js">>
>
  var linklist = new Gridnav('#links');
>

You define the amount of elements in each row and the keyboard accessible element as data attributes on the list element. These are optional, but make the script faster and less error prone. There’s an extensive README explaining how to use the script.

How does it work?

When I started to ponder how to do this, I started like any developer does: trying to tackle the most complex way. I thought I needed to navigate the DOM a lot using parent nodes and siblings with lots of comparing of positioning and using getBoundingClientRect.

Then I took a step back and realised that it doesn’t matter how we display the list. In the end, it is just a list and we need to navigate this one. And we don’t even need to navigate the DOM, as all we do is go from one element in a collection of buttons or anchors to another. All we need to do is to:

1. Find the element we are on (event.target gives us that).
2. Get the key that was pressed
3. Depending on the key move to the next, previous, or skip a few elements to get to the next row

Like this (you can try it out here):

The amount of elements we need to skip is defined by the amount of elements in a row. Going up is going n elements backwards and going down is n elements forwards in the collection.

The full code is pretty short if you use some tricks:

(function(){
  var list = document.querySelector('ul');
  var items = list.querySelectorAll('button');
  var amount = Math.floor(
        list.offsetWidth / 
        list.firstElementChild.offsetWidth
      );
  var codes = {
    38: -amount,
    40: amount, 
    39: 1,
    37: -1
  };
  for (var i = 0; i < items.length; i++) {
    items[i].index = i;
  }
  function handlekeys(ev) {
    var keycode = ev.keyCode;
    if (codes[keycode]) {
      var t = ev.target;
      if (t.index !== undefined) {
        if (items[t.index + codes[keycode]]) {
          items[t.index + codes[keycode]].focus();
        }
      }
    }
  }
  list.addEventListener('keyup', handlekeys);
})();

What’s going on here?

We get a handle to the list and cache all the keyboard accessible elements to navigate through

  var list = document.querySelector('ul');
  var items = list.querySelectorAll('button');

We calculate the amount of elements to skip when going up and down by dividing the width of the list element by the width of the first child element that is an HTML element (in this case this will be the LI)

  var amount = Math.floor(
        list.offsetWidth / 
        list.firstElementChild.offsetWidth
      );

Instead of creating a switch statement or lots of if statements for keyboard handling, I prefer to define a lookup table. In this case, it is called codes. They key code for up is 38, 40 is down, 39 is right and 37 is left. If we now get codes[37] for example, we get -1, which is the amount of elements to move in the list

  var codes = {
    38: -amount,
    40: amount, 
    39: 1,
    37: -1
  };

We can use event.target to get which button was pressed in the list, but we don’t know where in the list it is. To avoid having to loop through the list on each keystroke, it makes more sense to loop through all the buttons once and store their index in the list in an index property on the button itself.

  for (var i = 0; i < items.length; i++) {
    items[i].index = i;
  }

The handlekeys() function does the rest. We read the code of the key pressed and compare it with the codes lookup table. This also means we only react to arrow keys in our function. We then get the current element the key was pressed on and check if it has an index property. If it has one, we check if an element exist in the collection that is in the direction we want to move. We do this by adding the index of the current element to the value returned from the lookup table. If the element exists, we focus on it.

  function handlekeys(ev) {
    var keycode = ev.keyCode;
    if (codes[keycode]) {
      var t = ev.target;
      if (t.index !== undefined) {
        if (items[t.index + codes[keycode]]) {
          items[t.index + codes[keycode]].focus();
        }
      }
    }
  }

We apply a keyup event listener to the list and we’re done :)

  list.addEventListener('keyup', handlekeys);

If you feel like following this along live, here’s a quick video tutorial of me explaining all the bits and bobs.

The video has a small bug in the final code as I am not comparing the count property to undefined, which means the keyboard functionality doesn’t work on the first item (as 0 is falsy).

https://www.christianheilmann.com/2016/08/15/better-keyboard-navigation-with-progressive-enhancement/

Cicadas are an interesting insect. They live most of their time as a nymph under the ground in between 2 and 5 years, but some species live until 17 years before coming out and die six weeks after. What does it tell us about all the hidden work we put during our lifetime and blooms and shines for only a couple of hours.

Tune of the week: Ella Fitzgerald - Summertime (1968)

Webcompat Life

Progress this week:

Today: 2016-08-15T08:58:55.633182
298 open issues
----------------------
needsinfo       4
needsdiagnosis  80
needscontact    17
contactready    29
sitewait        158
----------------------

You are welcome to participate

Webcompat issues

(a selection of some of the bugs worked on this week).

• Gecko and Blink/WebKit have different default CSS border-width values for the input element. It breaks a site. If we decide to fix it in Gecko, do we break other sites relying on this default value?
• Performance issues on a heavy map Web site, though I'm not sure it is really a Web compatibility issue. It looks like more of something related to Gecko.
• Another issue related to layout with a content inside a form. I need to dig a bit more.
• no tap on priceline
• Use chrome only for transcribeme
• When using element.removeEventListener('event', callback) never forgets the second argument because it fails in Firefox, though that seems to be working in Chrome.
• mask, background and mask-image difference creates immaterial design. The most important now being to really find what is the source of the issue.

WebCompat.com dev

• Is invalid always the right keyword for closing an issue? From our side (project owner) it is invalid because it is not in the scope of the project, or there isn't enough details to reproduce. But from the user's perspective who had genuinely an issue (whatever the issue is), it can be felt as a strong rejection along the lines of "We don't care about you". Maybe we should find a better way of closing issues when they are out of scope.

Reading List

• More a quote of the day, but spot on: > Wondering how long it will take for publishers to realize it’s Medium that desperately needs them and not the other way around.
• And another one from Adam. And I really wish we could do that in a cool way! > Almost at our 3000th bug on webcompat.com. The lucky reporter who hits 3000 wins a broken light bulb

Follow Your Nose

• Previous Worklog
• Bugzilla Activity
• Github Activity

TODO

• Document how to write tests on webcompat.com using test fixtures.
• ToWrite: Amazon prefetching resources with for Firefox only.

Otsukare!

http://www.otsukare.info/2016/08/15/worklog-cicada

What was supposed to be one blog post about memory segmentation turned into what will be a series of posts. As the first in the series, we cover the extreme basics of object files and symbols. In follow up posts, I plan to talk about static libraries, dynamic libraries, dynamic linkage, memory segments, and finally memory usage accounting. I also cover command line tools for working with these notions, both in Linux and OSX.

A quick review of the compilation+execution pipeline (for terminology):

1. Lexing produces tokens
2. Parsing produces and abstract syntax tree
3. Analysis produces a code flow graph
4. Optimization produces a reduced code flow graph
5. Code gen produces object code
6. Linkage produces a complete executable
7. Loader instructs the OS how to start running the executable

This series will focus on part #6.

Let’s say you have some amazing C/C++ code, but for separations of concerns, you want to start moving it out into separate source files. Whereas previously in one file you had:

1
2
3
4
5
6
7
8

// main.c
#include 
void helper () {
  puts("helper");
}
int main () {
  helper();
}

You now have two source files and maybe a header:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// main.c
#include "helper.h"
int main () {
  helper();
}

// helper.h
void helper();

//helper.c
#include 
#include "helper.h"
void helper () {
  puts("helper");
}

In the single source version, we would have compiled and linked that with clang main.c and had an executable file. In the multiple source version, we first compile our source files to object files, then link them altogether. That can be done separately:

1
2
3

$ clang -c helper.c     # produces helper.o
$ clang -c main.o       # produces main.o
$ clang main.o helper.o # produces a.out

We can also do the compilation and linkage in one step:

1

$ clang helper.c main.c # produces a.out

Nothing special thus far; C/C++ 101. In the first case of separate compilation and linkage steps, we were left with intermediate object files (.o). What exactly are these?

Object files are almost full executables. They contain machine code, but that code still requires a relocation step. It also contains metadata about the addresses of its variables and functions (called symbols) in an associative data structure called a symbol table. The addresses may not be the final address of the symbol in the final executable. They also contain some information for the loader and probably some other stuff.

Remember that if we fail to specify the helper object file, we’ll get an undefined symbol error.

1
2
3
4
5
6

$ clang main.c
Undefined symbols for architecture x86_64:
  "_helper", referenced from:
      _main in main-459dde.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The problem is main.o refers to some symbol called helper, but on it’s own doesn’t contain any more information about it. Let’s say we want to know what symbols an object file contains, or expects to find elsewhere. Let’s introduce our first tool, nm. nm will print the name list or symbol table for a given object or executable file. On OSX, these are prefixed with an underscore.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ nm helper.o
0000000000000000 T _helper
                 U _puts

$ nm main.o
                 U _helper
0000000000000000 T _main

$ nm a.out
...
0000000100000f50 T _helper
0000000100000f70 T _main
                 U _puts
...

Let’s dissect what’s going on here. The output (as understood by man 1 nm) is a space separated list of address, type, and symbol name. We can see that the addresses are placeholders in object files, and final in executables. The name should make sense; it’s the name of the function or variable. While I’d love to get in depth on the various symbol types and talk about sections, I don’t think I could do as great a job as Peter Van Der Linden in his book “Expert C Programming: Deep C Secrets.”

For our case, we just care about whether the symbol in a given object file is defined or not. The type U (undefined) means that this symbol is referenced or used in in this object code/executable, but it’s value wasn’t defined here. When we compiled main.c alone and got the undefined symbol error, it should now make sense why we got the undefined symbol error for helper. main.o contains a symbol for main, and references helper. helper.o contains a symbol for helper, and references to puts. The final executable contains symbols for main and helper and references to puts.

You might be wondering where puts comes from then, and why didn’t we get an undefined symbol error for puts like we did earlier for helper. The answer is the C runtime. libc is implicitly dynamically linked to all executables created by the C compiler. We’ll cover dynamic linkage in a later post in this series.

When the linker performs relocation on the object files, combining them into a final executable, it goes though placeholders of addresses and fills them in. We did this manually in our post on JIT compilers.

While nm gave us a look into our symbol table, two other tools I use frequently are objdump on Linux and otool on OSX. Both of these provide disassembled assembly instructions and their addresses. Note how the symbols for functions get translated into labels of the disassembled functions, and that their address points to the first instruction in that label. Since I’ve shown objdump numerous times in previous posts, here’s otool.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

$ otool -tV helper.o
helper.o:
(__TEXT,__text) section
_helper:
0000000000000000    pushq    %rbp
0000000000000001    movq    %rsp, %rbp
0000000000000004    subq    $0x10, %rsp
0000000000000008    leaq    0xe(%rip), %rdi         ## literal pool for: "helper"
000000000000000f    callq    _puts
0000000000000014    movl    %eax, -0x4(%rbp)
0000000000000017    addq    $0x10, %rsp
000000000000001b    popq    %rbp
000000000000001c    retq
$ otool -tV main.o
main.o:
(__TEXT,__text) section
_main:
0000000000000000    pushq    %rbp
0000000000000001    movq    %rsp, %rbp
0000000000000004    movb    $0x0, %al
0000000000000006    callq    _helper
000000000000000b    xorl    %eax, %eax
000000000000000d    popq    %rbp
000000000000000e    retq
$ otool -tV a.out
a.out:
(__TEXT,__text) section
_helper:
0000000100000f50    pushq    %rbp
0000000100000f51    movq    %rsp, %rbp
0000000100000f54    subq    $0x10, %rsp
0000000100000f58    leaq    0x43(%rip), %rdi        ## literal pool for: "helper"
0000000100000f5f    callq    0x100000f80             ## symbol stub for: _puts
0000000100000f64    movl    %eax, -0x4(%rbp)
0000000100000f67    addq    $0x10, %rsp
0000000100000f6b    popq    %rbp
0000000100000f6c    retq
0000000100000f6d    nop
0000000100000f6e    nop
0000000100000f6f    nop
_main:
0000000100000f70    pushq    %rbp
0000000100000f71    movq    %rsp, %rbp
0000000100000f74    movb    $0x0, %al
0000000100000f76    callq    _helper
0000000100000f7b    xorl    %eax, %eax
0000000100000f7d    popq    %rbp
0000000100000f7e    retq

Also note that for static linkage, symbols need to be unique*, as they refer to memory locations to either read/write to in the case of variables or locations to jump to in the case of functions.

1
2
3
4
5
6
7
8
9
10
11
12

$ cat double_define.c
void a () {}
void a () {}
int main () {}
$ clang double_define.c
double_define.c:2:6: error: redefinition of 'a'
void a () {}
     ^
double_define.c:1:6: note: previous definition is here
void a () {}
     ^
1 error generated.

*: there’s a notion of weak symbols, and some special things for dynamic libraries we’ll see in a follow up post.

Languages like C++ that support function overloading (functions with the same name but different arguments, return types, namespaces, or class) must mangle their function names to make them unique.

Code like:

1
2
3
4
5
6
7

namespace util {
  class Widget {
    public:
      void doSomething (bool save);
      void doSomething (int n);
  };
}

Will produce symbols like:

1
2
3
4
5

$ clang class.cpp -std=c++11
$ nm a.out
0000000100000f70 T __ZN4util6Widget11doSomethingEb
0000000100000f60 T __ZN4util6Widget11doSomethingEi
...

Note: GNU nm on Linux distros will have a --demangle option:

1
2
3
4
5

$ nm --demangle a.out
...
00000000004006d0 T util::Widget::doSomething(bool)
00000000004006a0 T util::Widget::doSomething(int)
...

On OSX, we can pipe nm into c++filt:

1
2
3
4

$ nm a.out | c++filt
0000000100000f70 T util::Widget::doSomething(bool)
0000000100000f60 T util::Widget::doSomething(int)
...

Finally, if you don’t have an object file, but instead a backtrace that needs demangling, you can either invoke c++filt manually or use demangler.com.

Rust also mangles its function names. For FFI or interface with C functions, other languages usually have to look for or expose symbols in a manner suited to C, the lowest common denominator. C++ has extern "C" blocks and Rust has extern blocks.

We can use strip to remove symbols from a binary. This can slim down a binary at the cost of making stack traces unreadable. If you’re following along at home, try comparing the output from your disassembler and nm before and after running strip on the executable. Luckily, you can’t strip the symbols out of object files, otherwise they’d be useless as you’d no longer be able to link them.

If we compile with the -g flag, we can create a different kind of symbol; debug symbols. Depending on your compiler+host OS, you’ll get another file you can run though nm to see an entry per symbol. You’ll get more info by using dwarfdump on this file. Debug symbols will retain source information such as filename and line number for all symbols.

This post should have been a simple refresher of some of the basics of working with C code. Finding symbols to be placed into a final executable and relocating addresses are the main job of the linker, and will be the main theme of the posts in this series. Keep your eyes out for more in this series on memory segmentation.

http://nickdesaulniers.github.io/blog/2016/08/13/object-files-and-symbols/

Stencil and its 700,000+ royalty-free images are now available for Firefox users, thanks to WebExtensions.

From enhanced security for users to cross-browser interoperability and long-term compatibility with Firefox—including compatibility with multiprocess Firefox—there are many reasons why WebExtensions are becoming the future of add-on development.

So it’s awesome to see so many developers already embracing WebExtensions. To date, there are more than 700 listed on AMO. In celebration of their efforts to modernize their add-ons, I wanted to share a few interesting ones I recently stumbled upon…

musicfm has an impressively vast and free music library, plus an intuitive layout for simple browsing. However, I’m more of a SoundCloud music consumer myself, so I was intrigued to find SCDL SoundCloud Downloader, which is built for downloading not just music files, but related artwork and other meta information.

The popular Chrome add-on Stencil is now available for Firefox, thanks to WebExtensions. It’s a diverse creativity tool that allows you to combine text and imagery in all sorts of imaginative ways.

musicfm offers unlimited free music and the ability to create your own playlists and online stations.

I’m enjoying Dark Purple YouTube Theme. I think video resolution reads better against a dark background.

Keepa is one of the finest Amazon price trackers out there that also supports various international versions of the online bazaar (UK, Germany, Japan, plus many others).

Googley Eyes elegantly informs you which sites you visit send information about you to Google.

Search Engine Ad Remover is a perfectly titled extension. But arguably even better than removing ads is replacing them with cat pics.

Thanks for your continued support as we push ahead with a new model of extension development. If you need help porting your add-on to WebExtensions, check out the resources we’ve compiled. If you’re interested in writing your first add-on with WebExtensions, here’s how to get started.

https://blog.mozilla.org/addons/2016/08/12/webextensions-taking-root/

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

http://jennierosehalperin.me/2016/08/12/hello-world/

Early this year I started looking into the VR (Virtual Reality) web applications. Web browsers now natively support VR applications using WebVR JavaScript API. We can now design virtual worlds using markup language and connect them to devices such as Oculus Rift and Leap motion controller using just a web browser.

To hit the ground running with WebVR. I started an experiment to capture Hackerspace Phnom Penh using Google Cardboard camera app and display it using A-Frame framework. The Google Cardboard camera photosphere is not supported by A-Frame. But the positive responses to my query encouraged me to try an hack using A-Frame Panorama component.

Is it possible to embed Google cardboard camera image capture in a @aframevr powered site?

— Arky (@playingwithsid) December 17, 2015

And it works. Almost I had to tweak the scale setting a bit to try get the perspective right but it does work. The ideal solution is to create a A-Frame custom component, that I leave it for more skilled people.

The markup needed for this demo is simple, you can achieve this with one line.

You can see the demo on Youtube or visit this webpage in an compatible web browser.

http://playingwithsid.blogspot.com/2016/08/early-this-year-i-started-looking-into.html

Hello, SUMO Nation!

How have you been? We missed you! Some of you have gone on holidays and already came back (to the inaudible – but huge – relief of the hundreds of users who ask questions in the forums and the millions of visitors who read the Knowledge Base). Let’s move on to the updates, shall we?

Welcome, new contributors!

• … who seem to be enjoying summer away from computers… The way they should! So, no major greeting party for anyone this week, since you’ve been fairly quiet… But, if you just joined us, don’t hesitate – come over and say “hi” in the forums!

Most recent SUMO Community meeting

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

The next SUMO Community meeting…

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

Community

• PLATFORM REMINDER! The Platform Meetings are BACK! If you missed the previous ones, here is the etherpad, with links to the recordings on AirMo.
  • MIGRATION REMINDER Please take a look at this migration document and use this migration thread to put questions/comments about it for everyone to share and discuss. As much as possible, please try to keep the migration discussion and questions limited to those two places – we don’t want to chase ten different threads in eight different places ;-).
  • Having said that – thanks to everyone participating in the discussion – we are looking forward to hearing from more of you!
  • Please help us with the audits of existing guidelines and documentation – read and tell us what you think in the following documents:
    • Messaging – Get Involved page
    • Support Forum
    • L10n documentation
    • Social resources
• Ongoing reminder #1: if you think you can benefit from getting a second-hand device to help you with contributing to SUMO, you know where to find us.
• Ongoing reminder #2: we are looking for more contributors to our blog. Do you write on the web about open source, communities, SUMO, Mozilla… and more? Do let us know!
• Ongoing reminder #3: want to know what’s going on with the Admins? Check this thread in the forum.

Social

• The results for the SUMO Social Day last week were shared out during the Monday Project Meeting.
• Come and sign up for Sprinklr – we need your help! Use the step-by-step guide here. Take a look at some useful videos:
  • Getting started & replying to users
  • Replying to users (continued)
• Ongoing reminder: We have a training out there for all those interested in Social Support – talk to Madalina or Costenslayer on #AoA (IRC) for more information.

Support Forum

Firefox

• for Android
  • no news from the Android side…

• for Desktop
  • …or the Desktop side…

• for iOS
  • …or the iOS side…
    

…what a quiet ending to this post, I hope you did not fall asleep. Then again, a siesta on a hot summer day is the best thing ever, trust me :-). Keep rocking (quietly, at least in the summer) the helpful web!

https://blog.mozilla.org/sumo/2016/08/11/whats-up-with-sumo-11th-august/

Weekly project updates from the Mozilla Connected Devices team.

https://air.mozilla.org/connected-devices-weekly-program-update-20160811/