mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 37 min 2 sec 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