During July I’ll be visiting family in Mongolia but I’ve also a few things that are very geeky that I want to do.
The first thing I want to do is plug the Ripe Atlas probes I have. It’s litle devices that look like that :
They enable anybody with a ripe atlas or ripe account to make measurements for dns queries and others. This helps making a global better internet. I have three of these probes I’d like to install. It’s good because last time I checked Mongolia didn’t have any active probe. These probes will also help Internet become better in Mongolia. I’ll need to buy some network cables before leaving because finding these in mongolia is going to be challenging. More on atlas at https://atlas.ripe.net/.
The second thing I intend to do is map Mongolia a bit better on two projects the first is related to Mozilla and maps gps coordinateswith wifi access point. Only a little part of The capital Ulaanbaatar is covered as per https://location.services.mozilla.com/map#11/47.8740/106.9485 I want this to be way more because having an open data source for this is important in the future. As mapping is my new thing I’ll probably edit Openstreetmap in order to make the urban parts of mongolia that I’ll visit way more usable on all the services that use OSM as a source of truth. There is already a project to map the capital city at http://hotosm.org/projects/mongolia_mapping_ulaanbaatar but I believe osm can server more than just 50% of mongolia’s population.
I got inspired to write this post by mu son this morning, look what he is doing at 17 months :
Thunderbird meeting notes 2015-05-05. NOON PT (Pacific). Check https://wiki.mozilla.org/Thunderbird/StatusMeetings for meeting time conversion, previous meeting notes and call-in detailsAttendees
aceman, aleth, Jorg K, merike, rkent, roland, wsmwk, MakeMyDay, rolandtanglaoAction items from last meetings
- (done) wsmwk to pat glandium
- (done) wsmwk to email hiro’s bug list to tb-planning
- (done) rkent to review tracking list http://mzl.la/1EOx9Tm
Critical bugs. Leave these here until they’re confirmed fixed. If confirmed, then remove.
- AMO compatibility bump! (is not going to happen)
- In general, the tracking-tb38 flag shows what are critical issues. In the next week or so, that list will be culled to only include true blockers for the Thunderbird 38 release. There will still be many.
- maildir UI: nothing more to do for UI, still want to land a patch for letting IMAP set this.
- gloda IM search regressions: mostly fixed, some db cleanup necessary for users of TB33+
- aleth landed a fix to stop duplicated entries from appearing, nhnt11 patch to clean up the databases of Aurora/Beta/Daily has landed and is awaiting uplift
removing from critical list/fixed:
- We need to decide on how to do release branching. I am uncertain whether Lightning integration requires this or not.
- –> We’ve created THUNDERBIRD_38_VERBRANCH on mozilla-release
- Lightning integration (below) really REALLY critical that we get this finished.
- –> Patches landed, testing beta 2015-04-30
- 31.6.0 shipped
- 38.0b3 shipped 2015-04-26 Sunday
- 38.0b4 shipped 2015-05-03 Sunday
- 38.0b5 (build Fri 5/8? when?)
- 38.0 on May 26?
- 31.7.0 2015-05-12+ Tues+
- As underpass has pointed out repeatedly (thanks for your patience!) , we need to rewrite / heavily modify the lightning articles on support.mozilla.org. let me know irc: rolandtanglao on #tb-support-crew or rtanglao AT mozilla.com OR simply start editing the articles
- We need to fill the “Learn More” page with content, possibly point it to something more specific bug 1159682
- Opt-out dialog: change “disable” to “remove” bug 1159698
- tracking bug for lightning 4.0 bug 1153752
- Thunderbird Events calendar created – send me your events to be added/corrections
- xml https://www.google.com/calendar/feeds/mozilla.com_707562313030%40resource.calendar.google.com/public/basic
- ical https://www.google.com/calendar/ical/mozilla.com_707562313030%40resource.calendar.google.com/public/basic.ics (For google calendar, on the google web page pick “Other Calendars”, “Add by URL”, paste in the ical link – enable email or sms reminders if you wish in Settings | Calendar)
- html https://www.google.com/calendar/embed?src=mozilla.com_707562313030%40resource.calendar.google.com
- Mail composition/spelling: bug 967494, bug 717292 (inline spell dictionary inconsistent), waiting for review by M Conley.
- Editor losing style after image paste: bug 1140617
- bug 1141446 – JSMIME regression, still awaiting final review
- Today looked at “double Trash” issue 1156669
- rail in releng seems to believe that we cannot overlap tb 31 and tb 38 and claims that was the previous practice, but Standard8 does not remember this the same way. At the moment I have been told that we cannot start building on the esr38 repo without disabling builds on esr31. This is still a developing story … until resolved I think we need to keep using comm-beta for TB 38 betas.
- we have a backlog of jsmime issues, jcranmer has been quite tied up with real life. Several of us have been trying to fix these, but we need reviews.
- Let’s review the critical tracking-38 bugs (29 at last count) http://mzl.la/1EOx9Tm
- thunderbird hotfix support – bug 914225 ready to land
— PLEASE INCLUDE YOUR NICK with your bullet item —aleth
Some testing/verification that chat logs are now being properly and completely indexed by gloda would be helpful, cf bug 1146698 (landed on c-c, a possible candidate for uplift).Support team
- Roland owes sumo kb article links for release notes. Hope to have stub articles ready today
- PLEASE PUT THE NEXT MEETING IN YOUR (LIGHTNING) CALENDAR
- Note – meeting notes must be copied from etherpad to wiki before 5AM CET next day so that they will go public in the meeting notes blog.
Have you been using Firefox Nightly and seen this big annoying spinner?
I hate that thing. I hate it.
And while we’re working on making the spinner itself less ugly, I’d like to eliminate, or at least reduce its presence to the absolute minimum.
How do I do that? Well, first, know your enemy.What does it even mean?
That big spinner means that the graphics part of Gecko hasn’t given us a frame yet to paint for this browser tab. That means we have nothing yet to show for the tab you’ve selected.
In the single-process Firefox that we ship today, this graphics operation of preparing a frame is something that Firefox will block on, so the tab will just not switch until the frame is ready. In fact, I’m pretty sure the whole browser will become unresponsive until the frame is ready.
With Electrolysis / multi-process Firefox, things are a bit different. The main browser process tells the content process, “Hey, I want to show the content associated with the tab that the user just selected”, and the content process computes what should be shown, and when the frame is ready, the parent process hears about it and the switch is complete. During that waiting time, the rest of the browser is still responsive – we do not block on it.
So there’s this window of time where the tab switch has been requested, and when the frame is ready.
During that window of time, we keep showing the currently selected tab. If, however, 300ms passes, and we still haven’t gotten a frame to paint, that’s when we show the big spinner.
So that’s what the big spinner means – we waited 300ms, and we still have no frame to draw to the screen.How bad is it?
I suspect it varies. I see the spinner a lot less on my Windows machine than on my MacBook, so I suspect that performance is somehow worse on OS X than on Windows. But that’s purely subjective. We’ve recently landed some Telemetry probes to try to get a better sense of how often the spinner is showing up, and how laggy our tab switching really is. Hopefully we’ll get some useful data out of that, and as we work to improve tab switch times, we’ll see improvement in our Telemetry numbers as well.Where is the badness coming from?
I also seem to see the spinner when I have “many” tabs open (~30), and have a build going on in the background (so my machine is under heavy load).
Maybe we’re just doing things inefficiently in the multi-process case. I recently landed profile markers for the Gecko Profiler for async tab switching, to help figure out what’s going on when I experience slow tab switch. Maybe there are optimizations we can make there.
One thing I’ve noticed is that there’s this function in the graphics layer, “ClientTiledLayerBuffer::ValidateTile”, that takes much, much longer in the content process than in the single-process case. I’ve filed a bug on that, and I’ll ask folks from the Graphics Team this week.How you can help
UPDATE (June 1, 2015): Getting profiles from Windows is currently broken because the symbol server appears to be busted. Any profiles from Windows machines will be useless until this bug is fixed. Alternatively, set profiler.symbolicationUrl to http://symbolapi.mocotoolsstaging.net in about:config.
If you’d like to help me find more potential causes, Profiles are very useful! NOTE – I don’t mean “user profiles”, as in, your bookmarks / customizations / history, etc, in the profile folder. I don’t mean this thing. I mean a performance profile.
A performance profile is a read-out of everything that Firefox / Gecko is doing over a particular span of time. When the profiler is running, Firefox / Gecko will record where the process is in the stack every 1ms or so. It’ll also record information about how long since it’s serviced the event loop, which helps us find jank.
To help, grab the Gecko Profiler add-on, make sure it’s enabled, and then dump a profile when you see the big spinner of doom. The interesting part will be between two markers, “AsyncTabSwitch:Start” and “AsyncTabSwitch:Finish”. There are also markers for when the parent process displays the spinner – “AsyncTabSwitch:SpinnerShown” and “AsyncTabSwitch:SpinnerHidden”. The interesting stuff, I believe, will be in the “Content” section of the profile between those markers. Here are more comprehensive instructions on using the Gecko Profiler add-on.
And here’s a video of me demonstrating how to use the profiler, and how to attach a profile to the bug where we’re working on improving tab switch times:
So hopefully we’ll get some useful data, and we can drive instances of this spinner into the ground.
I’d really like that.