Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 20 uur 14 min geleden

Air Mozilla: Webdev Extravaganza: April 2015

di, 07/04/2015 - 19:00

 April 2015 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on.

Categorieën: Mozilla-nl planet

Michael Kaply: The Future of CCK2

di, 07/04/2015 - 18:51

With the removal of the distribution/bundles directory, as well as multiprocess Firefox, I'm currently rewriting portions of the CCK2 to be more forward compatible.

This involves removing any dependencies on the distribution/bundles directory as well as rewriting the code to no longer use XUL overlays.

As I'm doing this work, it has me wondering; should the CCK2 be a library that you simply pass a config to and it does the work (as it is today), or should the CCK2 Wizard generate a complete AutoConfig.js file that stands alone and can be included with little or no other outside files?

In doing surveys in the past, there are quite a few people that just use AutoConfig. Would it be worthwhile to make the process of generating AutoConfig files easier? Or is this a very small group of people?

What do you think the future should hold for the CCK2?

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 38 beta1 to beta2

di, 07/04/2015 - 18:44

In this second beta, we landed an important number of fixes.

We took changes to enable the suggested tiles in this release. We also uplifted a bunch of changes for the reading list, MSE and EME.

We also uplifted the fixes made for 37.0.1.

  • 123 changesets
  • 198 files changed
  • 5357 insertions
  • 1539 deletions

ExtensionOccurrences js39 java37 cpp34 h16 html11 py10 jsm9 css8 xml6 ini4 build4 xul3 mn3 m42 json2 in2 txt1 svg1 mozbuild1 mm1 list1 ipdl1 inc1 common1

ModuleOccurrences browser52 mobile44 dom29 toolkit17 python10 media8 layout5 js5 ipc5 image5 netwerk4 build3 widget2 testing2 storage2 services1 modules1 gfx1 docshell1

List of changesets:

