Gaia/SMS/Scrum/2.1S5

List of bugs

SMS issues handled by the SMS subteam (blocks the sprint bug 1067820)

Bugzilla link

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature-b2g	Whiteboard	Resolution
903763		[Messages] avoid css recalculations while rendering a thread	---	No cf_feature-b2g	[c=progress p= s= u=][p(2.1S5)=1]	DUPLICATE
1003843	Oleg Zasypkin [:azasypkin]	Follow up to Bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads	---	No cf_feature-b2g	groupmms [p(2.1S6)=1][p(2.1S5)=1]	FIXED
1021608	Steve Chung [:steveck]	[Messages] Report panel visual refresh	---	No cf_feature-b2g	[sms-most-wanted][p(2.1S7)=1][p(2.1S6)=2][p(2.1S5)=2]	FIXED
1053708	Julien Wajsberg [:julienw]	Make SMS main User Interface RTL-friendly	---	No cf_feature-b2g	[p(2.1S6)=1][p(2.1S5)=2]	FIXED
1054989	Julien Wajsberg [:julienw]	[Messages][DSDS] Send button refresh	---	No cf_feature-b2g	[p=1]	FIXED
1061417	Julien Wajsberg [:julienw]	[SMS] We don't properly discard the draft in some occasions	2.1+	No cf_feature-b2g	[g+][LibGLA,TD92485,QE1, B][p=1]	FIXED
1067228	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Move subject management to a separate component	---	No cf_feature-b2g	[p=2]	FIXED

7 Total; 7 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Remaining points and burndown chart

google chart api url for Sprint 2.1S5

	Remaining points
Start	10
Day 2	10
Day 3	10
Day 4	9
Day 5	9
Day 6	9
Day 7	9
Day 8	8
Day 9	8
Day 10	6
End

SMS issues handled by the SMS subteam outside of the sprint (contains whiteboard "sms-sprint-2.1S5")

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature-b2g	Whiteboard	Resolution
1052447	Julien Wajsberg [:julienw]	[Messages] when we're in an activity and we delete all messages in the thread, we should close the activity	2.0+	No cf_feature-b2g	[g+][LibGLA, Dev, B][sms-papercuts][sms-sprint-2.1S5]	FIXED
1061215	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Improve handling of remaining chars counter	---	No cf_feature-b2g	[sms-papercuts][sms-sprint-2.1S5]	FIXED
1070890	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Make use of EventDispatcher in Compose	---	No cf_feature-b2g	[sms-sprint-2.1S5]	FIXED

3 Total; 3 Open (100%); 0 Resolved (0%); 0 Verified (0%);

All SMS issues tracked for this sprint (target milestone)

Bugzilla link

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature b2g	Resolution
836690	Jorge Prudencio [:jorgep]	[SMS] Implement temporary in App message informing the user that they have started another SMS packet	---	---	FIXED
1052447	Julien Wajsberg [:julienw]	[Messages] when we're in an activity and we delete all messages in the thread, we should close the activity	2.0+	---	FIXED
1054989	Julien Wajsberg [:julienw]	[Messages][DSDS] Send button refresh	---	2.2+	FIXED
1061417	Julien Wajsberg [:julienw]	[SMS] We don't properly discard the draft in some occasions	2.1+	---	FIXED
1067228	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Move subject management to a separate component	---	---	FIXED
1067820		[meta] SMS subteam sprint 2.1S5	---	---	WONTFIX

6 Total; 6 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 17th September

Julien

• I finished reading my mails and handling some bugs
• created the Scrum page; I updated the Template page (the graph URL was incorrect when the points were not 11). Maybe we could easily convert this to a script instead, now.

Today:

• will start working on the blocker bug 1061417

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Almost finished with the main parts, today will tune and work on tests (in progress);
  • Just realized that this bug depends on "bug 1061215 - [Messages][Refactoring] Improve handling of remaining chars counter" that is currently in r? for Steve. Will rebase on master and redirect to Julien as Steve is on PTO.

Other:

• Investigated and dig through bugzilla about iframe vs unload/beforeunload. Alive asked to redirect that question to platform as it's Gecko who doesn't support that.

  (Julien) did we file a bug for having a "onclose" event for a MessagePort ?

  (Oleg) No, does spec contain that event?

  (Julien) nothing in the spec, but from what we saw we need it... we need to evolve the spec :)

  (Oleg) Ok, let's wait for Andrea reply first as start point, he is working on MessagePort and BroadcastChannel (MessageChannel too :)).

  (Julien) if we don't have an answer today, maybe send a mail to dev-webapi. Andrea can be busy :)

  (Oleg) Okay, thanks for dev-webapi reference :) I need to subscribe :)

