Mozilla Nederland Logo De Nederlandse Mozilla gemeenschap


  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2014 of /home/mzilla2013/domains/
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 2024 of /home/mzilla2013/domains/

Will Kahn-Greene: Site development using pagekite

Mozilla planet - wo, 09/04/2014 - 12:00

I have this basic problem where I do a lot of web-site work and I need to show people what I've done so far so they can review it and help me make it better or make it suit their needs better. Screenshots aren't very helpful because the site is interactive. Further, the site needs to get tested on multiple devices/platforms/browsers. Also, I need to make sure that the site is only accessed via https.

What I've been doing up to now is failing miserably: I'd push work to our staging server for people to test out, but that sucks as an answer and affects my co-workers and makes a mess of our staging server. Plus iterating on things is difficult.

So, requirements:

  1. endpoint must be https-only
  2. must be easy to set up and take down
  3. must be easy to access so people can easily test things on my local machine

I looked around and this would be pretty easy to do if I didn't have the https-only requirement. That makes things difficult without a lot of work.

Then I found pagekite. They make it really easy.

Here's how you set it up:

  1. Download and install the pagekite software:

  2. Run your website. In my case, I'm working on Django sites, so I launch like this:

    $ ./ runserver

    That runs the Django project I'm working on on localhost:8000.

  3. Run pagekite:

    $ 8000

    That creates a tunnel from your machine to the server. When someone accesses, the request goes through the tunnel to your pagekite backend and that performs the request over http to your local webserver (in my case, the Django project) bound to localhost:8000.

    Access is https-only. If anyone tries to access, then they get a connection error.

    The https-only requirement is satisfied by restricting the kite to only listening to port 443--the https port. That's pretty key.

This lets me run my Django project locally on http without dealing with self-signed certificates, but still require https access so data isn't floating around in clear text.

The one problem with this is that my local server thinks it's running http and so redirects that include the protocol go to http rather than https.

If you don't already have an account, I'm pretty sure step 3 will walk you through setting one up. Free accounts are limited in what they can do.

Also, they hang out on #pagekite on Freenode. I had a problem, asked a question and got a super helpful reply. The code is Open Source, so it's possible to look through it and debug it.

I'll be using this going forward.

Why write this?

This is a common use case for web developers. I figured I'd write this up because the https-only part is pretty key and it was the part that I had to ask for help with.

Categorieën: Mozilla-nl planet

Kumar McMillan: How To Protect Against Heartbleed And Other Vulnerabilities

Mozilla planet - wo, 09/04/2014 - 07:01

The OpenSSL heartbleed bug was a serious kick to the Internet's collective ass. This video provides a quick overview if you want the details. In summary, an attacker could craft a payload with a fake size (up to 64k) and trick openssl into sending a random chunk of server memory. WTF?! To understand how bad this was I spent a minute hacking on this script that was going around. I pointed it at (which is no longer vulnerable) and tried to see if I could catch a username and password flying by. I had one within 30 seconds. That's how bad it was; you could read random parts of the server's memory which may contain passwords, private keys, or whatever else OpenSSL was processing for current site visitors.

I had stolen someone's credentials. Game over, right? How do you protect yourself against something as bad as this? ...

[read entire article]

Categorieën: Mozilla-nl planet

Kumar McMillan: Ramblings

Mozilla planet - wo, 09/04/2014 - 05:15

Oh, hey! I almost forgot I have a blog. Well, the colors are annoying to me and my comment system sucks but, meh. I wanted to write a quick note about where you can find stuff I write.

Categorieën: Mozilla-nl planet

Carla Casilli: Open Badges, wicked problems, and that thing called hope

Mozilla planet - wo, 09/04/2014 - 00:37
"feather bad weather" by Erik bij de Vaate

“feather bad weather” ©2008 Erik bij de Vaate, used under CC-BY-SA

Open badges: they are so tantalizing to so many people, so full of possibility. They appear to offer so many solutions to so many different problems. They encourage us to look at old problems with new eyes. And precisely because of their dynamism, their precious novelty, we occasionally find ourselves overwhelmed with the hope that they’ll solve all of the problems. Everything.

This, my friends, this is precisely what’s at issue with introducing badges to our current social structure: recognizing that there are problems with existing acknowledgement and recognition systems. Problems that have not been adequately addressed. We need to crack that nut wide open as we begin to figure out how badges might change the game. We need to figure out what works and what’s worth saving in this new badge world. We need to look hard at the wicked problems that they might at least influence.