Ryan VanderMeulenBacked out changeset b4b774124dee (Bug 1105803) because tests are green without it. a=test-only - c71114667500 Ryan VanderMeulenBacked out changeset 0fa80dee3113 (Bug 1126639) because tests are green without it. a=test-only - 6604edc0f5da Mark HammondBug 1149023 - fix errors deleting an already synced readinglist item. r=adw, a=readinglist - 4e05802f6eb4 Jared WeinBug 1147113 - Filter the article properties in ReaderParent.jsm instead of ReadingList.jsm. r=adw, a=readinglist - 7dded32396ba Drew WillcoxonBug 1147554 - Lazily create desktop reading list's database connection. r=markh, a=readinglist - acc50d404648 Drew WillcoxonBug 1147554 - Lazily create desktop reading list's database connection (follow-up: revert erroneous chage). r=me, a=readinglist - 9104d1f928a7 Drew WillcoxonBug 1149105 - Fix various desktop reading list sync failures, add more logging. r=markh, a=readinglist - 818e63fbfba2 Marina SamuelBug 1126182: Extract related tiles data from links json and store for later selection. r=adw, a=sylvestre - 83bcf11d00ef Marina SamuelBug 1126184: Part 1: Make DirectoryLinksProvider listen to PlacesProvider and update its _topSitesWithRelatedLinks cache. r=adw, a=sylvestre - 869ba4681d1b Marina SamuelBug 1126184: Part 2: Select a single tile to show as the first unpinned tile based on a user's top sites. r=adw, a=sylvestre - 48564fb0e663 Marina SamuelBug 1126184: Part 3: Mochitest fixes for suggested tiles. r=adw, a=sylvestre - 1a007e477655 Marina SamuelBug 1126188: Show suggested tile explanation text under a suggested tile. r=adw, a=sylvestre - e9021ea8d7ca Marina SamuelBug 1126186: Allow users to turn off all tiles that aren't history tiles and update newtab cogmenu wording. r=adw, a=sylvestre - db2b58500934 Marina SamuelBug 1145410: Return valid results when querying the provider cache while it's empty or being populated. r=adw, a=sylvestre - 56763fc69140 Marina SamuelBug 1143797 - Allow clicking on suggested explanation text to see overlay explaining the suggested tile. r=adw, a=sylvestre - 65f2aa5f2dd7 Marina SamuelBug 1143745 - Update the way Firefox reads directoryLinks.json sent from the server for the tiles v3 endpoint. r=adw, a=sylvestre - 745269d59b33 Marina SamuelBug 1136208 - Change all references of 'related' to 'suggested' r=adw, a=sylvestre - 60f350a6b8b8 Ed LeeBug 1140496 - Only show a suggested tile url for some number of times or until clicked [r=adw, a=sylvestre] - 4afccec73fb9 Ed LeeBug 1146249 - Tiles on the newtab page don't wrap properly [r=adw, a=sylvestre] - 6892b485a7e0 Marina SamuelBug 1146146 - Maximize the number of rows of tiles by reducing the suggested explanation maximum line count to 2 instead of 3 [r=adw, a=sylvestre] - 5fd426f495ff Marina SamuelBug 1136203 - Remove thumbnail/title replacing functionality for history tiles. r=adw, a=sylvestre - 1d9b014f0414 Ed LeeBug 1149021 - Suggested tile with just an image shows a thumbnail instead [r=adw, a=sylvestre] - da2535172770 Marina SamuelBug 1105360: Only enhance tiles that are under the 'enhanced' key. r=adw, a=sylvestre - 311733df5675 Marina SamuelBug 1149680: Send the Firefox channel on fetch. r=adw, a=sylvestre - 96e8fba7c4c4 Marina SamuelBug 1149682: Don't cache (or show) sponsored suggested links. r=adw, a=sylvestre - 98144ed917cb Ed LeeBug 1148862 - Update pref to the new v3 endpoint [r=adw, a=sylvestre] - daf8a9291a9b Nick AlexanderBug 1140810 - Upload material (non-status) Reading List modifications. r=rnewman, a=readinglist - f1c7c471c2d8 Richard NewmanBug 1148432 - Sync reading list deletions. r=nalexander, a=readinglist - c27964aaa4c5 Nick AlexanderBug 1147473 - Expose Firefox Account debug information from Settings activity. r=rnewman, a=readinglist - ac9b83aca21f Nick AlexanderBug 1142596 - Use cached FxA OAuth tokens in Reading List sync. r=rnewman, a=readinglist - 0aedf96a7cdc Nick AlexanderBug 1148504 - Protect Firefox Account state with a critical section. r=rnewman, a=readinglist - 32b6b2c4a69e Richard NewmanBug 1147473 - Follow-up: move ReadingListConstants to avoid build flag pain., a=readinglist - c5baf4b4a350 Nick AlexanderBug 1148029 - Disable Reading List sync when using custom endpoints. r=rnewman, a=readinglist - ec6516ecdd71 Nick AlexanderBug 1140812 - React to Backoff and Retry-After headers from Reading List storage servers. r=rnewman, a=readinglist - dff4ad268667 Nick AlexanderBug 1140813 - Schedule periodic Reading List syncs. r=rnewman, a=readinglist - 27f61020a9e4 Sebastian KaspariBug 1143280 - DateTimePicker: Replace deprecated DateFormat constants with local constants. r=rnewman, a=sylvestre - 14eb337e419a Sebastian KaspariBug 1143280 - SearchBar: Suppress deprecation warnings in constructor to allow building with API level 22. r=rnewman, a=sylvestre - f546eff14959 Jeff MuizelaarBug 1137716 - Fix driver version typo. a=lmandel - 25d2e5abebec Milan SreckovicBug 1149761 - Don't MOZ_CRASH if WARP fails. r=bas, a=lmandel - cf2036567077 Bas SchoutenBug 1149864 - Do not attempt to create any D3D11 device when safemode is turned on. r=jrmuizel, a=sledru - c4e7a4be6f63 Patrick McManusBug 1148328 - Disable alt-svc. r=dveditz, a=lmandel - d7bbef9132a4 Randell JesupBug 1147857 - Be careful about WebRTC stats query creation. r=jib, a=lmandel - 2c5d97fcb993 Randell JesupBug 1147857 - Followup patch to continue BuildStats cleanup. r=jib, a=lmandel - 108255910fbf Ryan VanderMeulenBug 1026815 - Disable test_bug565388.xul on Linux and OSX for frequent failures. a=test-only - 85c87a6f453f L. David BaronBug 1123979 - Annotate known intermittent assertion on crashtest. a=test-only - 231768361c8b Mark BannerBug 1139586 - Attempt to fix intermittent failures in Loop's Marionette unit tests by extending the timeout. r=mikedeboer, a=test-only - d30e64ad7e1f Neil DeakinBug 822298 - Window isn't focused so spellchecking doesn't happen, use waitForFocus first. a=test-only - fdb4e8b3eedb Martijn WargersBug 1148405 - Intermittent Mulet test_garbage_at_end_of_declarations.html,test_value_storage.html. r=smaug, a=test-only - 09687ee1bf7e Neil DeakinBug 1121671 - See if using the TabSwitchDone event will work. a=test-only - 3f7826efc5de Tim TaubertBug 1016312 - Fix intermittent browser_fullscreen-window-open.js failures by removing arbitrary timeouts. r=jaws, a=test-only - e98a992238e2 Patrick BrossetBug 1137771 - Intermittent browser_animation_play_pause_button.js. r=miker, a=test-only - b228af82453b Neil DeakinBug 1150038 - Add a waitForFocus to this test. a=test-only - cf89394816b1 Jon CoppeardBug 1149997 - Add v8-v5/check-raytrace.js test to expected CGC timeouts list. r=terrence, a=test-only - cc9ac7031506 Tim TaubertBug 1120748 - Split browser_ssl_error_reports.js into multiple tasks. r=felipe, a=test-only - b9d2266daf60 Tim TaubertBug 1120748 - Ensure the progress listener created by createNetworkErrorMessagePromise() isn't GCed too early. r=felipe, a=test-only - 9c755cdc241c Ryan VanderMeulenBacked out changeset 3f7826efc5de (Bug 1121671) for test failures. - ffb13ef5ff0a Chris PearceBug 1146201 - Delay navigator.requestMediaKeySystemAccess if CDM not downloaded yet or needs update. r=jwwang,ehsan a=sylvestre - b7e7470e83b3 Chris PearceBug 1146201 - Initiate check for GMP updates when JS requests CDM and we haven't installed it yet. r=spohl a=sylvestre - 9383010b69fe Chris PearceBug 1146201 - Remove "we can't play EME because..." notifications when we successfully play EME. r=gijs a=sylvestre - 7a04aad0ab5d Chris PearceBug 1146201 - Use message manager instead of observer service in GMPWrapper. r=markh a=sylvestre - c481e8a84a6c Philip CheeBug 1142997 - Cannot Print from Composer and other <editor> elements r=mossop a=sylvestre - e65f5a19d0e4 Hector ZhaoBug 1146869 - Make AM_PATH_{NSPR,NSS} compatible with input version in the form of major.minor. r=glandium, a=NPOTB - 0fce0415d8b4 Matt WoodrowBug 1138260 - Add typed Microseconds class and use it for the range removal algorithm. r=jya, r=kinetik, a=sledru - 67259acf0c1e Alessio PlacitelliBug 1138323 - Use https instead of http in Heartbeat's browser.selfsupport.url. r=ttaubert, a=sledru - bfe014dd05ef Alessio PlacitelliBug 1137481 - Adjust the Heartbeat UI and add a Learn More link. r=MattN, a=sledru - 94de32e773b8 Deepak KoliBug 1039540 - In-content preferences: Disable the sorting of rows of sub-dialogs when right clicking. r=MattN, a=sledru - a9d533ac9ff4 Jed DavisBug 1146116 - Clone File objects passed to mozSetFileArray into receiver's global. r=sicking, a=sledru - d3e9b16fc53f Seth FowlerBug 1148684 - Compact SourceBuffer even if it contains only one chunk. r=tn, a=sledru - ca8eaf3366e5 Seth FowlerBug 1148682 - Handle content length correctly for moz-icon channels. r=tn, a=sledru - 5f5a4c5a7e02 Nils Ohlmeier [:drno]Bug 1148572 - Improve H264 renegotiation handling. r=jesup, a=sledru - 8d84399a000b Boris ZbarskyBug 1148973 - When skipping shape guards in Ion common getter/setter code because the object has a non-configurable property, first verify that its current shape matches the shape we're using to compile our code. r=jandem, a=sledru - d6ec30c02b8d Andrea MarchesiniBug 1148032 - BroadcastChannel API should not bypass private browsing mode. r=ehsan, a=sledru - 125623fcc804 Michael ComellaBug 1132751 - Remove redundant ActionBar home setting. r=liuche, a=sledru - 8be55cae236f Michael ComellaBug 1132751 - Add android:logo to fennec application. r=liuche, a=sledru - b28b502e4aca Mark HammondBug 1146346 - Fix sync login when master-password was unlocked by something other than sync. r=ckarlof, a=sledru - edf4fa83d569 Vladan DjericBug 1149746 - Update expiry dates for probes that measure Telemetry health. r=rvitillo, a=sledru - dad86e3e53cd Matthew GreganBug 1134977 - Release IAudioStreamVolume when closing WASAPI stream. Refixes Bug 1109802. r=padenot, a=sledru - 8348e6654b30 Vladan DjericBug 1150230 - Add reading-list.sqlite and about:home indexedDB to SlowSQL whitelist. r=Yoric, a=sledru - 88b4ec69e42f Margaret LeibovicBug 1147597. r=gavin, a=sledru - e4566e5991e8 Joel MaherBug 1139328 - update talos to latest version for preferences and e10s fixes. r=wlach, a=test-only - 0ed266400af5 Nick AlexanderBug 1149226 - Initialize Reading List authority after upgrade. r=rnewman, a=sylvestre - 4d02b020a319 Robert StrongBug 1083653 - Fix intermittent failure for marStageSuccessPartialSvc.js and marStageFailurePartialSvc.js. r=spohl, a=test-only - e2efc8489eba Justin DolskeBug 1142298 - Fix reader view font/color control glitches. r=gijs, a=sledru - c0496dd61e60 Vaibhav Pradeep BhosaleBug 1135009 - Printing in reader mode cuts off on the left (sidebar overlays text). r=Margaret, a=sledru - a1214cc8c57e Markus JaritzBug 1139174 - Use Georgia and Helvetica/Arial as Reader View Fonts until Fira and Charis land. r=margaret, r=dolske, a=sledru - 079e210207b9 Jared WeinBug 1135589 - Make the focusring match the visible borders of the buttons in reader mode. r=florian, a=sledru - fd67405ba1de Margaret LeibovicBug 1147122 - Restore reader view error message if about:reader fails when user clicks reader button. r=Gijs, a=sledru - a2a4bbc864ad Margaret LeibovicBug 1146373 - Don't resize reader view images in JS. r=Gijs, a=sledru - 180f3c3634e3 Blake WintonBug 1147889 - Transition background and text color in Reading Mode. ui-r=mmaslaney, r=Unfocused, a=sledru - 3e828a466ece Mark CapellaBug 1134446 - Automatically open the ReadingList sidebar the first time ReaderMode is used. r=unfocused, a=sledru - 887be7f12f1e vivekBug 1142528 - Decrease tappable area for +/- buttons. r=margaret, a=sledru - 7d883361e554 Blake WintonBug 1145809 - Add the reading mode footer. ui-r=mmaslaney, r=Unfocused, a=sledru - 537b5f078296 Ben TurnerBug 1071360 - Fix async storage connection closing when open fails. r=asuth, a=sledru - 0e9a4f42d12a Ben TurnerBug 1112620 - Fix invalidated version change transactions. r=khuey, a=sledru - f8e17839eac9 Blake WintonBug 1148050 - Make Reader View type panel look closer to the spec. ui-r=mmaslaney, r=Unfocused, a=sledru - 7b6bd63b68e5 Abhinav KoppulaBug 1132656 - Reader mode toolbar overlaps content if window becomes too narrow. r=jaws, a=sledru - b8343ae0a9dc Blake WintonBug 1149277 - Increase the Line-Height in Reader View from 1.44 em to 1.6 em. ui-r=mmaslaney, r=Unfocused, a=sledru - 30be2924717b Jeff MuizelaarBug 1150124 - Move WARP reporter closer to actually testing WARP. r=Bas, a=sledru - e749a39aaf5c Divjot SinghBug 1139026 - Use white background-color & inverted color for selected area. r=margaret, a=sledru - 2ff89ac6dc8d J. Ryan StinnettBug 1149778 - Lazify simulator startup to allow ADB init. r=ochameau, a=sledru - ecf15768ec50 Gijs KruitboschBug 1150476 - Fix silly typo in list styles. a=sledru - 3d380257da88 Tim NguyenBug 1138630 - Switch the desktop update badge to an SVG image. r=Gijs, a=sledru - 33496825c683 Blake WintonBug 1137211 - Move the click handler to the document so we can click on the margins. ui-r=phlsa, r=margaret, r=jaws, a=sledru - d69e01ecebe0 Jared WeinBug 1148462 - When "Reading List" is disabled (browser.readinglist.enabled = false) CTRL+ALT+R should not open its sidebar. r=gijs, a=gavin - 6238a894c78f Jared WeinBug 1146773 - Unify the code paths for adding an item to the reading list (location bar + reader mode). r=margaret, a=sledru - f7d65dc9093b Byron Campen [:bwc]Bug 1147919 - Part 1: Make sure content gets an error callback when it does not use a fingerprint algorithm we support. r=drno, a=sledru - 38cb0f4d54e8 Byron Campen [:bwc]Bug 1147919 - Part 2: Lowercase fingerprint alg before comparing. r=drno, a=sledru - a606f164b2a7 Blake WintonBug 1147440 - Add a transition to the readinglist-addremove-button. ui-r=mmaslaney, r=jaws, a=sledru - 05f716c8608d Blake WintonBug 1147444 - Add a transition when deleting an item from the Reading List. ui-r=mmaslaney, r=Unfocused, a=sledru - b42a539dcc29 Blake WintonBug 1147479 - Add a transition for adding items to the reading list. ui-r=mmaslaney, r=Unfocused, a=sledru - 088cbfb10079 Mike HommeyBug 1147760 - In mozpack.files.FileCopier.copy, remove files after copying. r=gps, a=sledru - 2bc3aac3094b Mike HommeyBug 1147723 - Avoid non TEST_PASS/TEST_UNEXPECTED_FAIL output from r=gps, a=test-only - 882dd82e8af0 Mike HommeyBug 910660 - Refactor so that it's easier to follow. r=gps, a=sledru - a141c675b405 Mike HommeyBug 910660 - Add a test for the unpacker code. r=gps, a=sledru - 06cd1b5deb25 Mike HommeyBug 910660 - Make package formatters handle addons. r=gps, a=sledru - 90925932c88c Mike HommeyBug 910660 - Make the SimplePackager emit a separate base for addons. r=gps, a=sledru - f4f4979e09b2 Ralph GilesBug 1133862 - Remove MSE debug User Agent string. r=mconley, a=sledru - f9441895096d Patrick McManusBug 1141775 - One wifi monitor thread. r=hurley, a=sledru - ce2f9cedb975 Milan SreckovicBug 1149954 - Only Skia canvases need be considered for acceleration. Carry r=jmuizelaar from Bug 1124249, a=sledru - b4e6da60e6d4 Robert KaiserBug 1084258 - Language pack compatibility should be bound to Gecko branch, else undefined entity errors possible. r=glandium, a=sledru - 8c5c12705b50 Cameron McCormackBug 1149542 - Part 1: Return early from SVG text layout if we discover mPositions is not long enough. r=dholbert, a=abillings - 984f9cdef799 Cameron McCormackBug 1149542 - Part 2: Track undisplayed characters before empty text frames properly. r=dholbert, a=abillings - 32d78bac2cfa Jeff MuizelaarBug 1137716 - Increase the list of devices that are blocked. a=sledru - 499e1c563939