• Added few demos to previous sprint page.

Today:

• Will handle review comments for the patches that currently in review;

Steve

• Absent/no report

Luke

• Absent/no report

Day 3: 18th September

Julien

• bug 1061417 (draft is not discarded in some occasions): it was easier than expected, and a long-standing bug probably existing since v1.4 (in review)
• resumed working on bug 1054989 (DSDS send button refresh), should have a patch ready today
• did some reviews
• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)

Other:

• resumed work on bug 874510 (upgrade mocha); one piece was missing (bug 1035133) that I added and is in review now.

Today:

• will continue working on bug 1054989
• will dig in some issues I left from yesterday

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Still in progress (in progress);
• bug 1061215 - [Messages][Refactoring] Improve handling of remaining chars counter
  • Got first review feedback, working on it (in progress).

    (Julien) do you need something from me here? I saw a question but I don't know if you still need the answer :)

    (Oleg) I guess no :) Will ping you on IRC if have one :)

    (Julien) ok great !

• bug 1067712 - [MADAI] [SMS] Message Apps cannot remove surrogate pair character correctly
  • Investigated and provided reduced test case, now we have Core->Editor bug instead

    (Julien) I hope we don't need an uplift :/

    (Oleg) Yeah, I believe it was always there

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.
• Will see what events are fired on iframe in Firefox when it's removed from DOM to be sure that's not only gaia problem.

Steve

• Absent/no report

Luke

• Absent/no report

Day 4: 19th September

Steve

• bug 1058459 - [SMS] Data shared from other applications are not shown as Drafts until the app is killed and open again
  • Reviewing the SharedWorker patch(and it's brilliant!) will leave some comments later and give it a try
• bug 1059233 - [SMS] User cannot view the cropped image in SMS application and ActivityCanceled error was shown when try to view
  • Having a integration tests for this case might be an idea to avoid possible regression(removing the workaround without gecko fixed first) like this. I've checked 1.4 and this issue exist since workaround was removed from v1.4 and later.

    (Julien) yeah it's strange that the branch checks said that it works in v1.4. I'll look closer today...

• bug 1067232 - [SMS] Avoid to make a private memory copy for file based blob
  • No update yet.

    (Julien) please wait that I sort out the issue in the platform; I think I'll just back out the workaround in SMS and we'll either add it back in Gallery or find the fix in the platform. :asuth thinks that even with the current workaround we can fail in some cases.

    (Steve) Hmm, not sure which case will make the blob copy workaround failed, I thought both workaround have similar approach.

    (Julien) not sure either. Nope, the gallery workaround is: copy the blob to a temporary file so that we get a file-backed blob and do not have the issue in SMS.

    (Steve) Ah, I see. Just check the gallery's patch.

    (Julien) I haven't looked at the patch though, I may be wrong here, I just take what djf told me :) Anyway we'll know more today !

    (Steve) I could agree it's better to workaround in gallery then in messaging in general like asuth said, if they(gallery) agrees to do so. I just confused that why we need messaging workaround in 1.2f and 1.3t if gallery already got the workaround as well...

    (Julien) the gallery workaround is in v1.3t only, as far as I know.

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • Start to implement report panel refresh.
• bug 1068564 - When CMAS alert are deleted in notifications panel, device closes utility try
  • Checking with current master and other notification case. It's weird and seems not a CMAS app wise issue.

    (Oleg) It looks like what I saw previously https://bugzilla.mozilla.org/show_bug.cgi?id=1051793#c8

    (Steve) Thanks! I almost forgot this. It was worked on emulator, but I haven't revisit again

    (Oleg) Maybe I'm wrong but as I remember when I swiped notification it got activated and our app reacted... don't remember exactly :)

    (Julien) it's probably a system front-end bug. (but probably from my code from bug 1051788 :D)

    (Steve) Hmm, will take a look about this then, thanks too!

Today:

• Investigate bug 1068564 and start bug 1021608

Julien

• bug 1061417 (draft is not discarded in some occasions): landed
• bug 1054989 (DSDS send button refresh):
  • got a patch, waiting for fang's ui-review and maybe image updates (because the new ones are larger for apparently no reason)
  • also added a missing l10n string
  • might ask for an approval to land on v2.1 if not too late
• did some reviews for Oleg especially :)
• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • looks like there is something deeper than just SMS. Will look further today, especially see how it works in the various versions. The regression window just points to the workaround removal in Gallery which does _and_ doesn't make sense ;)

Other:

