De Nederlandse
Mozilla-gemeenschap

As discussed in the previous post, the HTML-based UI for editing events and tasks in a tab is still a work in progress that is in a fairly early stage and not something you could use yet.  (However, for any curious folks living on the bleeding edge who might still want to check it out, the previous post also describes how to activate it.)  This post relates to its implementation, namely the use of React, “a Javascript library for building user interfaces.”

For the HTML UI we decided to use React (but not JSX which is often paired with it).  React basically provides a nice declarative way to define composable, reusable UI components (like a tab strip, a text box, or a drop down menu) that you use to create a UI.  These are some of its main advantages over “raw” HTML.  It’s also quite efficient / fast and is a library that does one thing well and can be combined with other technologies (as compared with more monolithic frameworks).  I enjoyed using and learning about React.  Once you understand its basic model of state management and how the components work it is not very difficult or complicated to use.  I found its documentation to be quite good, and I liked how it lets you do everything in Javascript, since it generates the HTML for the UI dynamically.

One of the biggest differences when using React is that instead of storing state in DOM elements and querying them for their state (as we currently do), the app state is centralized in a top-level React component and from there it gets automatically distributed to various child components.  When the state changes (on user input) React automatically updates the UI to reflect those changes.  To do this it uses an internal “virtual DOM” which is basically a representation of the state of the DOM in Javascript.  When there are changes it compares the previous version of that virtual DOM with the new version to decide what changes need to be made to the actual DOM.  (Because the actual DOM is quite slow compared to Javascript, this approach gives React an advantage in terms of performance.)  Centralizing the app state in this way simplifies things considerably.  Direct interaction with DOM elements is not needed, and is actually an anti-pattern.

One example of the power and flexibility that React offers is that I actually did the “responsive design” part of the HTML UI with React rather than CSS.  The reason was that some of the UI components had to move to different positions in the UI when transitioning between the narrow and wide layouts for different window sizes.  This was not really possible with CSS, at least not without overly complex workarounds.  However, it was simple to do it with React because React can easily re-render the UI in any configuration you define, in this case in response to resizing the window past a certain threshold.  (Once CSS grid layout is available this kind of repositioning will be straightforward to do with CSS.)

React’s different approach to state does present some challenges for using it with existing code.  For this project at least it is not simply a matter of dropping it in and having it work, rather using it will entail some non-trivial code refactoring.  Basically, the code will need to be separated out into different jobs.  First there’s (1) interacting with the outside of the iframe (e.g. toolbar, menubar, statusbar) and (2) modifying and/or formatting the event or task data.  These are needed for both the XUL and HTML UIs.  Next there’s (3) updating and interacting with the XUL UI inside the iframe.  Currently these things (1, 2, and 3) are usually closely intertwined, for example in a single function.  Then there is (4) using React to define components and how they respond to changes to the app state, and (5) updating and interacting with the HTML UI inside the iframe (i.e. read from or write to the app state in the top-level React component).  So there is some significant refactoring work to do, but after it is done the code should be more robust and maintainable.

Despite the refactoring work that may be involved, I think that React has a lot to offer for future UI work for Calendar or Thunderbird as an alternative to XUL.  Especially for code that involves managing a lot of state (like the current project) using React and its approach should reduce complexity and make the code more maintainable.  Also, because it mostly involves using Javascript this simplifies things for developers.  When CSS grid layout is available that will also strengthen the case for HTML UI work since it will offer greater control over the layout and appearance of the UI.

I’ll close with links to two blog posts and a video about React that I found helpful:

• Removing User Interface Complexity, or Why React is Awesome
• Firefox Hello Desktop: Behind the Scenes – Flux and React
• Video: “Cleaning the Tar: Using React within the Firefox Developer Tools” talk by James Long

— Paul Morris

It’s hard to believe it is already late August and this year’s Google Summer of Code is all wrapped up.  The past couple of months have really flown by.  In the previous post I summarized the feedback we received on the new UI design and discussed the work I’ve been doing to port the current UI (for editing events and tasks) to a tab.  In this post I’ll describe how to try out this new feature in a development version of Thunderbird, and give an update on the HTML implementation of the new UI design. In my next post I’ll share some thoughts on using React for the HTML UI.