Categorieën: Mozilla-nl planet

Mozilla Science Lab: Announcing our global sprint 2015

di, 07/04/2015 - 18:40

Join us as we collaborate on projects helping further science on the open web! We’re back with our second global sprint June 4-5, 2015. We could use your help to make this year’s event bigger and better than last.

Our inaugural sprint last July (#mozsprint, for short) brought together over 100 members of the community, from librarians to developers to bench scientists to hack for two-days on open science projects. Over 22 cities around the world were represented (53 hours of consecutive hacking!), and we need your help to do it again this June.

We’ve just opened our call for project ideas and site host (you’re welcome to sign up for both!):

  1. Project ideas. Anything related to doing or teaching open science is a fit for this sprint. These can be tool-based, open educational resources or any other project ideas that
    a) further open science,
    b) have ways for folks to get involved and make some progress over the course of the sprint and
    c) have someone available to coordinate the work before and at the sprint.
    You can browse our featured projects or see the full list and propose your own on the planning etherpad.
  2. Site hosts. Want to host a sprint site in your city? It could be for 3 people or 30 – you tell us. All you need is to provide a space for people to gather and work, a strong wifi connection, and perhaps some coffee. We’ll help with the rest. The sprint only runs through normal business hours, so no overnight coverage needed. Sign up to host on the planning etherpad