• resumed work on bug 874510 (upgrade mocha) (my "subway" project :) ); fixed some unit tests but there are more failing.

Today:

• will continue working on bug 1059233 for the blob related issue
• will do reviews
• will start another sprint bug (don't know which one yet)

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Almost finished unit tests, will wait for bug 1061215 first(in progress, almost finished);
• bug 1061215 - [Messages][Refactoring] Improve handling of remaining chars counter
  • Got second round of review comments, fixed, will ask review in a few! (in progress).
• bug 1050416 - [Messages][Build] Add build script to ignore the desktop-only folder for production build
  • Got first round of review comments, working on it (in progress).

Other:

• Reviewed Luke's patch to fix cursor glitch, left some suggestion on selection managment and unit test;
• Reviewed small patch on draft discard.

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Day 5: 22th September

Steve

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • Ongoing.
• bug 1068564 - When CMAS alert are deleted in notifications panel, device closes utility try
  • I could only reproduce this on CMAS, and like Oleg said it's not just on clear all notification case, every CMAS notification removed by swipe will also hide the tray. So I will take a deep look now. Not quite sure that it's about the silent notification changes in bug 1026685. The only thing I know now is the hide action occurred after mozContentNotificationEvent dispatched.

    (Julien) tell me if you'd prefer to redirect to me :)

    (Steve) If I can't find answer today, it might be more efficient that hand over this bug to you

    (Julien) ok, tell me when you go home later today :)

• Some review and bug reply.

Today:

• Investigate bug 1068564 and start bug 1021608

Julien

• bug 1054989 (DSDS send button refresh):
  • still in review

    (Oleg) will take a look very soon, sorry :)

• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • spent a lot of time on this. Found a similar issue without cropping, but when we use an image that needs an EXIF-based rotation; this also triggers a memory blob. I don't understand why the use case with crop works in v1.4 but not the use case with Exif.
  • my preference would be to reland the workaround in gallery instead of SMS, because other applications (eg: email) have the issue
  • I'd also like to understand why the crop-based use case work in v1.4. I think I'll look at it again today.

    (Steve) Did you tried it yourself? Not sure how they test this issue, but it's only reproducible on image smaller than size limitation.

    (Julien) Yep I tried myself :) (I have 1 phone for each version...). but you're right, I'll check if I used an image that was small enough.

    (Steve) BTW I used 9/11 1.4 build on bury

• starting looking at bug 1003843 (change how we display threads with several recipients)
  • asked a question to Fang about this

Other:

• resumed work on bug 874510 (upgrade mocha) (my "subway" project :) ); fixed some unit tests but there are more failing.

Today:

• will continue working on bug 1063658 for the blob related issue
• will do reviews
• will work on bug 1003843 if Fang is answering, otherwise I'll take either the RTL bug or bug 903763 for performance.

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Done, waiting for dependencies to land (waiting for dependency);
• bug 1061215 - [Messages][Refactoring] Improve handling of remaining chars counter
  • Fixed the latest comments (in review);
  • Added big marionette test to test MMS label and char counter behaviour :)
  • Rebased on the latest master as patch for bug 836690 resurrected ThreadUI<->Char counter dependency, not sure how segment info notice should really work, asked Steve on github.

    (Julien) doesn't ThreadUI just use the "segmentinfo" event? (I haven't looked the new code)

    (Oleg) Yes, it uses it, but also uses counterLabel.dataset.counter to get previous segment info (parses and splits content to get segment number). I was thinking about passing old and new segment info in segmentinfochange event

    (Julien) in DOM, usually, we don't pass the information with the event if it can be retrieved in another way (eg: geolocation vs visibilitychange). Maybe ThreadUI could just store the segmentinfo itself. But I don't really mind :)

    (Oleg) Yeah, that is what I did currently, but I'm storing only segment number for now

    (Julien) yep, I meant segment number.

• bug 1050416 - [Messages][Build] Add build script to ignore the desktop-only folder for production build
  • Created asyncStorage mock that doesn't touch IndexDB, so it keeps drafts in memory + other fixes; Didn't touch regex part for now (in review).

bug 1014686 - [Messages][Refactoring] Improve "html template string" to "dom node\fragment" conversion

• • Provided patch for Template.prepare().toDocumentFragment as I want to use something like this in subject refactoring patch (in review). Tried to check its performance on JSPerf - looks fine to me, if I did everything correctly :) (in review)

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Day 6: 23th September