The issues most often raised about badges—accessibility, injustice, value, meaning, and rigor—are not necessarily about badges themselves but instead are rooted in wicked problems, the larger systemic social, political, and economic issues that surround learning and recognition. When viewed from this perspective, it’s obvious that badges are not a panacea. So, let’s be realistic in our discussions about the ability of badges to solve all issues of access, fairness, and equity: nothing so far has solved those issues and badges alone won’t do it, either. This is a known known; let’s not waste time arguing this point. Instead, let’s wrestle mightily with the all-too-familiar feeling of impotence when discussing any possible inroad to wicked problems. Because discuss them we must.

On the plus side of this discussion, here’s a tiny sample of what badges can do. They can provide markers of social and professional possibilities, they can acknowledge varying degrees of expertise in social skills, they can indicate job skills compatibility, they can evidence a variety of important learning experiences including capturing prior learning, they can demonstrate continued professional engagement, they can represent vastly different company and brand values, and perhaps most importantly, they can provide important and meaningful personal insight.

So for now, while we’re building this ecosystem together, let’s hold tight to that thing with feathers—our sense of hope, our sense of possibility—for when seeking change, particularly systemic change, odd though it may feel and sound to outsiders, optimism is a feature not a bug.


If you’re reading this and nodding your head, you might also appreciate this related post from Badge Alliance Executive Director, Erin Knight: More Beefs

Much more soon. carla [at] badgealliance [dot] org


Tagged: badges, identity, learning, mozilla, Open badges, openbadges, politics, tools, wicked problems
Categorieën: Mozilla-nl planet

Sylvestre Ledru: Changes Firefox 29 beta5 to beta6

Mozilla planet - ti, 08/04/2014 - 22:52

The number of changeset has decreased (23 for beta6 compared to 43 for beta5). This is a good sign as we approach from the release date of 29. In this release, some top crashes have been fixed and some last bugs for Australis has been address.

  • 23 changesets
  • 55 files changed
  • 435 insertions
  • 704 deletions

By extensions:

ExtensionOccurrences cpp12 js10 css8 h7 ini6 html4 mm2 xul1 xml1 json1 jsm1 inc1

By modules:

ModuleOccurrences browser19 js13 dom6 widget5 content5 toolkit2 gfx2 modules1 layout1

List of changesets:

Tim NguyenBug 989449 - fix menu-button dropmarker corners to have border-radii on Windows 7, Vista and XP. r=mikedeboer, a=sylvestre. - bc6c34299b03 Tim NguyenBug 980339 - Remove border-radius from add-on manager on Windows 8. r=mikedeboer, sr=Unfocused, a=sylvestre. - cb7f81834560 Mike de BoerBug 991072: fix zoom percentage label to be centered in any toolbar. r=mconley, a=sylvestre. - 3e69377c027a Gijs KruitboschBug 946595 - High contrast themes on Windows 8 shouldn't be considered the default theme in CSS, r=jimm, a=sylvestre. - 250d63775815 Boris ZbarskyBug 976920 - Mostly back out Bug 932322 for now; only define the unforgeable properties on the window object itself. r=jst, a=sledru - aecbb562466a Robert StrongBug 982448 - Some fxmetro pref's still being left behind with values without --enable-metro in the mozconfig. r=bbondy, a=sledru - 6f0ad6b259ca Jan de MooijBug 983709 - Simple branch patch for uplift. r=hv1989, a=sledru - 81285325c7db Jon CoppeardBug 986864. r=sfink, a=sledru - e6b88dfe88cd Phil RingnaldaBug 986760 (with a dash of 989101 added in) - disable browser_UITour3.js on Linux for excessive failures and lack of action taken toward fixing them. a=test-only - 6c1da25749a0 Matthew NoorenbergheBug 990384 - Define tabToolbarNavbarOverlap to reduce magic numbers in CSS for the overlap between the tabs and nav-bar. r=mconley a=sylvestre - a2fccb7d55f7 Matthew NoorenbergheBug 878436 - Update Lion Fullscreen window styling offsets to avoid themes shifting position. r=timdream a=sylvestre - 4d27870d3fdc Matthew NoorenbergheBug 990387 - Toolbar buttons on the TabsToolbar appear below the nav-bar border with a theme. r=dao a=sylvestre - 81075b35ee13 Matthew NoorenbergheBug 973855 - [Australis] Include browser-bottombox in the customization mode padding. r=jaws a=sylvestre - 75c7e2c98e0c Jan BeichBug 948946 - Use private-browsing indicator with GTK theme on non-Linux as well. r=MattN a=sylvestre - f7faeaf19dfa John DaggettBug 975460 - disable async font loader on OSX 10.6 (beta/aurora). r=smichaud,mkato a=sylvestre - 79c61c6f632d Joel MaherBug 987892 - Clear up oranges for deBug mochitest-browser-chrome jobs on Mozilla-Beta. r=armenzg a=test-only - 13bf6fe8df1f Benjamin BouvierBug 969203 - Take out non strictly commutative Float32 functions. r=sstangl, a=sledru - 7e9b33204db9 Bobby HolleyBug 980537 - Only store FakeBackstagePass instances in mThisObjects. r=khuey, a=sledru - 9933fa36efa5 Mike KaplyBacking out Bug 889085 (dddfd63f1414, f8c14bd80676) due to regression Bug 987783. r=roc, a=sledru - 51e5b0ec21b3 Garrett RobinsonBug 971341 - Fix infinite tab loading due to missing characters in CSP's path regexes. r=sstamm, a=lsblakk - fe5d67aa5366 Shane CaraveoBug 992398 - Fix domain for cdn deployment of directory site. r=gavin, a=sledru - ea5b3027bb42 Karl TomlinsonBug 990794 - Crash on ovrfl in SharedBuffer::Create(). r=roc, a=sledru - 51a84afe085d Karl TomlinsonBug 990794 - Crash on ovrfl in AllocateAudioBlock. r=roc, a=sledru - 004a7c15d761

