mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 11 uur 26 min geleden

Anthony Hughes: Visualizing Crash Data in Bugzilla

di, 16/08/2016 - 23:40

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 crash dashboard for our most common device/driver combination (Intel HD 4000 w/driver 10.18.10.4276)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.

//bugzil.la/1241921Socorro 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.

Categorieën: Mozilla-nl planet

Air Mozilla: 2016 Intern Presentations

di, 16/08/2016 - 21:30

2016 Intern Presentations 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...

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 143

di, 16/08/2016 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us 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 New Crates & Project Updates 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.

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.

New Contributors
  • Andrii Dmytrenko
  • Cameron Hart
  • Cengiz Can
  • Chiu-Hsiang Hsu
  • Christophe Vu-Brugier
  • Clement Miao
  • crypto-universe
  • Felix Rath
  • hank-der-hafenarbeiter
  • José manuel Barroso Galindo
  • Krzysztof Garczynski
  • Luke Hinds
  • Marco A L Barbosa
  • Mark-Simulacrum
  • Matthew Piziak
  • Michael Gattozzi
  • Patrick McCann
  • Pietro Albini
  • ShyamSundarB
  • srdja
  • Stephen Lazaro
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

No jobs listed for this week.

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

The best way to learn Rust is to just try! and see what works (or is this to just see what works? now?)!

llogiq on /r/rust.

Thanks to UtherII for the suggestion.

Submit your quotes for next week!

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

Categorieën: Mozilla-nl planet

Jen Kagan: to-do lists for big problems => small pieces

di, 16/08/2016 - 04:06

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.

Screen Shot 2016-08-15 at 9.31.20 PM

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:

Screen Shot 2016-08-15 at 9.50.13 PM

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!

Categorieën: Mozilla-nl planet

Dave Townsend: A new owner for the add-ons manager

di, 16/08/2016 - 01:29

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.

Categorieën: Mozilla-nl planet

Mitchell Baker: Increasing Information Flow at Mozilla

ma, 15/08/2016 - 22:26

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.

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: “Restart Required” Badge on AMO

ma, 15/08/2016 - 22:22

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!

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 15 Aug 2016

ma, 15/08/2016 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Christian Heilmann: Better keyboard navigation with progressive enhancement

ma, 15/08/2016 - 11:45
Keyboard

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.

<ul> <li><button>1</button></li> <li><button>2</button></li> <li><button>3</button></li> … <li><button>20</button></li> </ul>

example how to tab through a list of buttons

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.

tabbing through a grid item by item

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:

navigating inside a grid of elements using the cursor keys going up, down, left and right

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.

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

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):

moving in the grid is the same as moving along an axis

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.

diagram of navigation in the grid

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).

Categorieën: Mozilla-nl planet

Ian Bicking: A Product Journal: Oops We Made A Scraper

ma, 15/08/2016 - 07:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

A while back we got our first contributor to PageShot, who contributed a feature he wanted for Outernet – the ability to use PageShot to create readable and packaged versions of websites for distribution. Outernet is a neat project: they are building satellite capacity to distribute content anywhere in the world. But it’s purely one-way, so any content you send has to be complete. And PageShot tries pretty hard to identify and normalize all that content.

Lately I spent a week with the Activity Stream team, and got to thinking about the development process around recommendations. I’d like to be able to take my entire history and actually get the content, and see what I can learn from that.

And there’s this feature in PageShot to do just that! You can install the add-on and enable the pref to make the browser into a server:

about:addons prefs

After that you can get the shot data from a page with a simple command:

$ url=https://mail.google.com $ server=http://localhost:10082 $ curl "${server}/data/?url=${url}&allowUnknownAttributes=true&delayAfterLoad=1000" > data.json

allowUnknownAttributes preserves attributes like data-* attributes that you might find useful in your processing. delayAfterLoad gives the milliseconds to wait, usually for the page to “settle”.

A fun part of this is that because it’s in a regular browser it will automatically pick up your profile and scrape the page as you, and you’ll literally see a new tab open for a second and then close. Install an ad blocker or anything else and its changes will also be applied.

The thing you get back will be a big JSON object:

{ "bodyAttrs": ["name", "value"], "headAttrs": [], "htmlAttrs": [], "head": "html string", "body": "html string", "resources": { "uuid": { "url": "..." } } }

There’s other stuff in there too (e.g., Open Graph properties), but this is what you need to reconstruct the page itself. It has a few nice features:

  1. The head and body are well formed; they are actually serialized from the DOM, not related to the HTTP response.
  2. All embedded resources (mostly images) are identified in the resources mapping. The URLs in the page itself are replaced with those UUIDs, so you can put them back with a simple string substitutions, or you can rewrite the links easily.
  3. Actual links (<a href>) should all be absolute.
  4. It will try to tell you if the page is private (though it’s just a heuristic).
  5. If you want, it’ll include a screenshot of the full page as a data: URL (use &thumbnailWidth=px to choose how wide).
  6. CSS will be inlined in a <style> tag, perhaps reducing the complexity of the page for you.

Notably scripts and hidden elements will not be included (because PageShot was written to share visible content and not to scrape content).

Anyway, fun to realize the tool can address some hidden and unintentional use cases.

Categorieën: Mozilla-nl planet

The Servo Blog: This Week In Servo 75

ma, 15/08/2016 - 02:30

In the last week, we landed 108 PRs in the Servo organization’s repositories.

Thanks to the community for their patience while our continuous integration services were were in a more manual mode as we adapted to some changes from Travis CI that complicated our autolander. Things should be fine now - please reach out in #servo if you see anything!

We are delighted to announce that long-time contributor Michael Howell (notriddle) has been made a reviewer! Thanks for all of your contributions and congratulations on your new role.

Planning and Status

Our overall roadmap is available online and now includes the initial Q3 plans. From now on, we plan to include the quarterly plan with a high-level breakdown in the roadmap page.

This week’s status updates are here.

Notable Additions
  • shinglyu fixed auto positioning on absolute flows
  • glennw implemented a slew of initial optimizations for the new WebRender
  • nox upgraded roughly half the Rust ecosystem to a new version of Euclid
  • notriddle added a flag to dump computed style values
  • ms2ger updated Glutin from upstream
  • paul updated browserhtml
  • vvuk continued his tear through the ecosystem, fixing everything to build cleanly on Windows with MSVC
  • simonsapin implemented ToCss for selector types
  • larsberg migrated our CI to check Travis status indirectly via GitHub
  • wafflespeanut added support for word-spacing for geckolib
  • anholt improved our WebGL support on Linux
  • msreckovic corrected inner radii for borders in WebRender
  • UK992 improved tidy’s license validation code
  • emilio fixed issues related to the client point with fixed positioned stacking contexts
  • paul added a Homebrew package for another path to the macOS nightly build
  • emilo redesigned the style sharing API
  • jennalee implemented the Request API
  • splav fixed a bug with the layout of inline pseudo elements
New Contributors

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Screenshot

None this week.

Categorieën: Mozilla-nl planet

Karl Dubost: [worklog] Edition 031. Heat wave and cicadas falling

ma, 15/08/2016 - 01:59

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! > <adam_s> Almost at our 3000th bug on webcompat.com. The lucky reporter who hits 3000 wins a broken light bulb
Follow Your Nose TODO
  • Document how to write tests on webcompat.com using test fixtures.
  • ToWrite: Amazon prefetching resources with <object> for Firefox only.

Otsukare!

Categorieën: Mozilla-nl planet

Nick Desaulniers: Object Files and Symbols

zo, 14/08/2016 - 05:46

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 an 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 <stdio.h> 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 <stdio.h> #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 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 through 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

readelf -s <object file> will give us a list of symbols on Linux. ELF is the file format used by the loader on Linux, while OSX uses Mach-O. Thus readelf and otool, respectively.

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 through 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.

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: WebExtensions Taking Root

za, 13/08/2016 - 00:48
Stencil and its 700,000+ royalty-free images are now available for Firefox users, thanks to WebExtensions.

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 playlists and online stations.

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.

Categorieën: Mozilla-nl planet

Jennie Rose Halperin: Hello world!

za, 13/08/2016 - 00:30

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

Categorieën: Mozilla-nl planet

Mozilla Open Design Blog: And then there were five

