Gaia/SMS/Scrum/2.1S8/Planning

Sprint is from 28oct -> 11nov

(Julien) 11nov is a french holiday, so we should do next retro/planning on 10nov (and you'll represent the team during comms' planning)

(Steve) Based on previous experience, we might change the comms retro/planning if some country is on holiday. Do you think we should change the meetings this time?(But now we have less members in Paris office, so...)

(Julien) yeah I think I'm the only one in France now... there is Johan but I don't think he takes part to planning? Anyway I'll raise the concern in the later meeting today

Velocity: [p=8] Julien and Oleg: some time needed to work on Smart Data; I suggest p=8 (means ~1 person less than usual)

(Oleg) p=8 sounds good to me

(Steve) May I know the "Smart Data"?

(Julien) yeah, sorry... it looks like it will be one of the key features of v2.2, and since SMS does not have a lot of planned features for v2.2 (of course they don't take into account everything _we_ want to do) Oleg and I are supposed to work on this. This is a big evolution about Cost Control...

(Steve) Ah, I remember we need to spend more resource on cost control.

(Julien) everything is not clear yet; I think they're looking for a possible 3rd person but David would like someone in the same timezone (not sure it makes really sense because the Gecko developer that works on this is in Seattle :p). In this sprint, we'll likely need to start doing small things to understand cost control better.

(Steve) Ok, good to know this

(Julien) I'll also think of how we can still work as a team here; they don't want that we stop working on SMS either. So well.. Maybe it would be nice if we're all co-owners of the app.

(Steve) Let's wait until things getting more clearly :) But it seems not a perfect for meeting if developers comes from all around the world:p

(Julien) yep. Let's see :) p=8 ok for you Steve?

(Steve) yep

from current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1071514 [unless is r+] [skip]
Bug 1071514 - [Woodduck][Messages] The picture will flicker once when you take one picture as attachment

• (Oleg) Looks like it's fixed and landed!

  (Steve) Since it's mainly for uplift for old branches(I think it's good enough currently), do we need to focus on the master now? But I'm not sure the idea proposed by Jenny is fine.

  (Julien) I think it's good like it is on master for now; we have regressions to fix currently :/ if we have reports of memory issues we'll look into it. Let's move to the next?

https://bugzilla.mozilla.org/show_bug.cgi?id=996755 [not actionnable, let's skip] [p=1]
Bug 996755 - [B2G][MMS] Unsupported data formats are not displayed corrected when received by MMS

• (Julien) I looked at the patch, and I don't really know the right behavior... Let's move the patch in a separate bug but don't work more on this

  (Steve) Bug created in https://bugzilla.mozilla.org/show_bug.cgi?id=1090043, for address the attachment missing in SMIL issue

  (Julien) thanks, the STR in this bug is much clearer, I now can see there is an actual real-world case :) do you think we should try to fix this? I don't think it's much important right now, especially the partner did not answer on the previous bug...

  (Steve) ya...But I can still create a patch for it since it's not a huge one.

  (Julien) maybe we can estimate and take it if we have enough time after we handle blockers?

  (Steve) Sure, it's p=1 for me because patch is already given

  (Julien) yep, p=1 (the patch needs unit tests, but should be easy enough)

  (Oleg) yep, looks like p=1, patch looks small

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1081207 [2.2+] [p=1]
Bug 1081207 - [Messages] We never revoke the blob URL for the attachments

• (Julien) goal is to set the blob url in a dataset, and properly revoke it when cleaning up.

  (Julien) I don't think there is much work to do, but needs to think to all cases where we need to revoke. Still I think p=1 is enough here?

  (Oleg) p=1

  (Steve) p=1

nominations

https://bugzilla.mozilla.org/show_bug.cgi?id=1085764 [2.1?] [p=2]
Bug 1085764 - [flameKK][v2.1]Be able to input Simplified-Chinese in SMS subject after reaching maxium length

• (Julien) Steve already investigated and has a possible solution.

  (Julien) steve, do you have the WIP patch somewhere? Do you think it will be blocker?

  (Steve) The main idea is add an input event and check/trim the string. But I think you don't like this idea(trigger reflow)?

  (Julien) if we need to trim after it's been added, there will likely be a reflow we I don't think we can avoid it without a new event?

  (Steve) ya... currently I don't have better idea then this

  (Julien) me neither. if we have clear ideas, I'd say p=1 or p=2

  (Steve) I think p=1 if we don't want any further experiment, but p=2 might be safer

  (Oleg) I'd say p=2,

  (Julien) ok

https://bugzilla.mozilla.org/show_bug.cgi?id=1089920 [perf, 2.1?] [p=3]
Bug 1089920 - [Messages] Investigate and fix the gaia-header in Messages app