r= means reviewed by
a= means uplift approved by

Previous changelogs:

Original post blogged on b2evolution.

Categorieën: Mozilla-nl planet

Joel Maher: polishing browser-chrome – coming to a branch near you soon

Mozilla planet - ti, 08/04/2014 - 21:54

The last 2 weeks I have gone head first into a world of resolving some issues with our mochitest browser-chrome tests with RyanVM, Armen, and the help of Gavin and many developers who are fixing problems left and right.

There are 3 projects I have been focusing on:

1) Moving our Linux debug browser chrome tests off our old fedora slaves in a datacenter and running them on ec2 slave instances, in bug 987892.

These are live and green on all Firefox 29, 30, and 31 trees!  More work is needed for Firefox-28 and ESR-24 which should be wrapped up this week.  Next week we can stop running all linux unittests on fedora slaves.

2) Splitting all the developer tools tests out of the browser-chrome suite into their own suite in bug 984930.

browser-chrome tests have been a thorn in the side of the sheriff team for many months.  More and more the rapidly growing features and tests of developer tools have been causing the entire browser-chrome suite to fail, in cases of debug to run for hours.  Splitting this out gives us a small shield of isolation.  In fact, we have this running well on Cedar, we are pushing hard to have this rolled out to our production and development branches by the end of this week!

3) Splitting the remaining browser chrome tests into 3 chunks, in bug 819963.

Just like the developer tools, we have been running browser-chrome in 3 chunks on Cedar.  With just 7 tests disabled, we are very green and consistently green. 



While there are a lot of other changes going on under the hood, what will be seen by next week on your favorite branch of Firefox will be:

  • ‘dt’ jobs for opt, and ‘dt1′, ‘dt2′, ‘dt3′ jobs for debug
  • ‘bc’ job will turn into ‘bc1′, ‘bc2′, ‘bc3′
  • much faster turnaround times on bc tests (62 minutes is the slowest right now, the rest are averaging ~20 minutes/job)
  • less random orange cluttering up results


Categorieën: Mozilla-nl planet

Staś Małolepszy: Refactored l10n.js landed in Gaia

Mozilla planet - ti, 08/04/2014 - 20:33

Today Zibi and I landed the refactored code of shared/js/l10n.js in Gaia master. A culmination of months of hard work, the refactor is also a first step of a larger initiative to innovate in the area of mobile localization and eventually, to implement L20n in Gaia.

Firefox OS faces a number of challenges related to localization. Growing the locale coverage beyond 20 supported locales; adapting to multiple screen sizes and form factors; ensuring the performance and memory consumption is good when the DOM is localized on the fly. In order to respond to these needs and many more that we will encounter in the future, we need a flexible and modular codebase, with a thought-out API designed to perform well in asynchronous scenarios.

We decided to re-write Gaia's l10n.js drawing from our experiences from developing L20n. The underlying concepts are similar: the code is organized into useful abstractions like the localization Context managing the fallback chain of Locale objects, or the Entity class which represents a single translation unit.