Steve

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • Ongoing.
• bug 1068564 - When CMAS alert are deleted in notifications panel, device closes utility try
  • After some investigation, it should be the notification issue and it seem exist long time ago. Notification will dispatch the close system message, and it will trigger the app launch again(and app launch event will hide the tray). It seem not a reasonable patent anyway, so I redirect the issue to system platform side.
• bug 1068490 - [Wooduck][[Comms]MMS]The picture will flicker once when you take one picture as attachment
  • Currently we always append the image attachment node at first, and update the attachment node if the total size exceed the limitation. This node replacement action might not the necessary step. Maybe we could simply update the size indicator and attachment item.

    (Julien) another idea is to put the default image for <image> attachments while we resize, and add the resized attachment on top (so that it won't flicker). I'll comment a little more on the bug :)

• Some review and bug reply.
• Some copy paste issue in message, but George Duan will handle it first. So if you see any problem related to copy paste issue, please refer him or Morris Tseng (gecko) for more information.

  (Julien) Good to know, thanks !

Today:

• Keep moving bug 1021608
• Investigate bug 1068490 for proper solution first

Julien

• bug 1054989 (DSDS send button refresh):
  • still waiting for Fang's ui-review :(
• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • haven't looked more yesterday, need to look again...
• about bug 1003843 (change how we display threads with several recipients)
  • unassigned myself to take another bug
  • Fang answered today so it's ready if one of you wants to take it
• started bug 1053708 (make main interface RTL friendly)
  • opened some bugs in Gecko to make this easier; will open more today and also send mails to www-style. Some CSS properties are ready for RTL, some others are not, I'd like to at least move forward this matter at W3C. In the mean time we'll probably need to override some CSS, but at least this will make the web better over time :)

Other:

• we have a new 2.0 blocker (bug 1052447). Should be an easy one. Who can take it?

  (Julien) I can do it if you're busy on other things :)

  (Oleg) I'll check, haven't noticed it yet :)

Today:

• will continue working on bug 1063658 for the blob related issue
• will do reviews
• will continue work on bug 1053708

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Done, waiting for dependencies to land (waiting for dependency);
• bug 1061215 - [Messages][Refactoring] Improve handling of remaining chars counter
  • Got next review round comments, asked clarifying questions (waiting for reply).

    (Julien) ok, will look at it first

    (Oleg) thanks!

    (Julien) may be easier/faster to wrap this up on IRC :)

    (Oleg) Yep :)

    (Julien) ok let's do this after the meeting

• bug 1058459 - [SMS] Data shared from other applications are not shown as Drafts until the app is killed and open again
  • Dig into possibility to MessagePort.onclose - looks like no way - "bug 915880 - Add onstart/onclose event handlers in the MozInterAppMessagePort" and "http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/252687.html". There is a big discussion that onclose would expose GC behaviour that isn't good.
  • So as per :baku we have weak reference from port to owner (window that owns port) and having dead ports we leak only these ports, well it's bad, but not as bad if we leaked entire window reference :) Probably we can do the following:
    • On "unload" - owner post message to SharedWorker like "I'm dying" and closes the port as recommended by spec; Shared worker will get this message and removes reference to the port. This won't work for the case when app is crashed or killed by LMK.

      (Julien) IIRC we don't always get "unload"? Also I don't know if we have access to some API in "unload".

      (Oleg) Yeah app can "miss" unload, so that we need fallback cleanup plan :( I've checked - postMessage works from unload handler.

      (Oleg) But I'm not sure what happens if app is killed and didn't have chance to close port...

    • For the later case SharedWorker can track number of active connections and after eg. 5 it can ping all it's ports to check if they alive - thus we'll remove overhead by pinging\polling constantly and will ping only in case something went wrong...
  • What do you guys think?

    (Julien) what happens if we don't know that a port is dead? Is it really an issue?

    (Oleg) I believe 5 or even 10 dead ports won't be a problem - it's just reference to port object, probably it depends on usage pattern - if user never closes main app and sharing-sharing-sharing :)

    (Julien) I don't find any better solution than this... I'm kind of sad ;)

    (Oleg) Yeah, I don't like hacks :( Seems BroadcastChannel API will also have this problem. Not sure whether we should move forward with it

    (Julien) But for BroadcastChannel we don't need to manage ports directly, right? It's all hidden in Gecko?

    (Oleg) Mmm, I need to see spec, probably I'm wrong :)

    (Oleg) Yeah, it's better but it still has "close" method that app should call at some point. So here we only need to take care about app crash case somehow

    (Julien) but here Gecko will take care of the GC-ed port because it's all internal so I don't think we'd have to worry. But anyway it's not ready so let's not lose time about BroadcastChannel now :)

    (Oleg) Yep, so should we move forward with SharedWorker or wait until it becomes a blocker for someone?