• (Julien) not fun, but someone needs to spend some time on this. I feel this can be a partner blocker in the future...

  (Steve) I thought Wilson might help with this one...

  (Julien) Wilson wants to change our event DOMContentLoaded with onload... So I want to find an alternative solution. I'd like to know whether the font fix is bad (so it would be bad in v2.0 already) or if the gaia-header regressed this more (would be worse starting with v2.1).

  (Julien) one crazy idea is to insert the gaia-header in a <script> not deferred; so that it can execute early and not do a big synchronous reflow. I haven't tried yet and not sure this is good :) Another idea is to insert the CSS as a <link> instead of letting gaia-header insert it programmatically (like it was in v2.0 actually). Also I'd like to see what is different between SMS and other apps (maybe it's DOMContentLoaded).

  (Steve) Sounds difficult to estimate this

  (Oleg) So as the first step we'd like to a) compare with v2.0 and b) try some radical ideas to improve?

  (Julien) for (a) I asked QA already but we can do it too. Maybe profiling the launch could be useful, ting-yu could help here because he did some profiling in bug 1074783

  (Steve) Yes, he found some penalty in font size calculation

  (Julien) yep because it triggers a reflow (I think). But it might be a good idea to compare the SMS profile with the profile for another app.+1

  (Julien) for sure gaia-header accesses offsetLeft and offsetWidth... :/ I also wanted to discuss with layout guys once I know what's the real culprit. Ideas for longterm: have similar properties that do not trigger a reflow, or have promise-based API that would not block the JS execution. So well, lots of ideas, not a lot of solutions :p

  (Julien) I think this is not less than p=3. We can wait for QA and ask Ting-Yu some help, and start from here? +1

  (Julien) anyway we should not spend more time than p=3 which is already a lot. (I can start the task until there is a solution if you want?)

• (Steve) Agree that it should not less than 3, so p=3for now

https://bugzilla.mozilla.org/show_bug.cgi?id=1088754 [2.2?] [skip, possible dupe to bug 1084252]
Bug 1088754 - [Messages] No overlay while deleting

• (Julien) regression window is coming but I think we can already try to debug. My guess is a regression from https://bugzilla.mozilla.org/show_bug.cgi?id=1078295

  (Julien) regression window came, good guess from me ;)

  (Steve) Very likely... so the solution might be in bug 1084252 since not all dialog could fit this styling

  (Julien) ah yeah ! can you try with the patch and see if the bug is fixed? Should we skip this bug while waiting for bug 1084252?

  (Steve) Ya, I think let's skip this one first and I'll verify this later.

https://bugzilla.mozilla.org/show_bug.cgi?id=1089198 [2.2?] [p=1]
Bug 1089198 - Tap on message report header, the contextual menu "…" will be shown

• (Julien) regression window is coming, probably a regression from the report redesign. Should be easy to fix.

  (Julien) regression window came, it's actually a regression from a web component update. Should we take it or let Wilson take it? I think we should at least investigate to see what broke. I don't think it's more than p=1 anyway ?

  (Oleg) Agree with p=1 and probably we can help Wilson first to find the reason

  (Steve) p=1 for help investigation

(Julien) So, we're at p=7. Should we take 996755 as estimated earlier, or a RTL bug below as Francisco asked us?

(Julien) I think we should take a RTL bug :)

(Steve) +1 for RTL bug, and for the smil issue I can spend less time on it

(Julien) bug 1080820 is the only one that can fit in p=1 I think. What do you think? if we have more time we can look at others at the end...

(Oleg) Yep

features

https://bugzilla.mozilla.org/show_bug.cgi?id=1080832 [RTL]
Bug 1080832 - [Messages][RTL] Cursor is badly located in recipients and subject when they're empty

• (Julien) some investigation needed

https://bugzilla.mozilla.org/show_bug.cgi?id=1080820 [RTL] [p=1]
Bug 1080820 - [Messages][RTL] Sticky header does not take the whole width

• (Julien) likely a CSS only issue

  (Oleg) Should be easy and it's time to fix it, it's quite annoying for LTR too, p=1

  (Julien) p=1 too.. but the sticky header uses -moz-element to display the header as a background, so it might be _that_ easy :) but still it should be reasonnably easy.

  (Steve) p=1

https://bugzilla.mozilla.org/show_bug.cgi?id=1053709 [RTL]
Bug 1053709 - Make SMS messages content UI RTL-friendly

• (Julien) some investigation needed + we need to add some example data in the desktop mocks

https://bugzilla.mozilla.org/show_bug.cgi?id=1080828 [RTL]
Bug 1080828 - [Messages][RTL] International phone numbers and groupmms threads are not correctly displayed

• (Julien) some investigation needed + we need to add some example data in the desktop mocks