You can read about all of the projects last year here in our wrap up and hear from one of our participants here.

Interested? Head on over to our planning etherpad and add your details, or drop us a note at We hope you’ll come and collaborate with us as we help research thrive on the open web.

Categorieën: Mozilla-nl planet

Laura Hilliger: Open Fluency

di, 07/04/2015 - 16:39


webliteracy-lens-open-fluency I’ve been thinking about lenses on the Web Literacy Map again. Specifically the “Leadership” component of what we do at Mozilla. In his post, Mark called this piece fuzzy, but I think it will become clearer as we define what “leadership” in the context of Mozilla means, and how we can offer professional development that brings people closer to that definition. What does it mean to be “trained” by Mozilla? Or be part of Mozilla’s educational network? What do the leaders and passionate people in our community have in common? What makes them sustainable? What do we need to cognitively understand? What behaviors do we need to model? How do we unite with one another locally and globally? I have some theories on specific competencies a leader needs to be considered “fluent” in open source and participatory learning. I’ve indicated possibilities in the above graphic [edit note: the smaller text are just notes of topics that might be contained under the competencies). The Web Literacy Map Doug Belshaw and the Mozilla community created is extremely relevant in this work, which is why this post is using the word “fluency” – to indicate the relationship between the map and this lens on it. It feels like leadership in our context requires fluency in specific competencies - the highlighted ones on the web literacy map above. There is a lot of content for professional development around teaching Web Literacy. I’m working on collecting resources for an upcoming conceptual and complete remix of what was Webmaker Training (and before that the original Teach the Web MOOC). Last week in a team call, we talked about my first attempt to use blunt force in getting the Web Literacy Map to cover skills and competencies I think are part of the “Teach Like Mozilla” offering at Mozilla. I made the below graphic, trying to work out the stuff in my brain (it helps me think when I can SEE things), and I immediately knew I was forcing a square peg into a round hole. I’m including it so you can see the evolution of the thinking behind the above graphic: webliteracy-lens-TLM I’d love to hear thoughts on this approach to placing a lens on the Web Literacy Map. Please ask questions, push back, give feedback to this thinking-in-progress.
Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

di, 07/04/2015 - 09:17

the following changes have been pushed to

  • [1118365] Write extension to use GitHub for Authentication
  • [1150965] “Due Date” field for the Mozilla Metrics queue
  • [1151592] Typo on custom recruiting form
  • [1149879] bug-modal’s editmode is broken for users without editbugs (Form field dup_id was not defined)
  • [1146960] replace the version number on bmo with a build number
  • [1149796] “Reset Assignee to default” and “Reset QA Contact to default” options missing when changing a bug’s component
  • [1149438] keyboard shortcut (hotkey) for “Edit” button
  • [1146760] cannot add other people to the cc list
  • [1150074] when a person blocks needinfo? requests, it prevents comments on a bug when there is an existing ni? request