• bug 1070890 - [Messages][Refactoring] Make use of EventDispatcher in Compose
  • Extracted this part from Subject refactoring patch to make review easier (in review).

    (Steve) Reviewed!

    (Oleg) Ah, cool, thanks!

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Day 7: 24th September

Steve

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • Ongoing. Some discussion about the unclear or missing states on spec. UX/Visual will update the spec later.
• bug 1068490 - [Wooduck][[Comms]MMS]The picture will flicker once when you take one picture as attachment
  • Reply my thought on bugzilla about the memory usage. But I could agree Jenny's proposal that don't render thumbnail before resize complete. Maybe I could give a brief test about the original/resized image thumbnail generation and summarize the memory usage for both case.

    (Julien) good idea :) Note that it's not in the sprint nor a blocker though (although it may become one, I know).

    (Steve) Not for now, at least

Today:

• Keep moving bug 1021608
• Sample test for bug 1068490 if I have time for it

Julien

• bug 1054989 (DSDS send button refresh):
  • changed for the latest request from Fang
  • PR ready, waiting to be tested on the device by myself before landing
• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • (still) haven't looked more yesterday, need to look again...
• started bug 1053708 (make main interface RTL friendly)
  • sent a mail on www-style, will answer more today

    (Steve) Haven't seen any spec about the RTL. Don't we have any layout change for RTL case?

    (Julien) There are no precise spec but we can still do things "automatically", I mean, put things that were on the left to the right, etc. Will need more polish when we'll have spec, but at least we can have a first look on how RTL works and the issues we can face. For example I'm looking at the RTL support for some properties (eg: -moz-padding-start; float: start/end; text-align: start/end...); some works, other don't :) My goal is to file bugs on Gecko about this so that it can be easier when we'll need to support it for real.+1

    (Julien) Probably a good idea to summarize what I find and send a mail on dev-gaia about this :)

• worked on the blocker bug 1052447: deleting all messages should not cause the user to be stuck in an activity
  • made a patch, reviewed, landed

Other:

• Bug triaging like every day
• various Travis cleanup:
  • GREEN build on the v1.4 branch ;) \0/
  • one failure on v2.0... the failing test is disabled on TBPL so that's important (not for us, it's homescreen). Filed a bug for the Homescreen team.
  • travis builds on v2.1 too now

Today:

• will continue working on bug 1063658 for the blob related issue
• will do reviews
• will continue work on bug 1053708

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • All dependencies landed! Testing on device and will ask for first round of review (almost done);

    (Julien) we probably underestimated for this one after all :/

    (Oleg) Yep, my bad

• bug 1061215 - [Messages][Refactoring] Improve handling of remaining chars counter
  • Got r+, landed (landed).
• bug 1070890 - [Messages][Refactoring] Make use of EventDispatcher in Compose
  • Got r+, landed (landed).
• bug 1058459 - [SMS] Data shared from other applications are not shown as Drafts until the app is killed and open again
  • Working on removing dead ports (at least on reducing the chances to have many of them). Testing on device (almost ready).

    (Julien) remember: it's not in the sprint, it's not a blocker; so better work on some sprint bugs first if you can

    (Oleg) Yep, I mean I work on in pauses, when stuck with smth else :)

Other:

• Some code reviews.

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Day 8: 25th September

Steve

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • Ongoing. More discussion about UX/Visual spec changes, will create patch today with description about this(if they didn't update the spec).

bug 1069135 - [Rose][Woodduck][Case Fail][[Comms]MMS]The "ogg" file will not show play button and save button in MMS.

• • Verified on master and 2.0, but could not reproduce it on both. The weird thing is our qa could reproduce it, so still checking it.

    (Julien) I don't have access to the bug, but isn't it a Music issue ? Usually I redirect such bugs to the appropriate component quite quickly :)

    (Steve) The problem is the ogg music file is missed in the attachment :-/ and I could not reproduce it on my device

    (Julien) looks weird :/

    (Steve) ya, but will let you know if I can reproduce it

• About Woodduck: Since partner create the bug as certified, we don't have to jump into it until our QA verified that it's also general issue on flame. If you ni? by partner or PM without QA verified first, just flag QAwanted first.

  (Julien) ok thanks ! we're not Cc in most restricted bugs anyway :p

  (Steve) Ya, that's good  :p I could help to filter out the general issue if necessary.

  (Julien) if you can add us on the bugs that are reproduced, then it would be nice :)

  (Steve) Sure!

Today:

• Keep moving bug 1021608
• Some noise from Woodduck bugs, will try to filter out the general issue first.

Julien

• bug 1054989 (DSDS send button refresh):
  • landed \o/
• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • tried to build a debug build so that I could give a stack trace to Ben Turner, but Hamachi has not enough storage, and I couldn't build for Flame... will resume today
  • (still) haven't looked why our use case worked in v1.4.
• bug 1053708 (make main interface RTL friendly)
  • sent more mails on www-style ;)
  • some more changes in the PR; I finished sms.css, and started other css files. For now it seems to work on LTR at least, haven't checked in RTL yet :)
• reviewed the subject refactoring patch from Oleg (bug 1067228)
• helped gecko guys on a failure in a SMS test after their patch (bug 1062323).
  • Before, Promise's then was synchronously running the callback; now it's fully asynchronous (as if it was inside a setTimeout).

    (Oleg) Heh, nice to know, thanks!

  • also helped with another unit test failure they have, in system

Other:

• Bug triaging like every day
• was especially pissed off by the Tarako bug 1069322

Today:

• will continue working on bug 1063658 for the blob related issue
• will do reviews
• will continue work on bug 1053708

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Got first feedback from Julien, updated PR, replied questions and asked some :) (in review)
• bug 1058459 - [SMS] Data shared from other applications are not shown as Drafts until the app is killed and open again
  • No progress so far
• bug 1003843 - Follow up to bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads
  • Took this bug, working on it (in progress).

Other:

• Created simple pad to track our in-house code style guidelines https://etherpad.mozilla.org/sms-code-style-guidelines

  (Julien) should we add it on https://wiki.mozilla.org/Gaia/SMS, or should we put it in a readme file inside the sms directory once it's ready? (or both: add it now on the wiki while we work on it, and then remove it when we move to a readme file ?)

  (Oleg) The last option sounds the best to me :)

  (Julien) me too; I'll let you do it ?

  (Oleg) Sure

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Day 9: 26th September

Steve

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • Seems we still miss the download failed case here. In the thread ui view we display error icon for the re-download mechanism. But UX/Visual are not in office today, so I might need to create another bug for it if necessary...
  • Visual part is ready, but some problem in resend mechanism(and follow up page update part) looks like more tests needed here.

bug 1069135 - [Rose][Woodduck][Case Fail][[Comms]MMS]The "ogg" file will not show play button and save button in MMS.

• • After more testing here, it's operator issue :-/

    (Julien) good for us ;)

bug 1069817 - [sms] localization missing for unknown contacts

• • Since ankit unassigned himself, will solve it ASAP

Today:

• Keep moving bug 1021608
• Fix the missing localization string issue in bug 1069817
• Review Luke's focus issue patch.

Julien

• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • got a debug build working on Flame, but... couldn't get a stack trace from gdb when the app crashed. Will got some help from colleagues today.
  • (still) haven't looked why our use case worked in v1.4. Most probable is that we had a workaround somewhere...
• bug 1053708 (make main interface RTL friendly)
  • some more changes in the PR; I finished sms.css, and started other css files. For now it seems to work on LTR at least, haven't checked in RTL yet :)
  • will ask for a first review today
• reviewed the subject refactoring patch from Oleg (bug 1067228) (again)
  • Very confident we'll land this today :D

Other:

• Bug triaging like every day
• fixed other unit tests issues with newer mocha (bug 874510). Will put this on pause today to work on sprint-related stuff first

Today:

• will continue working on bug 1063658 for the blob related issue
• will do reviews
• will continue work on bug 1053708

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Got second round of review comments, updated PR with the separate commit (in review).

    (Julien) will work on it first thing today

    (Oleg) Oh, forgot to mention, found a bug with segmentinfo banner (made by me with this.previousSegment). We didn't clear it after we send message, so I added fix + test for this in this patch

    (Julien) ok :)

• bug 1058459 - [SMS] Data shared from other applications are not shown as Drafts until the app is killed and open again
  • No progress so far

    (Steve) If it's not a blocker, will you use Broadcast API instead? or simply keeps current sharedWorker patch(I think it's fine actually)

    (Oleg) I think we need to move forward with SharedWorker for now, but implement a bit more logic to deal with dead ports.. Not sure when BroadcastChannel API will be available...