To try out editing events and tasks in a tab instead of in a dialog window you’ll need a development version of Thunderbird (aka: “Daily”).  Since it is a development version you will want to use a separate profile and/or make sure your data is backed up.  Once you have that all set up, you can turn on the “event in a tab” feature with a hidden preference.  To access hidden preferences, go to Preferences > Advanced > Config Editor, and then search for “calendar.item.editInTab” and toggle it to true by double-clicking on it.

Or if that’s too much trouble you can just wait until it arrives in the next stable release of Thunderbird/Lightning.  In the meantime, here’s what it looks like (click to enlarge):

The screenshot above shows the current XUL-based UI ported to a tab.  I ended up not having much time to work on the new HTML-based UI (actually only a week or so) and did not get as far on it as I’d hoped — only as far as a basic and preliminary implementation, a starting point for further development rather than something that can be used today.  For example, it does not yet support saving changes and not all of the data is loaded into the UI for a given event or task.

Some aspects do already work, like the responsive design where the UI changes to adapt to the width of the window, taking more advantage of the greater space available in a tab.  Here are two screen shots that show the wide and narrow views (click to enlarge).

Even though the HTML UI is not ready for use yet, we decided to go ahead and land it in the code base as a work-in-progress for further development.  So if you are curious to see where it stands, it can also be turned on with a hidden preference (“calendar.item.useNewItemUI”) in a current development version of Thunderbird, as described above.  Again, be sure to use a separate profile and/or make sure your data is backed up.

For more technical details about the project, including some high-level documentation I wrote for this part of the code, see the meta bug, especially my comment #2 which summarizes the state of things as of the end of the Summer of Code period.

It was a great summer working on this project.  I learned a lot and enjoyed contributing.  As my time permits, I hope to continue to contribute and finish the implementation of the new UI.  Many thanks to Google, Mozilla, and especially to my mentors Philipp Kewisch (Fallen) and MakeMyDay for their guidance and tireless willingness to answer my questions and review code.  Also thanks to Richard Marti (Paenglab) for his help and feedback on the UI design work.

I wish there was another month of the official coding period to get the HTML implementation further along, but alas, so far we’ve only been able to help people manage their time, not actually generate more of it.

— Paul Morris

The clock has run out on Google Summer of Code 2016.  In this post I’ll summarize the feedback we received on the new UI design and the work I’ve been doing since my last post.

Feedback on the New UI Design

A number of people shared their feedback on the new UI design by posting comments on the previous blog post.  The response was generally positive.  Here’s a brief summary:

• One commenter advocated for keeping the current date/time picker design, while another just wanted to be sure to keep quick and easy text entry.
• A question about how attendees availability would be shown (same as it is currently).
• A request to consider following Google Calendar’s reminders UI.
• A question about preserving the vertical scroll position across different tabs (this should not be a problem).
• A concern about how the design would scale for very large numbers (say hundreds) of attendees, categories, reminders, etc.  (See my reply.)

Thanks to everyone who took the time to share their thoughts.  It is helpful to hear different views and get user input.  If you have not weighed in yet, feel free to do so, as more feedback is always welcome.  See the previous blog post for more details.

Coding the Summer Away

A lot has happened over the last couple months.  The big news is that I finished porting the current UI from the window dialog to a tab.  Here’s a screenshot of this XUL-based implementation of the UI in a tab (click to enlarge):

Getting this working in a really polished way took more time than I anticipated, largely because the code had to be refactored so that the majority of the UI lives inside an iframe.  This entailed using asynchronous message passing for communication between the iframe’s contents and its outer parent context (e.g. toolbars, menus, statusbar, etc.), whether that context is a tab or a dialog window.  While this is not a visible change, it was necessary to prepare the way for the new HTML-based design, where an HTML file will be loaded in the iframe instead of a XUL file.

Along with the iframe refactoring, there are also just a lot of details that go into providing an ideal user experience, all the little things we tend to take for granted when using software.  Here’s a list of some of these things that I worked on over the last months for the XUL implementation:

• when switching tabs, update the toolbar and statusbar to reflect the current tab
• persist open tabs across application restarts (which requires serializing the tab state)
• ask the user about saving changes before closing a tab, before closing the application window, and before quitting the application
• allow customizing toolbars with the new iframe setup
• provide a default window dialog height and width with the new iframe setup
• display icons for tabs and related CSS/style work
• get the relevant ‘Events and Tasks’ menu items to work for a task in a tab
• allow hiding and showing the toolbar from the view > toolbars menu
• if the user has customized their toolbar for the window dialog, migrate those settings to the tab toolbar on upgrade
• fix existing mozmill tests so they work with the new iframe setup
• test for regressions in SeaMonkey

In the next two posts I’ll describe how to try out this new feature in a development version of Thunderbird, discuss the HTML implementation of the new UI design, and share some thoughts on using React for the HTML implementation.

— Paul Morris

As you can see on the Event in a Tab wiki page, I have created a number of mockups, labeled A through N, for the new UI for creating, viewing, and editing calendar events and tasks.  (This has given me a lot of practice using Inkscape!)  The final design will be implemented in the second phase of the project.  So far the revisions have been based on valuable feedback from Paenglab and MakeMyDay (thanks!), and we are now seeking broader feedback from users on the latest and greatest mockup “N” (click to view full size):

Event in a Tab, UI Design, Mockup “N”