vr, 12/08/2016 - 21:01

It’s been a little quiet around here for a week or so because we’ve had our heads down agreeing the final verbal themes for the Mozilla brand project.

Six weeks ago we shared our initial seven themes, and then took hundreds of comments from the Mozillians at the All Hands conference in London. We gathered some useful comments online, plus some invaluable feedback internally – especially about upping the positivity and doing more with the whole principle of ‘open’.

thegoodfightSo now we’re ready to share our final five thematic options.

Taking a stand

Right from the off there’s been a desire to play to Mozilla’s non-profit strengths, amplify its voice and turn up the volume. Previously this overall direction was more about what Mozilla were fighting against – we’ve turned this to be more about what Mozilla are fighting for.

Theme 1: The Good Fight
Sometimes you have to fight for what you believe in. Mozilla believes in an open, equal, accessible Internet – for everyone. One that makes us active creators, not passive receivers. One that works for the benefit of the many, not the few. We’re ready to take a stand, link arms with others who share our view of the future, and provide tools and opportunities for those who need them. You can wish for a better web, and a better world. Or you can get involved and make it happen.

fortheinternetofpeople_2
Positive impact on humanity
Another realization after our first stage of work was that we’d become too mired in geek-speak and weren’t successfully explaining how a healthy Internet helps everyone. So theme two concentrates on people, not machines.

Theme 2: For the Internet of People
Mozilla believes that the Internet should work for people – and the best way to achieve that is to give people the power to shape the Internet. At its best, the Internet is humanity’s greatest invention. It has the ability to connect human minds and free human potential on a scale never seen before. But we need to keep it open, always. We need to distribute power widely, not divide it narrowly. We need to build bridges, not walls. The future of the Internet is amazing, as long as it remains the Internet of People.

chooseopen
About ‘Open’
We had a sneaking suspicion that we’d buried the whole debate about ‘open’ too deep in the first tranche of work. So the third theme addresses this head on.

Theme 3: Choose open
The future of the internet can be open, or closed. We choose open. We choose an internet that is equal and accessible by default. Open to ideas, open to collaboration, open to everyone. But it isn’t a choice we can make alone. An open web is something we all have to choose together. And it involves many other choices. The tools we use. The products we support. The way we behave online. Those choices can be complex, but the guiding principle should always be simple. Choose open.

betterinternetstartshere
The pioneers
In our discussions at the Mozilla London All Hands meeting, and since, we’ve been talking about Mozilla’s pioneering role in the early development of the Internet, and ever since. So theme four looks hard at this (and brings back some of that grit as well, just for good measure).

Theme 4: With you from the start
Mozilla was, is, and always will be on the side of those who want a better, freer, more open Internet. In the early days, we were among those helping to embed principles of openness and accessibility into the web’s DNA. Now those principles matter more than ever. We need an Internet that works wonders for the many, not just the few. We need to stand by the founding ideals of the Internet, and carry them forward into new products, platforms, conversations, and great ideas. We’ve been with you from the start. And we’re just getting started.

mavericksunited
The maker community
Last, but definitely not least, we wanted a clearer idea that summed up the dynamic online community worldwide that Mozilla represents. Now that we’ve met hundreds of them in person, we wanted something that verbally did them justice.

Theme 5: Mavericks, united
The Internet belongs to mavericks and independent spirits. It’s the sum total of millions of people working towards something greater than themselves. We believe the independent spirit that founded the Internet is vital to its future. But being independent doesn’t mean being alone. We bring together free thinkers, makers and doers from around the world. We create the tools, platforms, conversations, and momentum to make great things happen. We’re not waiting for the future of the Internet to be decided by others. It’s ours to invent.

What’s next? Well, in parallel to agreeing all of the above, we’ve started the design routes that go with each one. With a bit of luck, we’ll be ready to share our first thoughts on that very soon.

Categorieën: Mozilla-nl planet

Arky: Embedding Google Cardboard Camera VR Photosphere with A-Frame

vr, 12/08/2016 - 06:44

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.


<a-scene> <a-sky src="img/hackerspace.vr.jpg" radius="2400" scale="2 1 2"> </a-sky> </a-scene>

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


Categorieën: Mozilla-nl planet