• bug 1003843 - Follow up to bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads
  • Attached patch to the bug, testing (in progress).
  • Have concern about performance in group MMS case, in the new spec thread item should display list of thread participant names divided by comma, so should we load every contact even that just a few names will fit into thread item? Not sure how to detect "the right number". Do you have any ideas? Or my concern isn't valid?

    (Julien) I'd say we should take 2, and terminate with ", ..." :) should be good enough.

    (Julien) that said, I also think we should try to take real contact names; so say if a phone number does not resolve to a contact, we can ignore it unless no other number resolve to a contact. There is a separate bug for this so you can ignore this here if you want.

    (Oleg) But what if we had very short two names like "A" and "B"

    (Julien) will be "A, B, ..." :) won't happen in real life, and good enough IMO. What do you think?

    (Oleg) Can't say for everybody, I don't use MMS and I have only first names in contacts :) Or maybe a lot of contacts in group mms is rare case?

    (Julien) I don't think it's rare case; what happen with first names for you? It doesn't fill the line? We can also take first names only in this case, BTW, but ask Jenny about this...

    (Oleg) Yeah, it occupies just a bit of space

    (Julien) and if we take 3 ?

    (Oleg) 3 is better :) Steve, not sure about Chinese names? Are they short ? :)

    (Julien) Right, Chinese names are shorter :)

    (Steve) Yap, in the most cases :p

    (Julien) maybe we can do something like: when loading the first pass, we just resolve the first contact like we do now; then when we loaded everything, we can revisit group MMS threads and resolve all contacts.

    (Oleg) One more option is to probably dynamically guess how many chars we can fit

    (Julien) depending on window.innerWidth? Yeah why not, it's not a big deal if we guess badly. Good for me :)

    (Oleg) Yep, okay will give it a try

Other:

• Read CSS materials from Julien's email, I think we can try new approach with new naming and blocks-elements-modifiers notion as first step and see how it goes.

  (Julien) maybe let's discuss this in next week's meeting, or have a separate meeting about this? Or start another etherpad?

  (Oleg) "Next week's meeting" - planning meeting?

  (Steve) Another pad would be more clear

  (Julien) ok, let's do this; a pad with the options and differences between options :) Who does this pad? No need for urgency :) Can wait next week ! Oleg you can take care of it?

  (Oleg) Sure, just quick question: can't we have CSS section here https://etherpad.mozilla.org/sms-code-style-guidelines ?

  (Julien) yep, good suggestion, let's do this :) thanks

  (Oleg) nice :)

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Day 10: 29th September

Steve

• bug 1021608 - [Messages] Consider adding a "resend" button in the message report page, if there is an error, and other visual refresh
  • First WIP given, replying the feedback and still checking with UX about the not-download part.

bug 1069817 - [sms] localization missing for unknown contacts

• • No progress last Friday, will update today.

    (Julien) maybe this can wait tomorrow's new sprint

    (Steve) ok

Today:

• Keep moving bug 1021608
• Fix the missing localization string issue in bug 1069817

Julien

• looked into the strange blob-related issue that appeared while I was in holidays (bug 1059233); should have been fixed in gecko... (bug 1063658 might be this)
  • we got a stack trace thanks to Alexandre Lissy... I hope Gecko developers will be able to find the issue.
  • (still) haven't looked why our use case worked in v1.4. Most probable is that we had a workaround somewhere...
• bug 1053708 (make main interface RTL friendly)
  • had a finished patch... until I rebased with Oleg's work ;)
  • will ask for review soon
• reviewed the subject refactoring patch from Oleg (bug 1067228) (again)
  • landed !

Other:

• Bug triaging like every day

Today:

• will continue working on bug 1063658 for the blob related issue
• will do reviews
• will continue work on bug 1053708
• will prepare sprint for tomorrow + add some demos

Oleg

• bug 1067228 - [Messages][Refactoring] Move subject management to a separate component
  • Landed (landed).
• bug 1003843 - Follow up to bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads
  • Added support of loading contact info for group thread only while we have space in thread title to display participant names.
  • Have almost ready patch, waiting for reply from Fang about default picture for the unknown contacts.
  • Will ask for early feedback if don't get reply, otherwise will ask for review :)

    (Julien) Steve, maybe you can ask Fang to look at this soon? Should not take too much time for her :)

    (Steve) No problem ! We got some event this morning, I think she would be able to reply later.

    (Oleg) Thanks. I've heard some loud laughing (looks like that event) while looking at Eric's video in the today's bug :)

Today:

• Will handle review comments for the patches that currently in review;
• Will handle review requests.

Demos

bug 1054989: [DSDS] Send button refresh

• 

  Before

• 

  After

bug 1021608: Report panel refresh

This bug has not been completely finished during the sprint.

• 

  Before

• 

  After

bug 1003843: Thread List visual refresh for contacts without pictures and group threads

This bug has not been completely finished during the sprint.