discuss these changes on

Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Andy McKay: Bill C51

di, 07/04/2015 - 09:00

Today Prime Minister Stephen Harper appeared at a school about 5 doors away from my house. We found this out on Easter Sunday when the school sent out a phone call to parents telling them, who then told us that he'd appear on Tuesday morning at the school.

We all immediately jumped at the opportunity to protest. Most people at the Enbridge and Kinder-Morgan pipeline expansions. Myself at Bill C51.

As Tuesday morning came around, I had a few meetings to polish off which meant I missed the start. Apparently upon seeing protestors, Stephen Harper went around the back and came in through a back path to avoid them. I came along later to find I wasn't the only one there. The protestors had split up between the main entrance and the back entrance.

Most of the protestors were there about oil, I was about that Bill C51. I felt pretty good turning up in my Mozilla t-shirt knowing that Mozilla cares about this sort of thing.

I was encouraged to find a bunch of people protesting Bill C51, which made me feel good about not bringing a sign since I could stand near them. I found it a little uncomfortable because there was one chap with a loud speaker who was being a bit vocal about his opinions which I didn't all agree with. I'm very bad at following crowds in chants.

This was a pretty big deal for Deep Cove, with RCMP plains clothes officers lurking in bushes and lots of other police around in flak jackets.

It seemed Harper spoke in front of a bunch of bored students and people in hard hats. Those people in hard hats got bussed in and out, they had nothing to do with the school. They just seemed to be excited to be on television with Harper.

For those unwaware bill C51 is a terrible bill that expands the agencies abilities to monitor Canadians with no oversight. The Mozilla blog sums this up well:

Meanwhile in Canada, the Canadian Parliament is considering an even more concerning bill, C-51, the Anti-Terrorism Act of 2015. C-51 is sweeping in scope, including granting Canadian intelligence agencies CSIS and CSE new authority for offensive online attacks, as well as allowing these agencies to obtain significant amounts of information held by the Canadian government. The open-ended internal information-sharing exceptions contained in the bill erode the relationship between individuals and their government by removing the compartmentalization that allows Canadians to provide the government some of their most private information (for census, tax compliance, health services, and a range of other purposes) and trust that that information will be used for only its original purposes. This compartmentalization, currently a requirement of the Privacy Act, will not exist after Bill C-51 comes into force.

The Bill further empowers CSIS to take unspecified and open-ended “measures,” which may include the overt takedown of websites, attacks on Internet infrastructure, introduction of malware, and more all without any judicial oversight. These kinds of attacks on the integrity and availability of the Web make us all less secure.


After a while it became clear he'd gone in one of the unmarked blacked out cars and that was that. People wandered off, I got back to work after spending just 30 mins on the protest.

In the end it was mentioned on the news the protestors turned up, so that felt cool. Although a lot of talk is about how Stephen Harper is at the other end of the country from the Mike Duffy trial. Very convenient.

Amsuingly I realised that to sneak into the school Stephen Harper had to walk down a path that I walk regularly with my dog. I always clean up my dogs poo, but I know other people don't on that path. Perhaps he stood in some.

Categorieën: Mozilla-nl planet

Raniere Silva: Hacking Gecko or 1011020

di, 07/04/2015 - 05:00
Hacking Gecko or 1011020

For some time now I want to be able to contribute to native support of MathML at Gecko but

  1. I only know C (not C++),
  2. I only program command line interfaces (not graphical user interface),
  3. I never program a “graphical framework”, ...

Frédéric recommended that I start with Bug 1011020 because shouldn’t be very hard to fix this bug. So I decided to give it a try.

Leia mais...

Categorieën: Mozilla-nl planet

Mike Hommey: Announcing git-cinnabar 0.2.0

di, 07/04/2015 - 04:18

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

What’s new since 0.1.1?
  • git cinnabar git2hg and git cinnabar hg2git commands that allow to translate (possibly abbreviated) git sha1s to mercurial sha1s and vice-versa.
  • A “native” helper that makes some operations faster. It is not required for git-cinnabar to work, but it can improve performance significantly. Check the Setup instructions in the README file.
  • Do not store mercurial metadata when pushing to non-publishing repositories. For Mozilla developers, this means not storing that metadata when pushing to try, which is a good thing when you know each of them makes pulling slower. This behavior can be changed if necessary. Future releases will allow to remove metadata that was created by previous releases but that wouldn’t be created with 0.2.0.
  • Made the discovery phase of pushes require less round trips (the phase that finds what is common between the local and remote repositories), hopefully making pushing faster.
  • Improved logging, which now doesn’t require fiddling with the code to get extra logging.
  • Made fsck validate more things, and act on more errors.
  • Fixed a few edge cases.
  • Better handle files with weird names, and that git quotes in its output.
  • Extensively tested on the following repositories: mozilla-central, mozilla-beta, mercurial, hg-git, cpython.
What to expect next?
  • Allow to push merge commits.
  • Improve memory footprint for pushes (currently, it’s fairly catastrophic on big repositories ; don’t try to push multiple hundreds of commits of a Mozilla-sized repository if you don’t have multiple gigabytes of memory available).
  • As mentioned above, allow to remove some metadata.
  • And more…

If you want to follow the improvements more closely, I encourage you to switch to the `next` branch. I won’t push anything there that hasn’t been extensively tested on the above mentioned repositories.

And as always, please report any issue you run into.

Categorieën: Mozilla-nl planet

Justin Wood: Find our footing on python best practices, of yesteryear.

di, 07/04/2015 - 03:52

In the beginning there was fire buildbot. This was Wed, 13 Feb 2008 for the first commit in the repository buildbot-configs.

For context, at this time:

Chief electronics engineer Kevin Sheridan receiving data in the makeshift Dapto radiospectrograph room

(CC BY-SA 3.0) via wikipedia

In picking buildbot as our tool we were improving vastly on the decade old technology we had at the time (tinderbox) which was also written in oft-confusing and not-as-shiny perl (we love to hate it now, but it was a good language) [see relevant: image of then-new cutting edge technology but strung together in clunky ways]