Mozilla Reps Community: RepsNext – Improvements overview

vr, 12/08/2016 - 00:41

Over the past months we have extensively worked on the future of the Reps program – called RepsNext. In several working groups we worked on proposals to improve the Reps program, keeping up with the Mozilla’s and our Reps’ needs. Following the RepsNext Introduction Video this blog post provides a broad overview of the various focus areas and invites further conversation.

RepsNext – The Visual Structure

Here is a visual overview of the RepsNext structure:

RepsNext structure as a flow chart, also explained in the next few paragraphs

With RepsNext there will be three different tracks to be specialized in:

  • Functional Goals
  • Leadership
  • Resources

The Functional Goals track is still work-in-progress, so we cannot provide a lot of information yet. We believe this will be a group of Reps who are heavily engaged in Mozilla’s functional areas.

Reps from the Leadership track support other Mozillians and communities through their broad  knowledge. Reps in this track will regularly exchange information among themselves, creating alignment among the various functional goals in the Reps program.

For all resource requests there is a dedicated Resources track which is specialized on increasing the program’s impact. The Review team, which is part of this track, is responsible to review budget requests.

Finally, every Rep will have a coach who has strong leadership skills and can provide guidance on Reps’ personal development.

Through this structure Reps from all specialization tracks can work together towards the overall Reps and Participation goals, each Rep contributing with their particular strengths to advance  Mozilla’s mission.

What are we going to improve in the Reps program?

Let’s compare the current state of the Reps program with the proposed improvements.

Area Current Future Alignment with Mozilla There are no formal alignment processes with the Mozilla organization The Reps Program is aligned with the Participation team’s OKRs. Council members  participate in important planning and strategy meetings Budget Request Reviews All Reps can submit budget requests, leading to a lot of ping pong when reviewing those Reps can specialize on “Resources” and file requests aligned for impact. This leads to faster reviews Reps Activities Reps are mostly focused on running events in their communities Reps will be able to specialize in a certain topic (Resources, Leadership, Functional areas) Mentoring Mentors are busy with Budget Request reviews Mentors will be focusing on personal development, no need to do budget reviews anymore (but you can be part of the Resources track) Leadership Leadership has been part of Reps since its very beginning, it was not formally nurtured very well With the Leadership track we enable Reps’ personal development and develop their leadership potential for them to expand impact on their fellow Mozillians Moving forward

We plan to go into more detail for each of the above mentioned areas in future blog posts. In order to prioritize and invest our (volunteering) energy in the most impactful way, we need your help: Which of the above areas are you most interested in? Where do you want to hear more in the next blog post? Which concerns do you have? What do you find intriguing?

Please let us know in Discourse and we aim to come up with an article answering to all your questions in a timely manner.

Categorieën: Mozilla-nl planet

Cameron Kaiser: And now for something completely different: what you missed by not going to Vintage Computer Festival West XI

do, 11/08/2016 - 06:30
With the exception of this man, you all missed out by not coming to the reincarnated Vintage Computer Festival West. You had a chance to meet me and my beloved Tomy Tutor (which you can emulate on a Power Mac or Intel Mac). You had a chance to see other inferior exhibits. You didn't. So let me now make you feel bad about what you missed out on.

You could have seen the other great exhibits at the Computer History Museum,

the complete Tomy Tutor family, hosted by my lovely wife and me that corrupted young minds from a very early age (for which I won a special award for Most Complete and 2nd place overall in the Microcomputer category), seen a really big MOS 6502 recreation, played Maze War, solved differential equations the old fashioned way, realized that in Soviet Russia computer uses you, given yourself terrible eyestrain, used a very credible MacPaint clone on a Tandy Color Computer, messed with Steve Chamberlain's mind, played with an unusual Un*x workstation powered by the similarly unusual (and architecturally troublesome) Intel i860, marveled at the very first Amiga 1000 (serial #1), attempted to steal an Apple I, snuck onto Infinite Loop on the way back south, and got hustled off by Apple security for plastering "Ready for PowerPC upgrade" stickers all over the MacBooks in the company store.

But you didn't. And now it's too late.*

*Well, you could always come next year.

Categorieën: Mozilla-nl planet