• 

  Before

• 

  After

bug 1053708: Make the SMS user interface RTL-friendly

This bug has not been completely finished during the sprint.

• 

  Before

• 

  After

• 

  Before

• 

  After

• 

  Before

• 

  After

• 

  Before

• 

  After

Retrospective

Previous sprints' actions

From 2.1S3:

• Look into VM with gaia dev environment
  • I've checked out FoxBox, looks like it's the best way to go, but we still need to adapt it a bit for our needs: 1. maybe update guest OS to the latest one to simplify loading of dependencies, 2. Provide some tips and tricks for the inside VM - like set of shortcuts to build debug\release, work with PR and etc. Maybe install IRC client :)

    (Julien) what do we want to do here exactly?

    (Oleg) I'd like to fix issues in current default FoxBox installation - it didn't work for me out of the box; Provide additional script that will adopt env for SMS development more. At least this for now. And provide link to fox box from our SMS wiki/Readme

    (Julien) oki !

From 2.1S4:

• add a README.md explaining the first steps for contributing to SMS

  (Julien) not done this time, let's keep it because it's important

What was good in the last sprint

• We did lots of work

What was bad in the last sprint

• some visual refresh is not finished in time...
• we did not finish lots of work ;)
• Refactoring estimates weren't quite right

  (Julien) +1, we need to increase estimations for refactoring stuff.

  (Steve) ya, we always underestimate the refactoring item

  (Julien) we need to take care for refresh too. We're quite good at estimating for "normal" bugs but not for the other type of bugs yet :) We need to keep doing the "split the bug in tasks" to estimate.

  (Steve) For the refresh item, it seems we easily ignoring some details, and need to confirm with UX/visual again while implementation. I remember we have spec review in the previous release, but didn't do this spec review now.

  (Oleg) Yeah, I think the full spec is the point, it would be great if we have up-to-date ongoing (maybe versioned) spec, that we or UX can update - so that we don't miss stuff

  (Julien) I think it's part of the agile way to not have full spec and discussing with designers during sprint. We just need to take this into account when estimating, and also try to discuss before the sprint (but we easily ignore things when we don't try to implement the spec, like Steve said)

  (Oleg) Yep, by full spec I meant at least list of possible cases that need to be covered

  (Steve) No full spec review during the sprint is right, but we actually added lots of refresh issue in this release, but these items is not committed while planing.

  (Julien) what do you mean "we added lots of refresh issue in this release" ?

  (Julien) any action we can take to avoid estimation issues in the future? Take care to refresh/refactoring bugs and split into tasks big bugs? (also last time steve was not here to estimate, maybe we missed him :D)

  (Steve) I mean, in 2.0 we knew we got visual refresh item and must be done in 2.0 release, so we review the spec carefully before implementation. But the refresh in 2.2 is more likely "nice to have", so we didn't plan for it carefully.

  (Julien) yeah it's more "adhoc".

  (Julien) ok, as an action, we can try to have more actionable bugs. But that means we need to look at bugs earlier and ask UX/Design earlier. So maybe in planning for sprint N we can try to pick refresh bugs for sprint N+1 so that we can ask earlier to Fang and Jenny? Without committing to them, just trying to plan in advance? In ideal world, we should do this for 3 or 4 sprints in advance in one "release planning" :) http://www.scrum-institute.org/Release_Planning.php

  (Oleg) That would help, I'll also try to make some wiki page "Current State of App" with screenshots grouped by panels/views with different cases (like not-downloaded for report and etc. that weren't visible to UX initially, but we clearly see this in code as developers), so that is easier to analyze the front of work :) I remember the same missed cases during Thread redesign, some not obvious cases where missed initially.

  (Julien) I'm adding some lines in the 'actions' part, tell me if that's good for you

  (Oleg) Good for me :)

  (Steve) +1

Any questions

• Since we got longer release cycle now(6 month), do we have any long term planing from BD/UX feature request? The only long term item I could image is only engineering issue.

  (Julien) as I understood, UX is working now, and we'll have planned features only in November. I don't completely like this, I think this could be more open (we can maybe ask later today).

  (Steve) +1 for opening UX WIP status, it would be great if we could provide any suggestion for new UX.

Actions for next sprint

• in planning for sprint N, we pick some items we want to do in sprint N+1 to ask early questions to UX and Designers (esp refresh bugs, but also bugs with UX changes)
• we'll add screenshots of panels in Wiki, with the various cases for these panels, to help analyzing change impacts and not forgetting things
• ask UX about WIP status for v2.2, so that developers can give ideas and feedbacks