It's not L20n just yet. The library still uses the .properties file format.
There are no custom macros or arbitrary dicts which allow localizers greater flexibility in creating translations. The language fallback is limited to two locales. It still is a good first step towards empowering developers and localizers alike.

To minimize the risk of regressions, the refactored code was almost a drop-in replacement for the old l10n.js library. We decided to keep the exact same API of the navigator.mozL10n object. Everything should just work as it did before. We feel that there's room for improvement in the API design, and we'll soon start suggesting changes to it (e.g. bug 993188 has made many developers implement workarounds in their apps, which would break if we fixed it right away in our refactored drop-in patch).

Notable changes
  • Modular code which encapsulates main concepts of localization with a clean OOP approach.

  • Better security thanks to the lazy compilation step.

  • Better error reporting, especially on build time:

    /build_stage/browser/index.html: [l10n] [ar]: 3 missing in the visible DOM: enter-search-or-address, top-sites-startPage, browserBrandShortName /build_stage/browser/index.html: [l10n] [ar]: 10 missing compared to en-US: brandShortName, browserBrandShortName, browserBrandFullName, enter-search-or-address, top-sites-startPage, top-sites-tab, search-engines, default-search-engine, edit-bookmark, edit-bookmark-header
  • The internal API (currently hidden behind the navigator.mozL10n wrapper) is ready to fully support asynchronous parsing, compilation and fetching of translations, which we think will be important when implementing language packages for Firefox OS.

  • You can now freely nest placeables, meaning that this will work:

    foo = Foo foobar = {{ foo }} Bar foobarbaz = {{ foobar }} Baz
  • Good test coverage, both in our source repo and as part of the Gallery app test suite.

Feedback and bugs

The top priority fot this refactor was to be 100% compatible with the old l10n.js library. We made sure all tests pass on Travis and on TBPL and put a lot of effort into writing additional tests. We will be monitoring the tree for any regressions. If you notice something weird going on with your device or your app, for instance related to language switching, please let us know.
File bugs in the newly created Gaia::L10n component in Bugzilla or find us in #gaia and #l20n.

Next steps

The list of tasks on our to-do list is long, but we couldn't be more exited about them. Ranging from UX improvements to developer-friendly APIs, to giving localizes more control over their translations, next months are going to be great for localization and Firefox OS. A sneak peek, in no particular order:

  • Revisit the build time optimizations currently used in production Firefox OS builds, which we suspect cripple the performance of builds with more than 20 locales installed.

  • Implement responsive localization tools, such as the @formFactor macro which makes it possible to define different translations for tablets and phones.

  • Clean up the app startup API; implement mozL10n.ready() and mozL10n.once() as separate methods (bug 993188) and move away from listening to the 'localized' events.

  • Improve app launch performance by delaying localization when possible.

  • Research the use of Mutation Observers to automatically localize new DOM nodes when they are inserted into the existing DOM.

  • Research langpacks, possibly using the DataStores API.

  • Implement better language negotiation and language fallback via the ECMAScript Internationalization API and the navigator.languages API.

Categorieën: Mozilla-nl planet

Ron Piovesan: Quality content rules the Facebook news feed

Mozilla planet - ti, 08/04/2014 - 20:09

With over 1 billion users worldwide coupled with deep local reach and engagement, Facebook is a key social platform for financial services professionals to reach out and connect with customers.

Everyday, millions of agents and advisers use their Facebook Business Page to share content, post updates on their business, and provide useful insights into what is happening in the market.

But it is a simple truth that as more people engage on Facebook Business Pages, the more crowded a user’s news feed will be. At best, a user can review dozens or maybe a hundred updates a day.

To reduce noise and keep a user’s news feed as relevant as possible, Facebook uses over 1000 filters to determine which posts should get highlighted.

In a recent TechCrunch article,  Facebook News Feed Director of Product Management Will Cathcart highlighted the main filters:

  • How popular (Liked, commented on, shared, clicked) are the post creator’s past posts with everyone
  • How popular is this post with everyone who has already seen it
  • How popular have the post creator’s past posts been with the viewer
  • Doe the type of post (status update, photo, video, link) match what types have been popular with the viewer in the past
  • How recently was the post published

As an agent or adviser, you’ve worked hard to build a loyal and active following on your Facebook Business Page. Make sure you keep those followers engaged and up-to-date by posting timely, relevant content.

Focusing on consistency and quality of content will help determine how prominently your post will appear in your follower’s news feed.

Categorieën: Mozilla-nl planet