Please take a look and send any feedback, comments, suggestions, questions, etc. to the calendar mailing list / newsgroup where we will be discussing the design, or you can leave a comment on this blog post, send a private email to mozilla@kewis.ch, or reach us via IRC (in Mozilla’s #calendar channel).

Here are some notes and details about the behavior of the proposed UI that are not apparent from a static image.

The mockup is intended as a relatively rough “wire frame” to show layout and it only approximates spacing, sizing, and aesthetic details. Unless otherwise noted, functionality is the same as in the current Lightning add-on.

A responsive design approach will be used to implement this UI in HTML. As the window expands horizontally, the elements will expand with it up to a breakpoint where the two-column “tab” layout goes into effect. Then the elements will continue to expand in both of the columns, up to a certain maximum limit at which they would expand no further. (Having this limit will keep things more focused on very wide monitors/windows.)

For vertical scrolling in a tab… Categories, Reminders, Attachments, Attendees, and Description can expand to take up as much vertical space as necessary to show all of their content. In most cases, where there are only a small number of these items, there will be enough room on the page to show them all without any scrolling. In less common cases where there are many items, the content of the tab will grow taller until it no longer fits vertically, and then the whole tab will become scrollable. (The toolbar at the top, with the buttons like “Save and Close,” will not scroll, remaining in place, still easily accessible.) This approach makes it possible to view all of the items at once when there are many of them (instead of having smaller boxes around each of these elements that are each independently scrollable).  This “whole tab scrolling” approach is how it works in Google Calendar.

For vertical scrolling in a dialog window…  When the contents of the tabbed box (Reminders, Attachments, Attendees, and Description) becomes too big to fit vertically, the tabbed box becomes scrollable.  (Suggestions are welcome for the name of the “More” tab in the window dialog.)

The mockup shows the new date/time picker that is being developed by Mozilla.  It remains to be seen whether it will be available in time for use in this project.  Another possibility is the date/time picker developed by Fastmail.

Progress Report on Coding

Besides working on the design for the UI, I have continued to work on porting the current event dialog UI to a tab.  I created a bug for this part of the first phase of the project, posted my first work-in-progress patch there, and am now working on the next iteration based on the feedback.

This work includes refactoring the current event dialog’s XUL file into more than one file to separate the main part of the UI from its menu bar, tool bar, and status bar items.  This more modular arrangement will make it possible to make the menu bar, tool bar, and status bar items appear in the correct places in the main Thunderbird window when displaying the UI in a tab.  This will solve the problem of the doubled status bar and menu bar in my first patch.

The next patch will also have a hidden preference (accessible via “about:config” but eventually to be added to Lightning’s preferences UI) that determines whether event and task dialogs are opened in a window or a tab by default.

So overall, things are progressing well, which is a good thing since there is only about a week or so left before the GSoC midterm milestone, and the goal is to have phase one of the project completed by that point.  After I have finished this initial “phase one” patch, and any follow-up work that needs to be done for it, we will reach a decision about whether to use XUL, Web Components, React.js, or “plain vanilla” HTML for the implementation of the new UI design, and then start working on implementing it.

— Paul Morris

Time for a progress report after my first week or so working on the Event in a Tab GSoC project. Things are going well so far. In short, I have the current event and task dialogs opening in a tab rather than a window and I can create and edit tasks and events in a tab. While not everything is working yet most things already are.

The trickiest part has been working with XUL, since I am not as familiar with it as I am with Javascript. With some help from Fallen on IRC I figured out how to register a new XUL document that contains an iframe and how to load another XUL file into this iframe. For an event or task that is editable one XUL file is loaded (calendar-event-dialog.xul), but if it is read-only then a different XUL file is loaded (calendar-summary-dialog.xul).

Initially I used the tabmail interface’s “shared tab” option — where a single XUL file is loaded and then its appearance and content is modified to create the appearance of completely different tabs. (This is how Thunderbird’s “3-pane” and “single message” tabs work, and also Lightning’s “Calendar” and “Tasks” tab.) However, this did not work when you opened multiple events/tasks in separate tabs. So I figured out the tabmail interface’s other option which loads each tab separately as you would expect and everything is now working fine.

The next step was to figure out how to access the data for an event (or task) from the tab. I actually figured out two ways to do this. The first was via the tabmail interface in the way that it is set up to work (i.e. “tabmail.currentTabInfo”). That meant that the current event dialog code (that referenced the data as a property of the “window” object) had to be changed to access it from this new location.  But that is not so good since we will be supporting both window and tab options and it would be nice if the same code could “just work” for both cases as much as possible.

So I figured out a second way to provide access to the data by just putting it in the right place relative to the iframe, so that the current code could reach it without having to be modified (i.e. still as a property of the “window” object, but with the “window” being relative to the iframe). This is a better approach since the same code will work for both cases (events/tasks in a dialog window or in a tab).

One small thing I implemented via the tabmail interface is that the title of the tab indicates whether you are creating a new item or modifying an existing one and whether the item is an event or a task. However, I will probably end up re-working this because the current dialog window code updates the title of the window as you change the title of the event/task, and that code can probably also be used to generate the initial title of the tab. This is something I will be looking into as I start to really work with the event dialog code.

On the UI design side of things, I created three new mockups based on some more feedback from Richard Marti and MakeMyDay. Part of the challenge is that there are a number of elements that vary in size depending on how many items they contain (e.g. reminders, categories, attachments, attendees). Mockups K and L were my attempt at a slightly different approach for handling this, although we will be following the design of mockup J going forward. You can take a look at these mockups and read notes about them on the wiki page.

The next steps will be to push toward a more finalized design and seek broader feedback on it.  On the coding side I will be identifying where things are not working yet and getting them to work. For example, the code for closing a window does not work from a tab and the status bar items are appearing just above the status bar (at the bottom of the window) because of the iframe.

So far I think things are going well. It is really encouraging that I am already able to create and modify events and tasks from a tab and that most of the basic functionality appears to be working fine.

— Paul Morris

Today is the first day of the “coding period” for Google Summer of Code 2016 and I’m excited to be working on the “Event in a Tab” project for Mozilla Calendar. The past month of the “community bonding period” has flown by as I made various preparations for the summer ahead. This post covers what I’ve been up to and my experience so far.

After the exciting news of my acceptance for GSoC I knew it was time to retire my venerable 2008 Apple laptop which had gotten somewhat slow and “long in the tooth.” Soon, with a newly refurbished 2014 laptop via Ebay in hand, I made the switch to GNU/Linux, dual-booting the latest Ubuntu 16.04. Having contributed to LilyPond before it felt familiar to fire up a terminal, follow the instructions for setting up my development environment, and build Thunderbird/Lightning. (I was even able to make a few improvements to the documentation – removed some obsolete info, fixed a typo, etc.) One difference from what I’m used to is using mercurial instead of git, although the two seem fairly similar. When I was preparing my application for GSoC my build succeeded but I only got a blank white window when opening Thunderbird. This time, thanks to some guidance from my mentor Philipp about selecting the revision to build, everything worked without any problems.

One of the highlights of the bonding period was meeting my mentors Philipp Kewisch (primary mentor) and MakeMyDay (secondary mentor). We had a video chat meeting to discuss the project and get me up to speed. They have been really supportive and helpful and I feel confident about the months ahead knowing that they “have my back.” That same day I also listened in on the Thunderbird meeting with Simon Phipps answering questions about his report on potential future legal homes for Thunderbird, which was an interesting discussion.

At this point I am feeling pretty well integrated into the Mozilla infrastructure after setting up a number of accounts – for Bugzilla, MDN, the Mozilla wiki, an LDAP account for making blog posts and later for commit access, etc. I got my feet wet with IRC (nick: pmorris), introduced myself on the Calendar dev team’s mailing list, and created a tracker bug and a wiki page for the project.

Following the Mozilla way of working in the open, the wiki page provides a public place to document the high-level details related to design, implementation, and the overall project plan. If you want to learn more about this “Event in a Tab” project, check out the wiki page.  It contains the mockup design that I made when applying for GSoC and my notes on the thinking behind it. I shared these with Richard Marti who is the resident expert on UI/UX for Thunderbird/Calendar and he gave me some good feedback and suggestions. I made a number of additional mockups for another round of feedback as we iterate towards the final design. One thing I have learned is that this kind of UI/UX design work is harder than it looks!

Additionally, I have been getting oriented with the code base and figuring out the first steps for the coding period, reading through XUL documentation and learning about Web Components and React, which are two options for an HTML implementation. It turns out there is a student team working on a new version of Thunderbird’s address book and they are also interested in using React, so there will be a larger conversation with the Thunderbird and Calendar dev teams about this. (Apparently React is already being used by the Developer Tools team and the Firefox Hello team.)

I think that about covers it for now. I’m excited for the coding period to get underway and grateful for the opportunity to work on this project. I’ll be posting updates to this blog under the “gsoc” tag, so you can follow my progress here.

— Paul Morris

Thunderbird notes 2015-12-01. NOON PT (Pacific). For meeting time, previous notes and call-in details see https://wiki.mozilla.org/Thunderbird/StatusMeetings

Attendees

• jorgk, fallen, ba, wsmwk, mkmelin,MakeMyDay, rkent, marcoagpinto, roker

MAIN FOCUS OF MEETING

• version 45
• governance, futures
• builds

Action items from last meetings

• Thunderbird Council reorganization: we’ll discuss this in the Council directly and do some reorganization. This is not a forever governance plan, but we need to be practical given the many demands of the moment.

Current status / Announcements

• Etherpads see list of names at https://public.etherpad-mozilla.org/p/thunderbird and https://public.etherpad-mozilla.org/p/calendar
• https://public.etherpad-mozilla.org/p/thunderbird38-support-issues for version 38 ESR issues
• Tree status issues: https://public.etherpad-mozilla.org/p/thunderbird-tree-status
  • Please help green up the tree – including not only c-c but also esr38, beta, and aurora
    • Please be aggressive filing bugs, and fixing what you can, so dev checkins can occur when patches become available.
    • If a bug breaks nightly or beta build or tests, please make severity=blocker
    • Please prioritize reviews/feedback requests in your queue that are tree issues!
• Thunderbird 45: string freeze 2015-12-14, interface freeze later (that’s me demanding a concession like last year).

Current Release Critical Issues

Leave critical bugs here until confirmed fixed. If confirmed, then remove.

• tracking-tb38 flags: approved(+)+unfixed in ESR: http://mzl.la/1LDrkxP nominated(?): http://tinyurl.com/pgwflyg

blocking

• 38.3.1 bug 1211160 calendar 4.0.3.1 is a workaround for 38.3.0 — Thunderbird Version 38.3 Buttons not working menu items // bug 1211291 – Folders are visible, but messages are not. (?related to bug 1211358 lightning chrome.manifest not updated in 38.3.0 ?)
• nightly (3 bugs blocking builds, all are assigned) – bug 1195442 – Mac builds broken ~1 month on nightly
• rkent is working on it – bug 1183490 – (dataloss) New emails do not adhere to sort by order received
  • Plan is to understand issues in converting completely to nextKey = ++lastKey for non-IMAP, then plan how much to implement for 38.3.0 A simple fix of the dataloss is probable. I have a try patch that does the nextKey = ++lastKey that works, now I need to think about patch for 38 (bug 1202105 needs to go to trunk and 38)
  • update 2015-10-20, patches have been posted but waiting for reviews for 2 weeks (aceman will look at those)
  • update 2015-11-17, review done 11-14, need to update and land.

important (but not top critical)

• status TBD – bug 1182629 – update to 38.1.0 from 38.0.1 re-enables disabled Lightning
• status TBD – bug 1176399 – Multiple master password when GMail OAuth2 is enabled
• status TBD – bug 1176748 – fix main thread proxies to the migration code (jorgk and m_kato have done such fixes in the past)
• filelink, proxy,
• topcrash bug 1149287 is ** 31% of our crashes** – see below

Version 45

• tracking-tb45 flags: unfixed ?/+ – http://mzl.la/1PMzNiK
• Items that may need to be checked and tested: gtk3, windows 10, windows 64bit?
• hardware acceleration – not looking promising (no changes / no testing in recent months)
• jsaccount should come in aurora

Releases

• Past
  • 38.0.1 nominally shipped 2015-06-12, 38.1.0 shipped 2015-07-10, 31.8.0 shipped 2015-07-17, 40.0beta shipped 2015-07-27 (skipping 39.0b), 38.2.0 shipped 2015-08-14, 41.0b1 2015-09-08 build2 (missed ~2015-08-10)
  • 41.0b2 (with uplifts for 38.3.0)
  • 38.3.0 ~2015-09-25 (throttled on 2015-10-06)
  • 42.0b2 2015-10-13 (42.0b1 abandoned)
  • 42.0b3 ~2015-09-23 (skipped)
  • 38.4.0 2015-11-25 (quite late) – many release notes issues
• Upcoming – https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates
  • 43.0b1 starting this week https://public.etherpad-mozilla.org/p/thunderbird-release-43b1
  • STRING FREEZE for version 45 in 2 weeks – 2015-12-14
  • 38.5.0 ~2015-12-14 ~3 weeks
  • 44.0b1 ~2015-12-14 ~3 weeks

Lightning

Past releases:

• 4.0.1.2 – bug 1182264, 4.0.2.1 – bug 1194997
• 4.0.3, 4.0.3.1 (no changes compared to 4.0.2.1)

Upcoming releases:

• 4.0.4 – bug 1215969
• 4.7.0 – bug 1225778 (TB 45)

Round Table Jorg K

• Landed six patches
  • bug 1219928 – M-C spell checker problem
  • bug 586587 + one more – M-C drag and drop onto editor window
  • ((bug|1226537}} – C-C spell check in subject problem
  • bug 1214377 – M-C editor problem, copy/paste – “white-space: pre;”
  • bug 1225864 – M-C CJK route cause of problem in the serialiser
• Awaiting review:
  • bug 769604 – C-C font size toolbar button and change increase/decrease size function.
  • bug 1225904 – C-C CJK e-mail with long lines gets corrupted
  • bug 653342 – C-C CJK fix serializer flags, support delsp=yes, tie all CJK issues altogether. Automatically fixes bug 26734
• (Attended Mozilla Berlin “Tech Meeting”: Firefox OS, Telemetry, Servo/Rust)

aceman

Assisting Thomas D. to drive the patches to fix determining the send format (plain/HTML) of outgoing messages:

• bug 136502 – landed
• bug 584313 – needs review in compose.cpp (e.g. Neil)
• bug 1222176 – patch with tests prepared, needs reviews

wsmwk

• 38.4.0
  • built and shipped
  • tracking Lightning related update issues bug 1215828
• new etherpad https://public.etherpad-mozilla.org/p/thunderbird-encryption

rkent

• I was away for a full week for Thanksgiving, just back today, and have a ear infection as well, so has not been a good week. Responding to the pEp proposals, and Mitchell’s post, are my main priorities at the moment.

Friends of the tree

• congrats to kohei who was recognized for “creating the Thunderbird version of the Get the Add-on button” (and has done a ton of work moving dozens of Thunderbird web pages to bedrock)

Action Items

• we should really clean up the module owners and peers at https://wiki.mozilla.org/Modules/MailNews_Core and https://wiki.mozilla.org/Modules/Thunderbird. Candidates for removal: Bienvenu, standard8, sid0, JosiahOne.

Help Wanted

• Support lead
  • Revise lightning articles on SUMO: https://support.mozilla.org/en-US/search/advanced?q=lightning&language=en-US&category=10&category=20&product=thunderbird&sortby_documents=relevance&a=1&w=1 – to query articles that needs change: https://support.mozilla.org/en-US/contributors/kb-overview?product=thunderbird
• Accessibility lead
• persons comfortable (not necessarily technical experts) with Core type issues. Example graphics to guide bug 1195947 Thunderbird hardware acceleration (HWA) issues to be resolved

Retrieved from “https://wiki.mozilla.org/index.php?title=Thunderbird/StatusMeetings/2015-12-01&oldid=1108006”

Thunderbird notes 2015-11-17. NOON PT (Pacific). For meeting time, previous notes and call-in details see https://wiki.mozilla.org/Thunderbird/StatusMeetings

Attendees

• jorgk, Pegasus, ba, wsmwk, mkmelin,MakeMyDay, rkent

FOCUS OF MEETING

(to be covered in sections below)

• version 45
• governance, futures
• builds

Action items from last meetings

• Thunderbird Council reorganization: we’ll discuss this in the Council directly and do some reorganization. This is not a forever governance plan, but we need to be practical given the many demands of the moment.

Current status / Announcements

• Etherpads have moved: see list of etherpad names at https://public.etherpad-mozilla.org/p/thunderbird and https://public.etherpad-mozilla.org/p/calendar
• https://public.etherpad-mozilla.org/p/thunderbird38-support-issues for version 38 ESR issues
• Tree status issues: https://public.etherpad-mozilla.org/p/thunderbird-tree-status

• Need to release 38.4 and 43.0b1
  • Please help green up the tree – including not only c-c but also esr38, beta, and aurora
    • We must be aggressive so checkins when patches become available. Thoughts: if you file a bug, please consider fixing it, or pass it off to someone rather than rely on “the fates”. If it breaks build or tests, please make severity=blocker
• Thunderbird 45: string freeze per schedule, interface freeze later (that’s me demanding a concession like last year).

Critical Issues

Leave critical bugs here until confirmed fixed. If confirmed, then remove.

• tracking-tb38 flags
  • approved(+)+unfixed in ESR: http://mzl.la/1LDrkxP
  • nominated(?): http://tinyurl.com/pgwflyg
• tracking-tb45 flags: unfixed ?/+ – http://mzl.la/1PMzNiK

blocking

• 38.3.1 bug 1211160 calendar 4.0.3.1 is a workaround for 38.3.0 — Thunderbird Version 38.3 Buttons not working menu items // bug 1211291 – Folders are visible, but messages are not. (?related to bug 1211358 lightning chrome.manifest not updated in 38.3.0 ?)
• nightly (3 bugs blocking builds, all are assigned) – bug 1195442 – Mac builds broken ~1 month on nightly
• rkent is working on it – bug 1183490 – (dataloss) New emails do not adhere to sort by order received
  • Plan is to understand issues in converting completely to nextKey = ++lastKey for non-IMAP, then plan how much to implement for 38.3.0 A simple fix of the dataloss is probable. I have a try patch that does the nextKey = ++lastKey that works, now I need to think about patch for 38 (bug 1202105 needs to go to trunk and 38)
  • update 2015-10-20, patches have been posted but waiting for reviews for 2 weeks (aceman will look at those)
  • update 2015-11-17, review done 11-14, need to update and land.

important (but not top critical)

• status TBD – bug 1182629 – update to 38.1.0 from 38.0.1 re-enables disabled Lightning
• status TBD – bug 1176399 – Multiple master password when GMail OAuth2 is enabled
• status TBD – bug 1176748 – fix main thread proxies to the migration code (jorgk and m_kato have done such fixes in the past)
• filelink, proxy,
• topcrash bug 1149287 is ** 31% of our crashes** – see below

Releases

• Past
  • 38.0.1 nominally shipped 2015-06-12, 38.1.0 shipped 2015-07-10, 31.8.0 shipped 2015-07-17, 40.0beta shipped 2015-07-27 (skipping 39.0b), 38.2.0 shipped 2015-08-14, 41.0b1 2015-09-08 build2 (missed ~2015-08-10)
  • 41.0b2 (with uplifts for 38.3.0)
  • 38.3.0 ~2015-09-25 (throttled on 2015-10-06)
  • 42.0b2 2015-10-13 (42.0b1 abandoned)
• Upcoming
  • https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates
  • 42.0b3? ~2015-09-23 not happening
  • 38.4.0 ~2015-11-05 Still in progress
  • 43.0b1 not yet started
  • STRING FREEZE for version 45 in <4 weeks

Lightning

Past releases:

• 4.0.1.2 – bug 1182264, 4.0.2.1 – bug 1194997
• 4.0.3, 4.0.3.1 (no changes compared to 4.0.2.1)

Upcoming releases:

• 4.0.4 – bug 1215969

Round Table Jorg K

• bug 1174452 – M-C editor problem, copy/paste – “white-space: pre;” – patch preposed in bug 1214377 ; landed and sadly got reopened, awaiting review again.
• bug 586587 – M-C drag and drop onto editor window – awaiting review.
• bug 769604 – C-C font size toolbar button and change increase/decrease size function – awaiting review.
• bug 1219928 – M-C spell checker problem – awaiting review.
• Started looking as CJK problems in flowed plaintext messages: bug 26734, bug 653342.
• Got hit by bug 1224840 – Assertion failure: IsOuterWindow(), fixed one occurrence.

rkent

• Thunderbird’s future plans
  • Pending letter from Mitchell on Thunderbird and MoCo
  • Big issues for Thunderbird future: 1) cost of transition 2) sources of income
    • 1) Volker Birk & another senior architect will work with you to estimate the cost of transition in man days and $ as they have lots of experince in setting up and migrating complex systems.
    • 2) We have been talking to DigitalCourage about setting up a donation based system and we as the p≡p Foundation will fund Thunderbird until the donation levels are sufficient for a sustained future.
  • Even bigger issues for the future: articulating a vision, collecting partners: p≡p, Postbox, Chinese fork, Gaia email, TDF/Collabora, MoFo, ???
    • We see these points as elements that need to be worked out in the six months’ period that we have agreed with MoFo. As for collecting partners, we consider this as an outcome of the Business Strategy that will be defined in the next 6 months. We, the p≡p Foundation will start discussions with TDF. In my opinion, ‘Collecting Partners’could require quite large time committment and it should hence be very well planned.
  • Status of MoFo-Thunderbird and Thunderbird-p≡p discussions
    • p≡p Foundation is waiting for MoFo to come back with final comments. In the meantime, I’ll be wait for Kent’s input to align
  • My concern for developing capacity of Thunderbird to be self-managed and focused.
  • Planning a Europe meetup in January, focused on a business plan for January – June 2016
    • We are happy to set it up here in Europe.

Question Time

• new account provisioner: Are there currently any providers other than Gandi? Would it be worth trying to find some more?
• We need a plan for the build system fairly urgently, given the apparent “no” to the c-c/m-c merge

Help Wanted

• Support lead
  • Revise lightning articles on SUMO: https://support.mozilla.org/en-US/search/advanced?q=lightning&language=en-US&category=10&category=20&product=thunderbird&sortby_documents=relevance&a=1&w=1 – to query articles that needs change: https://support.mozilla.org/en-US/contributors/kb-overview?product=thunderbird
• Accessibility lead
• persons comfortable (not necessarily technical experts) with Core type issues. Example graphics to guide bug 1195947 Thunderbird hardware acceleration (HWA) issues to be resolved

Retrieved from “https://wiki.mozilla.org/index.php?title=Thunderbird/StatusMeetings/2015-11-17&oldid=1106129”