The Japanese engineering team has moved to a new office near Tokyo station. A lot less fancy than the beautiful space near National Arts Center, but a new space for discovery and exploration.webcompat issues
- Yet another regression related to the combination of a -moz-appearance: none and a background: 0 blocking the checkmark on input element.
- Strange issue with AbemaTV where the user agent sniffing is not always working.
- Flickr and Deezer are breaking because of a change in Firefox on the global property. And Jira
- Mazda Japanese Web site on mobile delivering a different broken experience with user agent sniffing.
- Proposed a pull request for issue 1261 on redesigning the comment area.
- Proposed a pull request for issue 722 on uploading two images. Merged.
- But forgotten the tests.
Reading about OKR and laughing hard:
The Objective is designed to get people jumping out of bed in the morning with excitement. And while CEOs and VCs might jump out of bed in the morning with joy over a three percent‐ gain in conversion, most mere mortals get excited by a sense of meaning and progress. Use the language of your team. If they want to use slang and say “pwn it” or “kill it,” use that wording.
Where is the humanity? Where is the individual accomplishment? And the collective realization of good? The thing which worries most is not the OKR method (it might be pretty good), but more the pseudo-intellectual mush given to managers. Instead, if you are a manager, go read Citadelle de Saint-Exupéry for example or go on a long hike in the mountains with another person. Anything which builds your understanding of humankind.
Almost two years ago the G-Ro travel bag kickstarter did the rounds and all of us travelers pricked up our ears. It sounded revolutionary and a really cool bag that is a mix of carry-on and laptop bag. It’s unique physics and large wheels promise easy travel and the in-built charger for mobiles and laptops seems excellent.
As with many kickstarters, this took ages to, well, kick in and by the time mine arrived my address had already changed. They dealt with this easily though and this last trip I took the cool bag for its first spin.
Now, a caveat: if you use the bag the way it is intended, I am sure it performs amiably. The problem I find is that the use case shown in the videos isn’t really one that exists for an international traveler.
Let’s start with the great things about the G-Ro:
- It looks awesome. Proper Star Trek stuff going on there.
- It does feel a lot lighter when you roll it compared to other two wheeled rollers. The larger wheels and the higher axle point makes physically sense.
- It comes with a lot of bags for the interior to fold shirts and jackets and lots of clever features.
- Once you spend the time to go through the instructions on the kickstarter page you’ll find more and more clever bits in it.
- The handle is sturdy and the right length to pull. It is less of a danger to other travelers, as all in all the angle you use it on is steeper. You use less space walking. However, it still is worse than a four-wheeled bag you push on your side. People still manage to run into the G-Ro at airports.
Now, for a weekend trip with a few meetings an a conference, this thing surely is cool and does the job. However, on my 4 day trip with two laptops and a camera it turns out to be just not big enough and the laptop bag is measured only for one laptop and not even a sensible space for the chargers.
Here are the things that miffed me about the G-Ro:
- Whilst advertising that it is the correct size for every airline to be a carry-on, the G-Ro is big and there are no straps to make it thinner. This is what I like about my The North Face Overhead Carry on Bag. This means that on an Airbus in Business Class, the G-Ro is a tight fit, both in height and length.
As most airlines ask you to put your coats on your bag, this is a no-go.
- The easy access bag on the front for your liquids and gels is flat and big, but the problem with liquids and deodorant/perfume bottles is that they are bulkier and less wide than that. This easy-access bag would be much better as another laptop/tablet holder. With your liquids in that bag, the G-Ro looks bulky and you’re sure to bump against the top of the overhead compartment with your liquids. Basically there is a good chance for accidental spillage. A bag on the side or a wider one on the back would make more sense.
- The bag in the back in between the handle bars is supposed to be for your wallet and passport, and thus works as an advertisement for pick-pockets. I used it for the chargers of my laptops instead, and that’s actually pretty convenient.
- The G-Ro is very clever in the way you can put a lot of cables and hardware into a very tight space. This is convenient, but also ensures that every time the bag is X-Rayed at the airport, it is taken out and officers ask you to remove things. Instead of keeping cables, iPods and chargers in the bags they should go, it would be better to have a removable pouch for them. I will use a Cable Organiser to avoid this now.
- One thing that is not really a problem but freaked me out is that the G-Ro is always slightly tilted and I am always wondering if it will fall over. It won’t, and what is pretty cool is that you can fully open the front bag without it falling over. But it is something to get used to.
- Now, I might have put too much in for a four day trip, but here is the main issue with the G-Ro. For its size it is ridiculously heavy – you know, like the first two Black Sabbath albums heavy. With its big wheels it feels great to pull the bag, but once you get to some stairs, you get a rude awakening. No, you can’t roll it down most stairs, as it would bounce and as with all two-wheel bags you have the issue of a slight angle going down a step making the bag fishtail. The heaviness of the bag is exacerbated by the uselessness of the handle on the side, which doesn’t pull out at all and thus for my fat fingers is a trap and great to remove fingernails rather than a way to carry the bag or pull it out of the overhead compartment.
All in all, I am not punishing myself for backing this product, but it is only useful for a certain use case. In essence, it is a glorified backpack or laptop bag, but not a full travel companion. I’m looking forward to using it for weekend business trips that last two days, as it will force me not to buy things. But with all the hype and the plethora of useful features that the web site and the videos promise us, I found it underwhelming, especially for this price.
Last week, I went to the conference Tech in Asia Jakarta 2016. Digressing… This URL will not be relevant for the 2016 content next year. It is a weak URL, already rusty from the start. A good way to fix this is to set a temporary redirection from http://events.techinasia.com/jakarta/ to http://events.techinasia.com/jakarta/2016/ so people have the right link in their bookmarks. Once the conference is finished, you can start redirecting to 2017.
I have been put in touch with David Corbin by Sandra Persing and Dietrich Ayala for talking about Web Compatibility on the Developer stage. The conference has a strong marketing and product placement agenda. This is not the usual crowd I venture to, but it's always interesting to have a different view on how people conceive and foresee the Web.
But we know for a long time Web Compatibility is about participating.Jakarta
Jakarta is a vibrant city which is bustling to the sounds of motorbikes. Buildings are growing everywhere. The city is being modernized at a fast pace and like in many other cities going through these transformations, it is socially and ecologically violent. The Guardian has this week a full live coverage of Jakarta. The street food is amazing and quality coffee places are not hard to find. The population is young. This participates to the dynamism of the city and the startup ecosystem.Web Compatibility talk
For my talk I usually try to connect to something the audience can relate to. This time I have used in most of my slides the Indonesian masks culture (topeng). Barong is a good spirit (on the left), while Rangda is a demon (on the right). The Web compatibility work is very much a battle in between the good and evil ways of doing things. But we all have to remember that like in the world of spirits, the daily reality is a lot more complex than just being right or wrong. Rangda is an evil force and… a protective force at the same time.
What do we mean when we talk about the Web? The Web is a space where a person should be able to use whatever device and browser of their choice to access and interact with the content. The Web has been instrumental in making information cheaply accessible anywhere at anytime everywhere on earth. It enlarged the ability of individuals to publish content.
A couple of years ago, at Mozilla, we tested the top 1000 Web sites in Japan and China on Firefox for Android. We quickly realized that around 20% of these sites were broken in some ways to the point of being completely unusable. The common issues were related to WebKit properties (CSS and DOM) such as old flexbox, gradient, transition, background-size, etc. Sometimes sites were relying on old non-standard properties implemented by other browsers but not Firefox such as innerText (the standard keyword is textContent). In this image of the Mobage site, we clearly the sign of flexbox first generation.
It leads to the fragmentation of the Web and condemn people to use specific devices when they can afford it. It is also a vicious circle. Any reasonable Web agencies or IT departments before fixing a bug look at their browser market shares. If a specific browser is not visible in their analytics, they decide it's not important to support it and not worth spending time on fixing the issues. Contacting the companies for outreach to get the sites fixed becomes a seduction game. In cases where the site is totally unusable by design leads to an obvious zero marketshare. It also becomes very difficult to convince the company that they will get customers if they fix the bug. And last but not least, if too many sites are broken, it becomes a lot harder to make distribution deals with devices companies, which in return entrenches the low marketshare.
How do we escape from this ouroboros? When the effort on HTML restarted, some design principles have been established including the priority of constituencies
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
It says that the people using the Web for reading and publishing are the most important in the ecosystem. Everything should be done so they have a smooth Web experience. Sometimes as a Web developer, you might want to choose a less fancy solution so more people can use the service. As a browser implementor, you need to implement non-standard properties so the sites will be working on people's browsers.Some Web Compatibility issues HTTP
Web compatibility issues are not only about CSS and DOM. Sometimes they are deep into the user experience and the way we use the protocols. A couple of years most Web sites had dedicated domain names for desktop computers and mobile devices. To help the user get the right experience, they used user agent sniffing (user agent detection mechanism). Each browser sports a HTTP User-Agent string which is sent with every request and identifies the browser. So sites are redirecting the device based on the user agent string to the www. or m. domains. Algorithms and databases of user agent strings help Web developers to make the right choice but for one issue: only the past is known. A new user agent string on the market will be unknown and then will not be recognized by these algorithms, sending the user to the wrong site. It's why I often say that user agent sniffing is a future fail strategy. It works only if you intend to keep a very high maintenance of every possible browser/device coming into the market before it actually hits the market. Mission impossible.
elm.style.webkitTransform elm.style.WebkitTransform elm.style['-webkit-transform'] elm.style['transform']
This kind of things led the core team of Firefox (working on Gecko) pushed by the web compatibility team to implement many aliases of WebKit. Some properties really need just an alias, but some are slightly more subtle, such as flexbox. The first implementation of flexbox is very different from the current one and websites using the first version only (aka for WebKit safari) breaks if we were just simply converting to modern flexbox.
until… (you know there is a recurrent joke here and that there will be an issue, but let's continue with it) Mozilla deployed the new feature in Firefox Nightly and broke many Web sites using Mootools 1.2. This well-known library had a similar keyword but not with the same exact semantics. Firefox had to back out this and remove the regression. Luckily enough this happened before productions releases.
The ES6 crew had to propose a new keyword: includes instead of contains. Sometimes we will discover Web compatibility issues only once we deploy a new feature and we realize that a well-known site or a successful libraries is relying on either a bug in the browser, or a similar feature.Contacting Web sites
Why these issues happen in the first place? Why can't people just code according to the standards. It's a very hard question. The Web is not only a technical object. It's not just code out of a compiler. The Web exists because of a social-economical structure. It's a deeply social object. Asking why some sites are broken is like wondering why there is pollution and why people can't just individually do the right thing. If you have worked or are working in a Web agency as a Web developer. You know you have a boss (or a project manager) and that there are clients. You know that the taboo Friday deployment is still happening. That the budget is undervalued. That the timeline for delivering the project is too tight. That the browsers themselves have their own set of issues. So people make choices, cut corners and test only for a certain number of scenarios.
Usually we try to contact Web sites. We make an attempt at discovering who is in charge, but here again boss, client, Fridays, legacy Web sites, maintenance budget in oblivion.
Sometimes the issue are deeper and comes directly from the specification. When you read in a specification "Left to implementations" runs away from the feature. It means that the specification doesn't explain clearly the behavior of the feature and implementers will have to decide what they should do with the gap in description. That often leads to interoperability issues. Sometimes it's because web developers are using some features in "creative" ways that implementers would have never thought about. Any systems contain in itself ways of being exploited in unfathomable directions.How To Do A Better Job?
There are ways to mitigating the issues. On webcompat.com, we developed the tool cssfixme, it is not perfect but it's a good way to understand how to fix your webkit only CSS. Better is to use tools such as postcss. They will take care for you of the incompatibilities and prefixing strategy. It helps you to focus on what matters. They do the hard work of salting for the browsers with appropriate prefixes.
Prefixes were a well intended idea—remember what I said about systems—but because of the socio-economical structure of the Web, they became a Achilles' heel for some browsers. A browser with very large market share can deploy a feature with a prefix and because Web developers don't want to wait before using it in production. It becomes a de-facto standard. That's really unfortunate, but a reality.
So browsers have decided a new policy and put new features behind settings to flip on and off. Most users do not change or even have access to these type of settings. So Web developers can't rely on them for the new production release of their site. At the same time, they can easily test the features by activating them. The caveat is that there will be less chances to discover issues, but it's a lot better for the browser ecosystem.
MDN is a treasures trove. This set of documentation hosted by Mozilla and written by the large Web developer community gives a lot of information about the Web features, including Web compatibility tables. And if an information is missing, just contribute. I would also specially recommend caniuse.com
If you find a bug in a browser you need to report it to browser vendors. This is essential. Too few Web developers report issues about Web browsers, and still they are the core of their daily usage. By reporting issues and bugs, you help browsers become better for your future work. The bugs you encounter in developing your own site are unique. Browser implementers can't imagine them or make them up.
Finally if you notice a Web site as a user or a Web developer with different rendering or behavior in different browsers. Do not hesitate to report it to webcompat.com. Make sure to test in multiple browsers. Be careful about your addons, they often create differences in between browsers (such as adblockers).
Let's Encrypt: Volledig versleuteld web stap dichterbij
In 2016 jaar is het fundament voor een volledig versleuteld web gelegd, zo stelt Let's Encrypt, een initiatief van de Internet Security Research Group (ISRG) dat wordt gesteund door Mozilla, Akamai, Cisco, de Amerikaanse burgerrechtenbeweging EFF en ...
I’ve been a gmail user for many years (maybe ten). Especially since the introduction of smart phones it has been a really convenient system to read email on the go. I rarely respond to email from my phone but I’ve done that occasionally too and it has worked adequately.
All this time I’ve used my own domain and email address and simply forwarded a subset of my email over to gmail, and I had gmail setup so that when I emailed out from it, it would use my own email address and not the @gmail.com one. Nothing fancy, just convenient. The gmail spam filter is also pretty decent so it helped me to filter off some amount of garbage too.It was fine until DMARC
However, with the rise of DMARC over the recent years and with Google insisting on getting on that bandwagon, it has turned out to be really hard to keep forwarding email to gmail (since gmail considers forwarded emails using such headers fraudulent and it rejects them). So a fair amount of email simply never showed up in my gmail inbox (and instead caused the senders to get a bounce from a gmail address they didn’t even know I had).
I finally gave up and decided gmail doesn’t work for this sort of basic email setup anymore. DMARC and its siblings have quite simply made it impossible to work with emails this way, a way that has been functional for decades (I used similar approaches already back in the mid 90s on my first few jobs).
Similarly, DMARC has turned out to be a pain for mailing lists since they too forward email in a similar fashion and this causes the DMARC police to go berserk. Luckily, recent versions of mailman has options that makes it rewrite the From:-lines from senders that send emails from domains that have strict DMARC policies. That mitigates most of the problems for mailman lists. I love the title of this old mail on the subject: “Yahoo breaks every mailing list in the world including the IETF’s”
I’m sure DMARC works for the providers in the sence that they block huge amounts of spam and fake users and that’s what it was designed for. The fact that it also makes ordinary old-school mail forwards really difficult and forces mailing list admins all over to upgrade mailman or just keep getting rejects since they use mailing list software that lacks the proper features, that’s probably all totally ignored. DMARC was as designed: it reduces spam at the big providers’ systems. Mission accomplished. The fact that they at the same time made world wide Internet email a lot less useful is probably not something they care about.It’s done
gmail can read mails from remote inboxes, but it doesn’t support IMAP (only POP3) so simply switching to such a method wouldn’t even work. I just refuse to enable POP3 anywhere again.
Of course it isn’t an irreversible decision, but I’ve stopped the forward to gmail, cleared the inbox there and instead I’ve switched to Aqua mail on Android. It seems fairly feature complete and snappy. It isn’t quite as fancy and cool as the gmail client, but hopefully it will do its job.
The biggest drawback I’ve felt after a couple of weeks is the gmail spam filter. I do run spamassassin on my server and it catches the large bulk of all spams, but having the gmail spam system on top of that was able to block more silliness from my phone than spamassassin does alone.
Let's Encrypt geeft miljoen gratis certs op een dag uit
In 2015 kwam het project, dat onder meer door digitale burgerrechtenorganisatie EFF is opgezet, direct van de grond met de steun van grote namen als Mozilla, Cisco en Akamai. Het doel is om versleuteld verkeer gratis en gemakkelijk te maken, zodat ...
Let's Encrypt: Volledig versleuteld web stap dichterbijSecurity.nl
alle 2 nieuwsartikelen »
In the last weeks, we landed 104 PRs in the Servo organization’s repositories.Planning and Status
Our overall roadmap is available online. Plans for 2017 (including Q1) will be solidified in the coming week. Please check it out and provide feedback!
This week’s status updates are here.Notable Additions
- gw added non-square texture page sizes to the renderer.
- UK992 fixed some packaging issues breaking the macOS nightly builds.
- nox corrected the way the text nodes get added to documents during parsing.
- UK992 enabled using ccache on Appveyor builds.
- mrnayak implemented support for subresource integrity checks.
- charlesvdv enabled setting numeric preferences from the command line.
- bzbarsky made per-document styles possible in Stylo.
- anholt implemented an overload of the WebGL bufferData API.
- jdm fixed an incorrect script/layout interaction preventing logging into many Google applications.
- Ms2ger implemented the “entry global” specification concept.
- emilio redesigned the interactions between the style system and media queries.
- Manishearth implemented the @supports directive for CSS.
- bholley improved performance of manipulating threadsafe RefCells.
- Manishearth added better documentation to all CSS properties.
- wafflespeanut made the behaviour of the input DOM event match the specification.
- cynicaldevil implemented the missing Document overload for the XMLHttpRequest API.
- MortimerGoro implemented the WebVR API.
- asajeffrey made Servo not retain every web page that it has ever loaded in the current session.
- paulrouget fixed the problem preventing the brew nightly formula from working.
- asajeffrey avoided the problem of creating many RNGs that would eventually exhaust available file descriptors.
- Dowon Cha
- Frederick F. Kautz IV
- Josh Holmer
- Jure Podgoršek
- Konstantin Veretennicov
Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!Screenshot
Mozilla roept op tot verantwoord Internet of Things
Mozilla roept ontwikkelaars van Internet of Things (IoT) apparaten, bedrijven en overheden op meer aandacht te besteden aan de beveiliging, risico's en dreigingen van het IoT. Het is volgens Mozilla van belang niet alleen te kijken naar de technische ...
en meer »
Mozilla roept op tot verantwoord Internet of Things
Mozilla roept ontwikkelaars van Internet of Things (IoT) apparaten, bedrijven en overheden op meer aandacht te besteden aan de beveiliging, risico's en dreigingen van het IoT. Het is volgens Mozilla van belang niet alleen te kijken naar de technische ...
en meer »
Since 2017 has finally arrived (a while ago), our team wanted to share a few numbers and remarks with you. This report is a bit delayed, but we hope it will prove to be worth the extra few days’ wait.
We are on the brink of probably the biggest change to the “way things are” around SUMO in the recent years, so taking a good look back is a great way to make sure we stay focused on the road ahead.
2016 has not been an easy year for many members of our community, for many of reasons. Fortunately, we all persevered and managed to come out stronger / wiser / more prepared on this side of the calendar. We will definitely keep working together on many aspects of our site, our community, and our presence in Mozilla’s mission. Our small core team counts on your presence and strength and you can count on our support. You rock the helpful web.
As for all the data you will see on this page and the ones it links to: remember that while we use some of these numbers to prepare plans for the future and put them into reality, they are just numbers – and as such cannot and will not fully represent the passion, the values, the talent and effort behind every single angry user turned into a happy one thanks to your dedication to making the open web better and more helpful.
For all that we thank you from the bottom of our hearts.
Now, let’s get on with the show!SUMO 2016 – the major facts
- We joined forces with the Marketing Team, becoming a part of MarComms, and working more closely with the Mozillians at the heart of Social and PR projects.
- With Firefox 46, we started publishing SUMO Release Reports, which met with a very positive response from all sides of Mozilla:
- Kitsune, our home-made support platform went through a LOT of changes, the final of which was the decision to replace it with an external solution, due to our lovely developer team being reassigned to other parts of the Mozilla project. We spent the better part of the second half of the year investigating the next generation of SUMO tech. We should be using the new platform any day now…
- Social Support and Army of Awesome morphed into two different beasts this year. While trying out a new tool (Sprinklr), a robust social engagement tool used for brand marketing, we engaged many new people, but it took us some time to refine our goals.
- We started to onboard with a goal of 25 active volunteers and soon found the tool overwhelming for just a few volunteers. Once we moved to another tool (Respond), a new community was created from the retiring Army of Awesome and the 4 main Mozilla Brand Social accounts for English, Spanish, Portuguese, and French languages. After transitioning to the new support tool, 33 people received training and the response rate went up from 10% to 33%.
- The Knowledge Base articles explaining how to contribute were revised, rewritten and re-read aplenty :-)
- We kicked off the “Internet Awareness” project – an exploration of a new way of educating users about the web.
- Safwan saved many a gray hair from appearing for numerous localizers through his Save as Draft feature.
- We changed a bit the way our Community Meetings worked, and we went full HD, 3D, hypersurround sound with AirMozilla (thanks, Costenslayer!)
- SUMO went places! #sumotourctg, SUMO@FOSDEM, SUMO Contributor Mentoring Day, SUMO l10n Sprint in Tunisia, Kazakhstan, Ivory Coast, Jakarta,
- We improved the SUMO Event Kit based on your feedback.
- This blog had 68 new posts and over 9,200 page views. Some of the best posts this year were written by you! Still, support.mozilla.org seems a bit more popular (see more details on that below) – but we are slowly catching up! ;-)
As you can imagine, our activity and its results can be described in many ways – and by many numbers. It would be a daunting task to put all of them here in a coherent way, so we decided to summarize data showing the potential, reach, and power of SUMO – both as a source of knowledge and help, and as an example of community collaboration.General site stats
- Number of total page views: 806,225,837
- Number of users with at least one recorded session (= visit to the site): 259,584,893
- Number of sessions (= periods of active user engagement on the site): 446,537,566
- Percentage of people returning to the site: 45%
- Average time spent on site per session: 01:39
- Average number of pages visited per session: 1.81
- Percentage of single page visits: 25%
- Number of people who created a SUMO account: 57,656
- Number of people who contributed for the first time: 1,153
- Percentage of people who visited SUMO using Firefox: 84%
- Percentage of people who visited SUMO using Chrome: 7% / Safari: 4% / Internet Explorer: 3%
- Top visitor 10 languages (by percentage of sessions):
- Portuguese (Brazil)
- Chinese (simplified)
- Top 10 visitor countries (by percentage of sessions):
- United States
- United Kingdom
- An interesting euro-fact: the top 5 countries by percentage of sessions from the European Union region were over 24% of all sessions in 2016.
- Number of all submitted revisions:
- for English only: 2,068
- for the top 20 locales: 14,177
- in all locales: 21,741 (almost 60 a day on average!)
- The most active Knowledge Base contributors in 2016 – each and every one of you is an e-linguistic superstar! Major shout-outs go to:
Here are the top viewed items for 2016, also considered to be the most “popular” in terms of issues raised by users across the board, in no particular order:
- My Youtube videos won’t load. “An error occurred, please try again later”.
- Insecure Connection – “Your connection is not secure”
- I got a Urgent Firefox update from [URL] Should I manually install? and Urgent Fire Fox Update Notice
- Twitter videos – “the media could not be played” – Solution
- users looking for the offline installers for Firefox
- people who want to how to cast a mobile device to a monitor
- users wondering how to change the interface language
- people who have problems using the full screen mode
All in all, it’s been quite a busy year, and there was so much great support from your side that it would not all fit into this blog post (we tried, the blog almost exploded), so do browse the highlight below and make sure you check the document linked at the end of this section. All your dedication and hard work throughout last year paid off and we are all grateful to each and every one of you for making SUMO’s support forums the best official support site for Mozilla’s software! As a bonus, there’s about two million smiles from Rachel for everyone who replied to a question, I hear ;-) Roll on with the numbers!
- Percentage of users (from 11,604 responses recorded through the Exit Survey):
- very satisfied with Firefox: 31.6%
- satisfied with Firefox: 27.3%
- neutral towards Firefox: 13.0%
- dissatisfied with Firefox: 11.3%
- very dissatisfied with Firefox: 11.1%
- Percentage of users who visited SUMO to:
- find a solution to a problem: 74,7%
- learn more about Firefox: 13.2%
- do something else: 12.1%
- Percentage of users who:
- found what they were looking for on SUMO: 40.2%
- did not find what they were looking for on SUMO: 47.6%
- don’t know what to say about the result of their visit: 12.2%
- The most active Support Forum contributors in 2016 – each and every one of you is a guardian angel of cyberspace! Major shout-outs go to:
Remembering the Awesome… Army of Awesome!
- We had 390 members of the Army of Awesome contributing until its very last day in 2016
- They contributed in German, English, French, Galego (!), Hungarian, Italian, Japanese, Norwegian, Dutch, Polish, Portuguese, Romanian, Russian, Tamil, Turkish, Ukrainian, and Chinese… You can see more data about their contributions here.
As a reminder: The Army of Awesome was a self service support program of one to one user support, with a glorious legion of amazing people around the world responding to Firefox (and not only) users in trouble through Twitter. It was morphed into a Social Support program that you can sign up for through form and learn more about from this wiki.
Most active contributors on Social: March to SeptemberContributor Messages Kristina Gorr 756 Andrew Truong 449 Noah Y 385 Magno Reis 298 Jhonatas Rodrigues Machado 179 Daniela Albarrán 105 Swarnava Sengupta 68 42265 62 Geraldo Barros 25 Cynthia Pereira 23 Rachel McGuigan 23 Marcelo Lauxen 16 Stefan Costen 15 Ghaith Limam 12 Alex Mayorga 8 Rachael Morrill 7 Luis Sanchez 4 Jaime Maretoli 2 Benny Chandra 2
October to December (welcome, Sierra!)
- Average time to a first reply on Social:
- 1d 21h (for the period from October to December)
- The lowest average time to a first reply on Social: 8 hours during one of the weeks in December!
Nope, it’s not enough that this is “probably the longest post on this blog, ever!” This is where we would love to see you step in :-) Please use the comment section to share your best and not so good SUMO (or Mozilla) moments from the last calendar year. If you think we should anything else to the report, please use the comments section as well.
We look forward to hearing from you!
I couldn’t even recall how many times I’ve done this already, but in 2017 I am once again showing up in the cold and grey city called Brussels and the lovely FOSDEM conference, to talk. (Yes, it is cold and grey every February, trust me.) So I had to go back and count, and it turns out 2017 will become my 8th straight visit to FOSDEM and I believe it is the 5th year I’ll present there.First, a reminder about what I talked about at FOSDEM 2016: An HTTP/2 update. There’s also a (rather low quality) video recording of the talk to see there.
I’m scheduled for two presentations in 2017, and this year I’m breaking new ground for myself as I’m doing one of them on the “main track” which is the (according to me) most prestigious track held in one of the biggest rooms – seating more than 1,400 persons.You know what’s cool? Running on billions of devices
Thousands of contributors help building the curl software which runs on several billions of devices and are affecting every human in the connected world daily. How this came to happen, who contributes and how Daniel at the wheel keeps it all together. How a hacking ring is actually behind it all and who funds this entire operation.So that was HTTP/2, what’s next?
A shorter recap on what HTTP/2 brought that HTTP/1 couldn’t offer before we dig in and look at some numbers that show how HTTP/2 has improved (browser) networking and the web experience for people.
Still, there are scenarios where HTTP/1’s multiple connections win over HTTP/2 in performance tests. Why is that and what is being done about it? Wasn’t HTTP/2 supposed to be the silver bullet?
A closer look at QUIC, its promises to fix the areas where HTTP/2 didn’t deliver and a check on where it is today. Is QUIC perhaps actually HTTP/3 in everything but the name?
Depending on what exactly happens in this area over time until FOSDEM, I will spice it up with more details on how we work on these protocol things in Mozilla/Firefox.
This will become my 3rd year in a row that I talk in the Mozilla devroom to present the state of the HTTP protocol and web transport.
Up until recently, anytime you pushed a patch series to MozReview, a single attachment would be created on the bug associated with the push.
That single attachment would link to the “parent” or “root” review request, which contains the folded diff of all commits.
We noticed a lot of MozReview users were (rightfully) confused about this mapping from Bugzilla to MozReview. It was not at all obvious that Ship It on the parent review request would cause the attachment on Bugzilla to be r+’d. Consequently, reviewers used a number of workarounds, including, but not limited to:
- Manually setting the r+ or r- flags in Bugzilla for the MozReview attachments
- Marking Ship It on the child review requests, and letting the reviewee take care of setting the reviewer flags in the commit message
- Just writing “r+” in a MozReview comment
Anyhow, this model wasn’t great, and caused a lot of confusion.
So it’s changed! Now, when you push to MozReview, there’s one attachment created for every commit in the push. That means that when different reviewers are set for different commits, that’s reflected in the Bugzilla attachments, and when those reviewers mark “Ship It” on a child commit, that’s also reflected in an r+ on the associated Bugzilla attachment!
I think this makes quite a bit more sense. Hopefully you do too!
I’m on vacation this week, but the show must go on! So I pre-recorded a shorter episode of The Joy of Coding last Friday.
I demo the tool, and then I explain how it works. After I finished the episode, I pushed to repository to GitHub, and you can check that out right here.
So I’ll see you next week with a full length episode! Take care!
Which, several times, I mistakenly refer to as the 15th episode, and not the 16th. Whoops. ↩
Common (excluding Website bugs)-specific: (23)
- Fixed: 768207 – Make the cache checkbox default-on in the new calendar dialog
- Fixed: 1049591 – Fix lots of strict warnings
- Fixed: 1086573 – Lightning and Thunderbird disagree about timezone support in ics files
- Fixed: 1099592 – Make JS callers of ios.newChannel call ios.newChannel2 in calendar/
- Fixed: 1149423 – Add Windows timezone names to list of aliases
- Fixed: 1151011 – Calendar events show up on wrong day when printing
- Fixed: 1151440 – Choose a color not responsive when creating a New calendar in Lightning 4.0b1
- Fixed: 1153327 – Run compare-locales with merging for Lightning
- Fixed: 1156015 – Email scheduling fails for recipients with URN id
- Fixed: 1158036 – Support sendMailTo for URN type attendees
- Fixed: 1159447 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_extract.js
- Fixed: 1159638 – Getter fails in calender-migration-dialog on first run after installation
- Fixed: 1159682 – Provide a more appropriate “learn more” page on integrated Lightning firstrun
- Fixed: 1159698 – Opt-out dialog has a button for “disable”, but actually the addon is removed
- Fixed: 1160728 – Unbreak Lightning 4.0b4 beta builds
- Fixed: 1162300 – TEST-UNEXPECTED-FAIL | xpcshell-libical.ini:calendar/test/unit/test_alarm.js | xpcshell return code: 0
- Fixed: 1163306 – Re-enable libical tests and disable ical.js in nightly builds when binary compatibility is back
- Fixed: 1165002 – Lightning broken, tries to load libical backend although “calendar.icaljs” defaults to “true”
- Fixed: 1165315 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_bug759324.js | xpcshell return code: 1 | ###!!! ASSERTION: Deprecated, use NewChannelFromURI2 providing loadInfo arguments!
- Fixed: 1165497 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_alarmservice.js | xpcshell return code: -11
- Fixed: 1165726 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/testBasicFunctionality.js | testBasicFunctionality.js::testSmokeTest
- Fixed: 1165728 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_bug494140.js | xpcshell return code: -11
Sunbird will no longer be actively developed by the Calendar team.
- Fixed: 401779 – Integrate Lightning Into Thunderbird by Default and Ship Thunderbird with Lightning Enabled
- Fixed: 717292 – Spell check language setting for subject and body not synchronized, but temporarily appears so when changing language and depending on focus (confusing ux)
- Fixed: 914225 – Support hotfix add-on in Thunderbird
- Fixed: 1025547 – newmailaccount/jquery.tmpl.js, line 123: reference to undefined property def
- Fixed: 1088975 – Answering mail with sendername containing encoded special chars and comma creates two “To”-entries
- Fixed: 1101237 – Remove distribution directory during install
- Fixed: 1109178 – Thunderbird OAuth implementation does not work with Evernote
- Fixed: 1110166 – Port |Bug 1102219 – Rename String.prototype.contains to String.prototype.includes| to comm-central
- Fixed: 1113097 – Fix misuse of fixIterator
- Fixed: 1130854 – Package Lightning with Thunderbird
- Fixed: 1131997 – Adapt for Debugger Server code for changes in bug 1059308
- Fixed: 1135291 – Update chat log entries added to Gloda since bug 955292 to use relative paths
- Fixed: 1135588 – New conversations get indexed twice by gloda, leading to duplicate search results
- Fixed: 1138154 – Plugins default to “always activate” in Thunderbird
- Fixed: 1142879 – [meta] track Mozilla-central (Core) issues that we want to have fixed in TB38
- Fixed: 1146698 – Chat Messages added to logs just before shutdown may not be indexed by gloda
- Fixed: 1148330 – Font indicator doesn’t update when cursor is placed in text where core returns sans-serif (Windows). Serif and monospace don’t work (Linux).
- Fixed: 1148512 – TEST-UNEXPECTED-FAIL | mailnews/imap/test/unit/test_dod.js | xpcshell return code: 0||1 | streamMessages – [streamMessages : 94] false == true | application crashed [@ mozalloc_abort(char const * const)]
- Fixed: 1149059 – splitter in compose window can be resized down to completely obscure composition area
- Fixed: 1151206 – Using a theme hides minimize, maximize and close button in composer window [Mac]
- Fixed: 1151475 – Remove use of expression closures in mail/
- Fixed: 1152299 – [autoconfig] Cosmetic changes for WEB.DE config
- Fixed: 1152706 – Upgrade to Correspondents column (combined To/From column) too agressive
- Fixed: 1152796 – chrome://messenger/content/folderDisplay.js, line 697: TypeError: this._savedColumnStates.correspondentCol is undefined
- Fixed: 1152926 – New mail sound preview doesn’t work for default system sound on Mac OS X
- Fixed: 1154737 – Permafail: TEST-UNEXPECTED-FAIL | toolkit/components/telemetry/tests/unit/test_TelemetryPing.js | xpcshell return code: 0
- Fixed: 1154747 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/session-store/test-session-store.js | test-session-store.js::test_message_pane_height_persistence
- Fixed: 1156669 – Trash folder duplication while using IMAP with localized TB
- Fixed: 1157236 – In-content dialogs: Port bug 1043612, bug 1148923 and bug 1141031 to TB
- Fixed: 1157649 – TEST-UNEXPECTED-FAIL | dom/push/test/xpcshell/test_clearAll_successful.js (and most other push tests)
- Fixed: 1158824 – Port bug 138009 to fix packaging errors | Missing file(s): bin/defaults/autoconfig/platform.js
- Fixed: 1159448 – Thunderbird ignores proxy settings on POP3S protocol
- Fixed: 1159627 – resource:///modules/dbViewWrapper.js, line 560: SyntaxError: unreachable code after return statement
- Fixed: 1159630 – components/glautocomp.js, line 155: SyntaxError: unreachable code after return statement
- Fixed: 1159676 – mailnews/mime/jsmime/test/test_custom_headers.js | run_next_test 0 – TypeError: _gRunningTest is undefined at /builds/slave/test/build/tests/xpcshell/head.js:1435 (and other jsmime tests)
- Fixed: 1159688 – After switching/changing the window layout, dragging the splitter between threadpane and messagepane can create gray/grey area/space (misplaced notificationbox)
- Fixed: 1159815 – Take bug 1154791 “Inline spell checker loses red underlines after a backspace is used – take two” in Thunderbird 38
- Fixed: 1159817 – Take “Bug 1100966 – Inline spell checker loses red underlines after a backspace is used” in Thunderbird 38
- Fixed: 1159834 – Consider taking “Bug 756984 – Changing location in editor doesn’t preserve the font when returning to end of text/line” in Thunderbird 38
- Fixed: 1159923 – Take bug 1140105 “Can’t query for a specific font face when the selection is collapsed” in TB 38
- Fixed: 1160105 – Fix strict mode warnings in protovis-r2.6-modded.js
- Fixed: 1160106 – “Searching…” spinner at the bottom of gloda search results never goes away
- Fixed: 1160114 – Strict mode warnings on faceted search
- Fixed: 1160805 – Missing Windows and Linux nightly builds, build step set props: previous_buildid fails
- Fixed: 1161162 – “Join Chat” doesn’t focus the newly joined MUC
- Fixed: 1162396 – Take bug 1140617 “Pasting an image loses the composition style” in TB38
- Fixed: 1163086 – Take bug 967494 “changing spellcheck language in one composition window affects all open and new compositions” in TB38
- Fixed: 1163299 – “TypeError: getBrowser(…) is null” in contentAreaClick with Lightning installed and started in calendar view
- Fixed: 1163343 – Incorrectly formatted error message “sending failed”
- Fixed: 1164415 – Error in comment for imapEnterServerPasswordPrompt
- Fixed: 1164658 – TypeError: Cc[‘@mozilla.org/weave/service;1’] is undefined at resource://gre/modules/FxAccountsWebChannel.jsm:227
- Fixed: 1164707 – missing toolkit_perfmonitoring.xpt in aurora builds
- Fixed: 1165152 – Take bug 1154894 in TB 38 branch: Disable test_plugin_default_state.js so Thunderbird can ship with plugins disabled by default
- Fixed: 1165320 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/notification/test-notification.js
MailNews Core-specific: (30)
- Fixed: 610533 – crash [@ nsMsgDatabase::GetSearchResultsTable(char const*, int, nsIMdbTable**)] with virtual folder
- Fixed: 745664 – Rename Address book aaa to aaa_test, delete another address book bbb, and renamed address book aaa_test will lose its name and appear deleted after restart (dataloss! involving localized names)
- Fixed: 777770 – get rid of nsVoidArray from /mailnews
- Fixed: 786141 – Use nsIFile.exists() instead of stat to check the existence of the file
- Fixed: 1069790 – Email addresses with parenthesis are not pretty-printed anymore
- Fixed: 1072611 – Ctrl+P not working from Composition’s Print Preview window
- Fixed: 1099587 – Make JS callers of ios.newChannel call ios.newChannel2 in mail/ and mailnews/
- Fixed: 1130248 – |To: “email@example.com” <firstname.lastname@example.org>| becomes |”email@example.com”@example.com| when I compose mail to it
- Fixed: 1138220 – some headers are not not properly capitalized
- Fixed: 1141446 – Behaviour of malformed rfc2047 encoded From message header inconsistent
- Fixed: 1143569 – User-agent error when posting to NNTP due to RFC5536 violation of Tb (user-agent header is folded just after user-agent:, “user-agent:[CRLF][SP]Mozilla…”)
- Fixed: 1144693 – Disable libnotify usage on Linux by default for new-mail notifications (doesn’t always work after bug 858919)
- Fixed: 1149320 – fix compile warnings in mailnews/extensions/
- Fixed: 1150891 – Port package-manifest.in changes from Bug 1115495 – Part 2: PAC generator for browsing and system wide proxy
- Fixed: 1151782 – Inputting 29th Feb as a birthday in the addressbook contact replaces it with 1st Mar.
- Fixed: 1152364 – crash in Address Book via nsAbBSDirectory::GetChildNodes nsCOMArrayEnumerator::operator new(unsigned int, nsCOMArray_base const&)
- Fixed: 1152989 – Account Manager Extensions broken in Thunderbird 37/38
- Fixed: 1154521 – jsmime fails on long references header and e-mail gets sent and stored in Sent without headers
- Fixed: 1155491 – Support autoconfig and manual config of gmail IMAP OAuth2 authentication
- Fixed: 1155952 – Nesting level does not match indentation
- Fixed: 1156691 – GUI “Edit filters”: Conditions/actions (for specfic accounts) not visible
- Fixed: 1156777 – nsParseMailbox.cpp:505:55: error: ‘do_QueryObject’ was not declared in this scope
- Fixed: 1158501 – Port bug 1039866 (metro code removal) and bug 1085557 (addition of socorro symbol upload API)
- Fixed: 1158751 – Port NO_JS_MANIFEST changes | mozbuild.frontend.reader.SandboxValidationError: calendar/base/backend/icaljs/moz.build
- Fixed: 1159255 – Build error: MSVC_ENABLE_PGO = True is not permitted to be used in mailnews/intl/moz.build
- Fixed: 1159626 – chrome://messenger/content/accountUtils.js, line 455: SyntaxError: unreachable code after return statement
- Fixed: 1160647 – Port |Bug 1159972 – Remove the fallible version of PL_DHashTableInit()| to comm-central
- Fixed: 1163347 – Don’t require scope in ispdb config for OAuth2
- Fixed: 1165737 – Fix usage of NS_LITERAL_CSTRING in mailnews, port Bug 1155963 to comm-central
- Fixed: 1166842 – Re-enable binary extensions for comm-central
You might have noticed that I had no “Things I’ve Learned This Week” post last week. Sorry about that – by the end of the week, I looked at my Evernote of “lessons from the week”, and it was empty. I’m certain I’d learned stuff, but I just failed to write it down. So I guess the lesson I learned last week was, always write down what you learn.How to make your mozilla-central Mercurial clone work faster
I like Mercurial. I also like Git, but recently, I’ve gotten pretty used to Mercurial.
One complaint I hear over and over (and I’m guilty of it myself sometimes), is that “Mercurial is slow”. I’ve even experienced that slowness during some of my Joy of Coding episodes.
This document did not exist when I first started working with Mercurial – back then, I was using mq or sometimes pbranch, and grumbling about how I missed Git.
But there is some gold in this document.
gps has been doing some killer work documenting best practices with Mercurial, and this document is one of the results of his labour.
watchman is a tool that some folks at Facebook wrote to monitor changes in a folder. hgwatchman is an extension for Mercurial that takes advantage of watchman for a repository, smartly precomputing a bunch of stuff when the folder changes so that when you fire a command, likehg status
It takes a fraction of the time it’d take without hgwatchman. A fraction.
Here’s how I set hgwatchman up on my MacBook (though you should probably go by the Mercurial for Mozillians doc as the official reference):
- Install watchman with brew: brew install watchman
- Clone the hgwatchman extension to some folder that you can easily remember and build it: hg clone https://bitbucket.org/facebook/hgwatchman cd hgwatchman make local
- Add the following lines to my user .hgrc: [extensions] hgwatchman = cloned-in-dir/hgwatchman/hgwatchman
- Make sure the extension is properly installed by running: hg help extensions
- hgwatchman should be listed under “enabled extensions”. If it didn’t work, keep in mind that you want to target the hgwatchman directory
- And then in my mozilla-central .hg/.hgrc: [watchman] mode = on
- Boom, you’re done!
Congratulations, hg should feel snappier now!
On Firefox Hello, we recently added the eslint linter to be run against the Hello code base. We started of with a minimal set of rules, just enough to get us something running. Now we’re working on enabling more rules.
Since we enabled it, I feel like I’m able to iterate faster on patches. For example, if just as I finish typing I see something like:
Now I think about it, I’m realising it has also helped reduced the amount of review nits on my patches – due to trivial formatting mistakes being caught automatically, e.g. trailing white-space or missing semi-colons.
Talking about reviews, as we’re running eslint on the Hello code, we just have to apply the patch, and run our tests, and we automatically get eslint output:
Hopefully our patch authors will be running eslint before uploading the patch anyway, but this is an additional test, and a few less things that we need to look at during review which helps speed up that cycle as well.
I’ve also put together a global config file for eslint (see below), that I use for outside of the Hello code, on the rest of the Firefox code base (and other projects). This is enough, that, when using it in my editor it gives me a reasonable amount of information about bad syntax, without complaining about everything.
I would definitely recommend giving it a try. My patches feel faster overall, and my test runs are for testing, not stupid-mistake catching!
Want more specific details about the setup and advantages? Read on…
You need to have eslint installed globally, or at least in your path, other than that, just follow the installation instructions given on the SublimeLinter page.
One configuration I change I did have to make to the global configuration:
- Select “Preferences” -> “Settings – More” -> “Syntax Specific – User”
- In the file that appears, set the configuration up as follows (or whatever suits you):
I’ve uploaded my global configuration to a gist, if it changes I’ll update it there. It isn’t intended to catch everything – there’s too many inconsistencies across the code base for that to be sensible at the moment. However, it does at least allow general syntax issues to be highlighted for most files – which is obviously useful in itself.
I haven’t yet tried running it across the whole code base via eslint on the command line – there seems to be some sort of configuration issue that is messing it up and I’ve not tracked it down yet.
Firefox Hello’s Configuration
The configuration files for Hello can be found in the mozilla-central source. There’s a few of these because we have both content and chrome code, and some of the content code is shared with a website that can be viewed by most browsers, and hence isn’t currently able to use all the es6 features, whereas the chrome code can. This is another thing that eslint is good for enforcing.
Our eslint configuration is evolving at the moment, as we enable more rules, which we’re tracking in this bug.
Last week I gave a talk at the Philly Tech Week 2015 Dev Day organized by the delightful people at technical.ly on some of the tricks/strategies we use in the Firefox OS Gaia Email app. Note that the credit for implementing most of these techniques goes to the owner of the Email app’s front-end, James Burke. Also, a special shout-out to Vivien for the initial DOM Worker patches for the email app.
I tried to avoid having slides that both I would be reading aloud as the audience read silently, so instead of slides to share, I have the talk script. Well, I also have the slides here, but there’s not much to them. The headings below are the content of the slides, except for the one time I inline some code. Note that the live presentation must have differed slightly, because I’m sure I’m much more witty and clever in person than this script would make it seem…
Cover Slide: Who!
Hi, my name is Andrew Sutherland. I work at Mozilla on the Firefox OS Email Application. I’m here to share some strategies we used to make our HTML5 app Seem faster and sometimes actually Be faster.
What’s A Firefox OS (Screenshot Slide)
Here are some screenshots. We’ve got the default home screen app, the clock app, and of course, the email app.
It’s an entirely client-side offline email application, supporting IMAP4, POP3, and ActiveSync. The goal, like all Firefox OS apps shipped with the phone, is to give native apps on other platforms a run for their money.
And that begins with starting up fast.
Fast Startup: The Problems
But that’s frequently easier said than done. Slow-loading websites are still very much a thing.
The good news for the email application is that a slow network isn’t one of its problems. It’s pre-loaded on the phone. And even if it wasn’t, because of the security implications of the TCP Web API and the difficulty of explaining this risk to users in a way they won’t just click through, any TCP-using app needs to be a cryptographically signed zip file approved by a marketplace. So we do load directly from flash.
It adds up in the form of event loop activity and competition with other threads and processes. With the exception of Promises which get their own micro-task queue fast-lane, the web execution model is the same as all other UI event loops; events get scheduled and then executed in the same order they are scheduled. Loading data from an asynchronous API like IndexedDB means that your read result gets in line behind everything else that’s scheduled. And in the case of the bulk of shipped Firefox OS devices, we only have a single processor core so the thread and process contention do come into play.
So we try not to be a naive.
Seeming Fast at Startup: The HTML Cache
If we’re going to optimize startup, it’s good to start with what the user sees. Once an account exists for the email app, at startup we display the default account’s inbox folder.
What is the least amount of work that we can do to show that? Cache a screenshot of the Inbox. The problem with that, of course, is that a static screenshot is indistinguishable from an unresponsive application.
Local Storage: Okay in small doses
We implement this by storing the HTML in localStorage.
Important Disclaimer! LocalStorage is a bad API. It’s a bad API because it’s synchronous. You can read any value stored in it at any time, without waiting for a callback. Which means if the data is not in memory the browser needs to block its event loop or spin a nested event loop until the data has been read from disk. Browsers avoid this now by trying to preload the Entire contents of local storage for your origin into memory as soon as they know your page is being loaded. And then they keep that information, ALL of it, in memory until your page is gone.
So if you store a megabyte of data in local storage, that’s a megabyte of data that needs to be loaded in its entirety before you can use any of it, and that hangs around in scarce phone memory.
To really make the point: do not use local storage, at least not directly. Use a library like localForage that will use IndexedDB when available, and then fails over to WebSQLDatabase and local storage in that order.
Now, having sufficiently warned you of the terrible evils of local storage, I can say with a sorta-clear conscience… there are upsides in this very specific case.
The synchronous nature of the API means that once we get our turn in the event loop we can act immediately. There’s no waiting around for an IndexedDB read result to gets its turn on the event loop.
This matters because although the concept of loading is simple from a User Experience perspective, there’s no standard to back it up right now. Firefox OS’s UX desires are very straightforward. When you tap on an app, we zoom it in. Until the app is loaded we display the app’s icon in the center of the screen. Unfortunately the standards are still assuming that the content is right there in the HTML. This works well for document-based web pages or server-powered web apps where the contents of the page are baked in. They work less well for client-only web apps where the content lives in a database and has to be dynamically retrieved.
The two events that exist are:
“DOMContentLoaded” fires when the document has been fully parsed and all scripts not tagged as “async” have run. If there were stylesheets referenced prior to the script tags, the script tags will wait for the stylesheet loads.
“load” fires when the document has been fully loaded; stylesheets, images, everything.
But none of these have anything to do with the content in the page saying it’s actually done. This matters because these standards also say nothing about IndexedDB reads or the like. We tried to create a standards consensus around this, but it’s not there yet. So Firefox OS just uses the “load” event to decide an app or page has finished loading and it can stop showing your app icon. This largely avoids the dreaded “flash of unstyled content” problem, but it also means that your webpage or app needs to deal with this period of time by displaying a loading UI or just accepting a potentially awkward transient UI state.
(Trivial HTML slide)<link rel=”stylesheet” ...> <script ...></script> DOMContentLoaded!
This is the important summary of our index.html.
We reference our stylesheet first. It includes all of our styles. We never dynamically load stylesheets because that compels a style recalculation for all nodes and potentially a reflow. We would have to have an awful lot of style declarations before considering that.
Then we have our single script file. Because the stylesheet precedes the script, our script will not execute until the stylesheet has been loaded. Then our script runs and we synchronously insert our HTML from local storage. Then DOMContentLoaded can fire. At this point the layout engine has enough information to perform a style recalculation and determine what CSS-referenced image resources need to be loaded for buttons and icons, then those load, and then we’re good to be displayed as the “load” event can fire.
After that, we’re displaying an interactive-ish HTML document. You can scroll, you can press on buttons and the :active state will apply. So things seem real.
Being Fast: Lazy Loading and Optimized Layers
But now we need to try and get some logic in place as quickly as possible that will actually cash the checks that real-looking HTML UI is writing. And the key to that is only loading what you need when you need it, and trying to get it to load as quickly as possible.
There are many module loading and build optimizing tools out there, and most frameworks have a preferred or required way of handling this. We used the RequireJS family of Asynchronous Module Definition loaders, specifically the alameda loader and the r-dot-js optimizer.
One of the niceties of the loader plugin model is that we are able to express resource dependencies as well as code dependencies.
RequireJS Loader Pluginsvar fooModule = require('./foo'); var htmlString = require('text!./foo.html'); var localizedDomNode = require('tmpl!./foo.html');
The standard Common JS loader semantics used by node.js and io.js are the first one you see here. Load the module, return its exports.
But RequireJS loader plugins also allow us to do things like the second line where the exclamation point indicates that the load should occur using a loader plugin, which is itself a module that conforms to the loader plugin contract. In this case it’s saying load the file foo.html as raw text and return it as a string.
But, wait, there’s more! loader plugins can do more than that. The third example uses a loader that loads the HTML file using the ‘text’ plugin under the hood, creates an HTML document fragment, and pre-localizes it using our localization library. And this works un-optimized in a browser, no compilation step needed, but it can also be optimized.
We then also run the optimizer against our other important cards like the “compose” card and the “message reader” card. We don’t do this for all cards because it can be hard to carve up the module dependency graph for optimization without starting to run into cases of overlap where many optimized files redundantly include files loaded by other optimized files.
Plus, we have another trick up our sleeve:
Seeming Fast: Preloading
Preloading. Our cards optionally know the other cards they can load. So once we display a card, we can kick off a preload of the cards that might potentially be displayed. For example, the message list card can trigger the compose card and the message reader card, so we can trigger a preload of both of those.
But we don’t go overboard with preloading in the frontend because we still haven’t actually loaded the back-end that actually does all the emaily email stuff. The back-end is also chopped up into optimized layers along account type lines and online/offline needs, but the main optimized JS file still weighs in at something like 17 thousand lines of code with newlines retained.
So once our UI logic is loaded, it’s time to kick-off loading the back-end. And in order to avoid impacting the responsiveness of the UI both while it loads and when we’re doing steady-state processing, we run it in a DOM Worker.
Being Responsive: Workers and SharedWorkers
DOM Workers are background JS threads that lack access to the page’s DOM, communicating with their owning page via message passing with postMessage. Normal workers are owned by a single page. SharedWorkers can be accessed via multiple pages from the same document origin.
By doing this, we stay out of the way of the main thread. This is getting less important as browser engines support Asynchronous Panning & Zooming or “APZ” with hardware-accelerated composition, tile-based rendering, and all that good stuff. (Some might even call it magic.)
When Firefox OS started, we didn’t have APZ, so any main-thread logic had the serious potential to result in janky scrolling and the impossibility of rendering at 60 frames per second. It’s a lot easier to get 60 frames-per-second now, but even asynchronous pan and zoom potentially has to wait on dispatching an event to the main thread to figure out if the user’s tap is going to be consumed by app logic and preventDefault called on it. APZ does this because it needs to know whether it should start scrolling or not.
And speaking of 60 frames-per-second…
Being Fast: Virtual List Widgets
…the heart of a mail application is the message list. The expected UX is to be able to fling your way through the entire list of what the email app knows about and see the messages there, just like you would on a native app.
This is admittedly one of the areas where native apps have it easier. There are usually list widgets that explicitly have a contract that says they request data on an as-needed basis. They potentially even include data bindings so you can just point them at a data-store.
But HTML doesn’t yet have a concept of instantiate-on-demand for the DOM, although it’s being discussed by Firefox layout engine developers. For app purposes, the DOM is a scene graph. An extremely capable scene graph that can handle huge documents, but there are footguns and it’s arguably better to err on the side of fewer DOM nodes.
So what the email app does is we create a scroll-region div and explicitly size it based on the number of messages in the mail folder we’re displaying. We create and render enough message summary nodes to cover the current screen, 3 screens worth of messages in the direction we’re scrolling, and then we also retain up to 3 screens worth in the direction we scrolled from. We also pre-fetch 2 more screens worth of messages from the database. These constants were arrived at experimentally on prototype devices.
We listen to “scroll” events and issue database requests and move DOM nodes around and update them as the user scrolls. For any potentially jarring or expensive transitions such as coordinate space changes from new messages being added above the current scroll position, we wait for scrolling to stop.
Nodes are absolutely positioned within the scroll area using their ‘top’ style but translation transforms also work. We remove nodes from the DOM, then update their position and their state before re-appending them. We do this because the browser APZ logic tries to be clever and figure out how to create an efficient series of layers so that it can pre-paint as much of the DOM as possible in graphic buffers, AKA layers, that can be efficiently composited by the GPU. Its goal is that when the user is scrolling, or something is being animated, that it can just move the layers around the screen or adjust their opacity or other transforms without having to ask the layout engine to re-render portions of the DOM.
When our message elements are added to the DOM with an already-initialized absolute position, the APZ logic lumps them together as something it can paint in a single layer along with the other elements in the scrolling region. But if we start moving them around while they’re still in the DOM, the layerization logic decides that they might want to independently move around more in the future and so each message item ends up in its own layer. This slows things down. But by removing them and re-adding them it sees them as new with static positions and decides that it can lump them all together in a single layer. Really, we could just create new DOM nodes, but we produce slightly less garbage this way and in the event there’s a bug, it’s nicer to mess up with 30 DOM nodes displayed incorrectly rather than 3 million.
But as neat as the layerization stuff is to know about on its own, I really mention it to underscore 2 suggestions:
1, Use a library when possible. Getting on and staying on APZ fast-paths is not trivial, especially across browser engines. So it’s a very good idea to use a library rather than rolling your own.
2, Use developer tools. APZ is tricky to reason about and even the developers who write the Async pan & zoom logic can be surprised by what happens in complex real-world situations. And there ARE developer tools available that help you avoid needing to reason about this. Firefox OS has easy on-device developer tools that can help diagnose what’s going on or at least help tell you whether you’re making things faster or slower:
– it’s got a frames-per-second overlay; you do need to scroll like mad to get the system to want to render 60 frames-per-second, but it makes it clear what the net result is
– it has paint flashing that overlays random colors every time it paints the DOM into a layer. If the screen is flashing like a discotheque or has a lot of smeared rainbows, you know something’s wrong because the APZ logic is not able to to just reuse its layers.
– devtools can enable drawing cool colored borders around the layers APZ has created so you can see if layerization is doing something crazy
There’s also fancier and more complicated tools in Firefox and other browsers like Google Chrome to let you see what got painted, what the layer tree looks like, et cetera.
And that’s my spiel.
The source code to Gaia can be found at https://github.com/mozilla-b2g/gaia
The email app in particular can be found at https://github.com/mozilla-b2g/gaia/tree/master/apps/email
(I also asked for questions here.)
It’s that time of year again, we have a new major release of Lightning on the horizon. About every 42 weeks, Thunderbird prepares for a major release, we follow up with a matching major version. You may know these as Lightning 2.6 or 3.3.In order to avoid disappointments, we do a series of beta releases before a such major release. This is where we need you. Please help out in making Lightning 4.0 a great success.Time flies when you are preparing for releases, so we are already at Thunderbird 38.0b3 and Lightning 4.0b3. The final release will be on May 12th and there will be at least one more beta. Please download these betas and take a moment to go through all the actions you normally do on a daily basis. Create an event, accept an invitation, complete a task. You probably have your own workflow, these are of course just examples.
Here is how to get the builds. If you have found an issue, you can either leave a comment here or file a bug on bugzilla.
- Thunderbird Beta: https://www.mozilla.org/thunderbird/all-beta.html
- You can directly select the beta version for your language on this page
- Lightning Beta: https://addons.mozilla.org/thunderbird/addon/lightning/
- Scroll down to the “Developer Channel”, expand the box and click on the download button
You may wonder what is new. I’ve gone through the bugs fixed since 3.3 and found that most issues are backend fixes that won’t be very visible. We do however have a great new feature to save copies of invitations to your calendar. This helps in case you don’t care about replying to the invitation but would still like to see it in your calendar. We also have more general improvements in invitation compatibility, performance and stability and some slight visual enhancements. The full list of changes can be found on bugzilla.
Although its highly unlikely that severe problems will arise, you are encouraged to make a backup before switching to beta. If it comforts you, I am using beta builds for my production profile and I don’t recall there being a time where I lost events or had to start over.
If you have questions or have found a bug, feel free to leave a comment here.
I guess that mostly comes from the impression that the whole story is our government watching (over) us and the worst thing that can happen is incrimination. While that might threaten some things, most people do nothing that is really interesting enough for a government to go into attack mode over it (or so they believe, and very firmly so). And I even agree that most governments (including the US and EU countries) actually actively seek out what they call "terrorist activities" (even though they often stretch that term in crazy ways) and/or child abuse and similar topics that the vast majority of citizens agree are a bad thing and are not part of - and the vast majority of politicians and government workers believe they act in the best interest of their citizens when "obviously fighting that" via their different programs of privacy-undermining surveillance. That said, most people seem to be OK with their government collecting data about them as long as it's not used to incriminate them (and when that happens, it's too late to protest the practice anyhow).
A lot has been said about that since the "Snowden leaks", but I think the more obvious short-term and direct threat is in corporate surveillance, which has been swept under the rug in most discussions recently - to the joy of Facebook, Google and other major players in that area. I have also seen that when depicting some obvious scenarios resulting of that, people start to think about it much more promptly and realize the effect on their daily lives (even if those are minor issues compared to government starting a manhunt against you with terror allegations or similar).
So what I start asking is:
- Are you OK with banks determining your credit conditions based on all his comments on Facebook and his Google searches? ("Your friends say you owe them money, and that you live beyond your means, this is gonna be difficult...")
- Are you OK with insurances changing your rates based on all that data? ("Oh, so you 'like' all those videos about dangerous sports and that deafening music, and you have some quite aggressive or even violent friends - so you see why we need to go a bit higher there, right?")
- Are you OK with prices for flights or products in online stores (Amazon etc.) being different depending on what other things you have done on the web? ("So, you already planned that vacation at that location, good, so we can give you a higher air rate as you' can't back out now anyhow.")
- And, of course, envision ads in public or half-public locations being customized for whoever is in the area. ("You recently searched for engagement rings, so we'll show ads for them wherever you go." or "Hey, this is the third time today we sat down and a screen nearby shows Viagra ads." or "My dear daughter, why do we see ads for diapers everywhere we go?")
And, of course, they are true to a degree even now. Banks are already buying data from Facebook, probably including "private" messages, for determining credit scores, insurances base rates on anything they can find out about you, flight rates as well as prices for some Amazon and other web shop products vary based on what you searched before - and ads both on your screen and even on postal mail get tailored to a profile built on all kinds of your online behavior. My questions above just take all of those another step forward - but a pretty realistic one in my opinion.
I hope thinking about questions like that makes people realize they might actually want to evade some of that and in the end they actually have something to hide.
And then, of course, that a non-profit like Mozilla, which doesn't seek to maximize money, can believably be on their side and help them regain some privacy where they - now - want to.