As such, we at Mozilla Release Engineering, while just starting to realize the benefits of CI for tests in our main products (like Firefox), were not accustomed to it.

We were writing our buildbot-related code in 3 main repositories at the time (buildbot-configs, buildbotcustom, and tools) all of which we still use today.

Fast forward 5 years and you would have seen a some common antipatterns in large codebases… (over 203k lines of code! )  It was hard to even read most code, let alone hack on it. Each patch was requiring lots of headspace. And we would consistently break things with patches that were not well tested. (even when we tried)

It was at a workweek here in 2013 that catlee got our group agreement on trying to improve that situation by continually running autopep8 over the codebase until there was no (or few) changes with each pass.

Thus began our first, attempt, at bringing our processes to what we call our modern practices.

This reduced, in buildbotcustom and tools alone our pep8 error rate from ~7,139 to ~1,999. (In contrast our current rate for those two repos is ~1485).

(NOTE: This is a good contributor piece, to drive pep8 errors/warnings down to 0 for any of our repos, such as these. We can then make our current tests fail if pep8 fails. Though newer repos started with pep8 compliance, older ones did not. See List of Repositories to pick some if you want to try. — Its not glorious work, but makes everyone more productive once its done.)

The one agreement we decided where pep8 wasn’t for us was line length, we have had many cases where a single line (or even url) barely fits in 80 characters for legit reasons, and felt that arbitrarily limiting variable names or depth just to satisfy that restriction was going to reduce readability. Therefore we generally use –max-line-length of ~159 when validating against pep8.  (The above numbers do not account for –max-line-length)

Around this time we had also setup an internal only jenkins instance as a test for validating at least pep8 and its trends, we have since found jenkins to not be suitable for what we wanted.

Stay tuned to this blog for more history and how we arrived at some best practices that most don’t take for granted these days.

Categorieën: Mozilla-nl planet

James Long: Stop Trying to Catch Me

di, 07/04/2015 - 02:00

I'm probably going to regret this, but this post is about promises. There are a few details that I'd like to spell out so I can point people to this post instead of repeating myself. This is not a hyperbolic post like Radical Statements about the Mobile Web, which I sort of regret posting. In that post I was just yelling from a mountaintop, which isn't very helpful.

I humbly submit these points as reasons why I don't like promises, with full realization that the ship has sailed and nothing is going to change.

First, let's talk about try/catch. The problem with exception handling in JavaScript is that it's too aggresive. Consider the following code:

try { var result = foo(getValue()); } catch(e) { // handle error from `foo` }

We've accidentally captured the getValue() expression within this handler, so any error within getValue is captured. This is how exceptions work, of course, but it's made worse in JavaScript because a simple typo becomes an exception.

Exceptions are meant to be just that, exceptional. In most other languages, many typo-style errors are caught at compile-time, even in dynamic languages like Clojure. But in JavaScript, with the above code, if I was happily hacking away within getValue and I typed fucn() instead of func(), it gets caught and treated as an exception here.

I don't like how easy it is to get tripped up try/catch. We could turn the above code into this:

try { var result = foo(getValue()); } catch(e) { if(e instanceof FooError) { // handle error from `foo` return; } throw e; }

Not only is this a ton of boilerplate, but it breaks an important feature of JavaScript debuggers: break on exception. If you have break on exception enabled, and you make an error inside getValue, it now pauses on the throw in the above code instead of inside getValue where you actually made the mistake.

So it's crazy to me that promises want to apply this behavior to async code and wrap everything in a try/catch. Break on exception is permanently broken now, and we have to go through all sorts of contortions and backflips to get back to reasonable debugging environment. All because it wraps code in try/catch by default.

I don't care about awkward .then() syntax. I don't mind automatic error propagation. I don't care having to call .done() on a promise chain. I don't care about losing the stack (which is inherent in any async work).

I care that promises grab all errors, just like try/catch. The cost of a simple typo is greatly magnified. When you do async work in most other systems, you deal with errors pertaining to your async call. If I make an HTTP request, I want the network error to automatically bubble up the promise chain. I don't want anything unrelated to the async work to bubble up. I don't care about it.

I should be able to reject a promise with an error, and it bubbles up. But I want to make stupid typo errors and have them appear as normal errors, not caught by promises. Don't run everything in try/catch.

Oh, and about async/await

ES7 proposes async functions for doing async work. A lot of people are extremely excited about it, and honestly I don't get the excitement. Async functions are only pretty generators with promises:

var asyncFunction = Task(function*() { var result = yield fetch(url); return process(result); }):

fetch returns a promise. With async functions, it would look like this:

async function asyncFunction() { var result = await fetch(url); return process(result); }

Ok, so that is nicer, and asyncFunction is hoisted (I think) like a normal function would be. It's cool, I just don't understand why everyone is so excited about a simple syntactic improvement.

Especially when we still have all the problems with promises. For example, some top-level promise code now looks like:

async function run() { console.log(await asyncFunction()); } run();

A newbie to JavaScript will write that code, and be totally bewildered when nothing happens. They have no idea that they made a typo in asyncFunction, and it takes them a while to learn that run actually returns a promise.

Here a few ideas I have:

  1. Allow run to mark itself as a top-level function somehow that automatically throws errors
  2. Now that we have #1, when an error happens inside a promise, the JS engine check the promise chain to see if the error should immediately throw or not. It should immediately throw (as a normal error) if there is a top-level async function at the beginning of the promise chain.

Ok, so that's really just one idea. Native async/await syntax could potentitally help here, if we are willing to think outside of promises.

You're Writing An Angry Tweet Right Now, Aren't You?

We are discussing error handling within the js-csp project, which implements go-style channels. Most likely we are going to propogate errors, but only ones that comes down channels. I've been trying this out for a while and I love it.

I'm not going to spend time here convincing you to use js-csp, I just wanted to offer a solution instead of just complaining.

Hopefully I explained this well. I don't expect anything to change. I think my idea about async/await is pretty cool, so I hope someone looks into it.

Categorieën: Mozilla-nl planet

Anthony Hughes: Ninety Days with DOM

di, 07/04/2015 - 00:35

Last quarter marked a fairly significant change in my career at Mozilla. I spent most of the quarter adjusting to multiple re-orgs which left me as the sole QA engineer on the DOM team. Fortunately, as the quarter wraps up I feel like I’ve begun to adjust to my new role and started to make an impact.

Engineering Impact

My main objective this quarter was to improve the flow of DOM bugs in Bugzilla by developing and documenting some QA processes. A big part of that work was determining how I was going to measure impact, and so I decided the most simple way to do that was to take the queries I was going to be working with and plot the data into Google docs.

The solution was fairly primitive and lacked the ability to feed into a dashboard in any meaningful way, but as a proof of concept it was good enough. I established a baseline using the week-by-week numbers going back a couple of years. What follows is a crude representation of these figures and how the first quarter of 2015 compares to the now three years of history I’ve recorded.

Volume of unresolved Regressions & Crashes
dom.regressions-vs-crashes.unresolved.alltime.2015q1Regressions +55%, Crashes +188% since 2012

Year-over-Year trend in Regressions and Crashes
dom.regressions-vs-crashes.unresolved.annual.2015q1Regressions +9%, Crashes +68% compared to same time last year.

Regressions and Crashes in First Quarters
dom.regressions-vs-crashes.unresolved.quarterly.2015q1Regressions -0.6%, Crashes +19% compared to previous 1st Quarters

Resolution Rate of Regressions and Crashes
dom.regressions-vs-crashes.fixrate.2015q190% of Regressions resolved (+2.5%), 80% of Crashes resolved (-7.0%)

Change in Resolution Rate compared to total Volume
dom.regressions-vs-crashes.volume.2015q1Regression resolution +2.5%, Crash resolution -6.9%, Total volume +68%

I know that’s a lot of data to digest but I believe they show embedding QA with the DOM team is having some initial success.

It’s important to acknowledge the DOM team for maintaining a very high resolution rate (90% for regressions, 80% for crashes) in the face of aggressive gains in total bug volume (68% in three years). They have done this largely on their own with minimal assistance from QA over the years, giving us a solid foundation from which we could build.

For DOM regressions I focused on making existing bug reports actionable with less focus on filing new regression bugs; this has been a two part effort. The first being focused on finding regression windows for known regression bugs, the second being focused on converting unconfirmed bugs into actionable regression reports. I believe this is why we see a marginal increase in the regression resolution rate (+0.4% last quarter).

For DOM crashes I focused on filing previously unreported crashes (basically anything above a 1% report threshold). Naturally this has led to an increase in reports but has also led to some crashes being fixed that wouldn’t have been otherwise. Overall the crash resolution rate declined by 2.6% last quarter but I believe this should ultimately lead to a more stable product in the future.

The Older Gets Older

The final chart below plots the age of unresolved DOM bugs week over week which currently sits at 542 days; an increase of 4.8% this past quarter and 241% since January 1, 2012. I include it here not as a visualization of impact but as a general curiosity.

Median Age of Unresolved DOM Bugs
dom.regressions-vs-crashes.fixrate.2015q1Median age is 542 days, +4.8% last quarter, +241% since 2012

I have not yet figured out what this means in terms of overall quality or whether it’s something we need to address. I suspect recently reported bugs tend to get fixed sooner since they tend to be more immediately visible than older bugs. A fact that is likely common to most, if not all components in Bugzilla. It might be interesting to see how this breaks down in terms of the age of the bugs being fixed.

What’s Next

My plan for the second quarter is to identify a subset of these to take outside of Google Docs and convert into a proof of concept dashboard. I’m hoping my peers on the DOM team can help me identify at least a couple that would be both interesting and useful. If it works out, I’d like to aim for expanding this to more Bugzilla components later in the year so more people can benefit.

If you share my interest and have any insights please leave a comment below.

As always, thank you for reading.

[UPDATE: I decided to quickly mock up a chart showing the age breakdown of bugs fixed this past quarter. As you can see below, younger bugs account for a much greater proportion of the bugs being fixed, perhaps expectedly.]

Screen Shot 2015-04-06 at 3.56.33 PM

Categorieën: Mozilla-nl planet

Niko Matsakis: Modeling graphs in Rust using vector indices

ma, 06/04/2015 - 20:58

After reading nrc’s blog post about graphs, I felt inspired to write up an alternative way to code graphs in Rust, based on vectors and indicates. This encoding has certain advantages over using Rc and RefCell; in particular, I think it’s a closer fit to Rust’s ownership model. (Of course, it has disadvantages too.)

I’m going to describe a simplified version of the strategy that rustc uses internally. The actual code in Rustc is written in a somewhat dated “Rust dialect”. I’ve also put the sources to this blog post in their own GitHub repository. At some point, presumably when I come up with a snazzy name, I’ll probably put an extended version of this library up on Anyway, the code I cover in this blog post is pared down to the bare essentials, and so it doesn’t support (e.g.) enumerating incoming edges to a node, or attach arbitrary data to nodes/edges, etc. It would be easy to extend it to support that sort of thing, however.

The high-level idea

The high-level idea is that we will represent a “pointer” to a node or edge using an index. A graph consists of a vector of nodes and a vector of edges (much like the mathematical description G=(V,E) that you often see):

1 2 3 4 pub struct Graph { nodes: Vec<NodeData>, edges: Vec<EdgeData>, }

Each node is identified by an index. In this version, indices are just plain usize values. In the real code, I prefer a struct wrapper just to give a bit more type safety.

1 2 3 4 5 pub type NodeIndex = usize; pub struct NodeData { first_outgoing_edge: Option<EdgeIndex>, }

Each node just contains an optional edge index, which is the start of a linked list of outgoing edges. Each edge is described by the following structure:

1 2 3 4 5 6 pub type EdgeIndex = usize; pub struct EdgeData { target: NodeIndex, next_outgoing_edge: Option<EdgeIndex> }

As you can see, an edge contains a target node index and an optional index for the next outgoing edge. All edges in a particular linked list share the same source, which is implicit. Thus there is a linked list of outgoing edges for each node that begins in the node data for the source and is threaded through each of the edge datas.

The entire structure is shown in this diagram, which depicts a simple example graph and the various data structures. Node indices are indicated by a number like N3 and edge indices by a number like E2. The fields of each NodeData and EdgeData are shown.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Graph: N0 ---E0---> N1 ---E1---> 2 | ^ E2 | | | v | N3 ----------E3-----------+ Nodes (NodeData): N0 { Some(E0) } N1 { Some(E1) } N2 { None } N3 { Some(E2) } Edges: E0 { N1, Some(E2) } E1 { N2, None } E2 { N3, None } E3 { N2, None } Growing the graph

Writing methods to grow the graph is pretty straightforward. For example, here is the routine to add a new node:

1 2 3 4 5 6 7 impl Graph { pub fn add_node(&mut self) -> NodeIndex { let index = self.nodes.len(); self.nodes.push(NodeData { first_outgoing_edge: None }); index } }

This routine will add an edge between two nodes (for simplicity, we don’t bother to check for duplicates):

1 2 3 4 5 6 7 8 9 10 11 impl Graph { pub fn add_edge(&mut self, source: NodeIndex, target: NodeIndex) { let edge_index = self.edges.len(); let node_data = &mut self.nodes[source]; self.edges.push(EdgeData { target: target, next_outgoing_edge: node_data.first_outgoing_edge }); node_data.first_outgoing_edge = index; } }

Finally, we can write an iterator to enumerate the successors of a given node, which just walks down the linked list:

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 impl Graph { pub fn successors(&self, source: NodeIndex) -> Successors { let first_outgoing_edge = self.nodes[source].first_outgoing_edge; Successors { graph: self, current_edge_index: first_outgoing_edge } } } pub struct Successors<'graph> { graph: &'graph Graph, current_edge_index: Option<EdgeIndex>, } impl<'graph> Iterator for Successors<'graph> { type Item = NodeIndex; fn next(&mut self) -> Option<NodeIndex> { match self.current_edge_index { None => None, Some(edge_num) => { let edge = &self.graph.edges[edge_num]; self.current_edge_index = edge.next_outgoing_edge; Some( } } } } Advantages

This approach plays very well to Rust’s strengths. This is because, unlike an Rc pointer, an index alone is not enough to mutate the graph: you must use one of the &mut self methods in the graph. This means that can track the mutability of the graph as a whole in the same way that it tracks the mutability of any other data structure.

As a consequence, graphs implemented this way can easily be sent between threads and used in data-parallel code (any graph shared across multiple threads will be temporarily frozen while the threads are active). Similarly, you are statically prevented from modifying the graph while iterating over it, which is often desirable. If we were to use Rc nodes with RefCell, this would not be possible – we’d need locks, which feels like overkill.

Another advantage of this apprach over the Rc approach is efficiency: the overall data structure is very compact. There is no need for a separate allocation for every node, for example (since they are just pushes into a vector, additions to the graph are O(1), amortized). In fact, many C libaries that manipulate graphs also use indices, for this very reason.


The primary disadvantage comes about if you try to remove things from the graph. The problem then is that you must make a choice: either you reuse the node/edge indices, perhaps by keeping a free list, or else you leave a placeholder. The former approach leaves you vulnerable to “dangling indices”, and the latter is a kind of leak. This is basically exactly analogous to malloc/free. Another similar problem arises if you use the index from one graph with another graph (you can mitigate that with fancy type tricks, but in my experience it’s not really worth the trouble).

However, there are some important qualifiers here:

  • It frequently happens that you don’t have to remove nodes or edges from the graph. Often you just want to build up a graph and use it for some analysis and then throw it away. In this case the danger is much, much less.
  • The danger of a “dangling index” is much less than a traditional dangling pointer. For example, it can’t cause memory unsafety.

Basically I find that this is a theoretical problem but for many use cases, it’s not a practical one.

The big exception would be if a long-lived graph is the heart of your application. In that case, I’d probably go with a Rc (or maybe Arc) based approach, or perhaps even a hybrid – that is, use indices as I’ve shown here, but reference count the indices too. This would preserve the data-parallel advantages.


The key insights in this approach are:

  • indices are often a compact and convenient way to represent complex data structures;
  • they play well with multithreaded code and with ownership;
  • but they also carry some risks, particularly for long-lived data structures, where there is an increased change of indices being misused between data structures or leaked.
Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting

ma, 06/04/2015 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Mozilla Science Lab: Mozilla Science Lab Week in Review, March 30 – April 5

ma, 06/04/2015 - 17:00

The Week in Review is our weekly roundup of what’s new in open science from the past week. If you have news or announcements you’d like passed on to the community, be sure to share on Twitter with @mozillascience and @billdoesphysics, or join our mailing list and get in touch there.

Conferences & Meetings
  • Submissions for talks and posters at SciPy 2015 are closing on April 10. The conference itself will be in Austin, Texas, July 6-12; check out the details here.
  •  Amye Kenall summarized the recent meeting of leaders & thinkers in the open science community, hosted late last month at the Center for Open Science. In her blog post, Kenall touches on projects the group agreed looking ahead, including articulating standards for open data APIs, providing guidance through the constellation of data and code training programs available, and better outlining the incentives for open practices.
  • The Advancing Research Communication & Scholarship conference is coming up on April 26-28 in Philadelphia; from their website, ‘ARCS is a new conference focused on the evolving and increasingly complex scholarly communication network.‘ Conference organizers are offering students and early career researchers scholarships for attendance and lodging.
  • The next Mozilla Science Lab Community Call is this Thursday, April 9. We’ll be hearing from several speakers on the topic of publishing negative results.
On the Blogs Lessons & Teaching
  • Nancy Soontiens wrote a lesson on mapping in Python using Basemap. Soontiens recently delivered this lesson at UBC’s Earth & Ocean Science Study Group, and posted her notes at the growing Mozilla Science Lab Study Group Lesson repo.
  • Megan O’donell & Emma Molls from Iowa State University Library published a slide deck entitled ‘What is Open? A Primer for Early Career Researchers’. In it, O’donnell and Molls give a first introduction to the concepts of open access publishing, and how open access affects research & self-promotion in the sciences.
Categorieën: Mozilla-nl planet