Gaia/SMS/Scrum/2.1S1

From MozillaWiki
< Gaia‎ | SMS‎ | Scrum
Jump to: navigation, search

List of bugs

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

Bugzilla link

Full Query
ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
944249 Julien Wajsberg [:julienw] [Messages] move the segment information request and size check to compose.js --- No cf_feature-b2g [p(2.0S6)=3][p(2.1S1)=2] FIXED
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
1015841 Oleg Zasypkin [:azasypkin] [Messages][Refresh] Recipients panel visible area handling --- No cf_feature-b2g [p=2] FIXED
1026694 Oleg Zasypkin [:azasypkin] Access to attach button --- No cf_feature-b2g [tako][p=1][2.1-feature-qa+] FIXED
1035279 Oleg Zasypkin [:azasypkin] [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file --- No cf_feature-b2g [sms-sprint-2.0S6][p=1] FIXED
1037661 Steve Chung [:steveck] [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded --- No cf_feature-b2g [273MB-Flame-Support], [2.0-exploratory][p=2] WORKSFORME
1041967 Steve Chung [:steveck] [Messages] do some safe lazy load to improve launch latency 2.0+ No cf_feature-b2g [c=progress p=2 s= u=2.0] FIXED

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


Remaining points and burndown chart

google chart api url for Sprint 2.1S1

Burndown chart
Remaining points
Start 11
Day 2 11
Day 3 11
Day 4 11
Day 5 11
Day 6 11
Day 7 8
Day 8 7
Day 9 5
Day 10 3
End 1


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

Full Query
ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
990021 Oleg Zasypkin [:azasypkin] [Messages] We should show the correct error message when trying to download a MMS in airplane mode --- No cf_feature-b2g [priority][sms-sprint-2.1S1] FIXED
1041124 Oleg Zasypkin [:azasypkin] [Messages][Refactoring] Make use of EventDispatcher in MessageManager --- No cf_feature-b2g [sms-sprint-2.1S1][p=1] FIXED
1042887 Oleg Zasypkin [:azasypkin] Cannot scroll in messages app 2.1+ No cf_feature-b2g [c=regression p= s= u=][sms-sprint-2.1S1] FIXED
1043293 Julien Wajsberg [:julienw] [Verticalhome] use "touchend" instead of "click" to launch applications 2.0+ No cf_feature-b2g [systemsfe][c=progress p= s= u=2.0][sms-sprint-2.1S1] FIXED
1045590 Julien Wajsberg [:julienw] [Messages] make offAll remove all listeners in EventDispatcher --- No cf_feature-b2g [sms-sprint-2.1S1] FIXED
1046248 Oleg Zasypkin [:azasypkin] [Messages] Set explicit background image size for "Add attachment" button --- No cf_feature-b2g [sms-sprint-2.1S1] FIXED

6 Total; 6 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
944249 Julien Wajsberg [:julienw] [Messages] move the segment information request and size check to compose.js --- --- FIXED
1015390 Steve Chung [:steveck] [SMS] Implement new startup loading events --- --- FIXED
1015841 Oleg Zasypkin [:azasypkin] [Messages][Refresh] Recipients panel visible area handling --- 2.1 FIXED
1026694 Oleg Zasypkin [:azasypkin] Access to attach button --- 2.1 FIXED
1035279 Oleg Zasypkin [:azasypkin] [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file --- --- FIXED
1037661 Steve Chung [:steveck] [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded --- --- WORKSFORME
1041725 [meta] SMS subteam sprint 2.1S1 --- --- FIXED
1041779 Arnau March [:arnau] ( not working in Firefox OS anymore :( ) [Messages][MMS] Download button styles are broken --- --- FIXED
1041967 Steve Chung [:steveck] [Messages] do some safe lazy load to improve launch latency 2.0+ --- FIXED
1042887 Oleg Zasypkin [:azasypkin] Cannot scroll in messages app 2.1+ --- FIXED
1046248 Oleg Zasypkin [:azasypkin] [Messages] Set explicit background image size for "Add attachment" button --- --- FIXED

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


Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 23th July

Steve

  • bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
    • Ongoing, but one question about the possible behavior change: Since we save to draft all the time, should we still keep the save to draft option menu? Or we just saving the draft before resizing image in this patch?
      (Julien) in this patch, I think you should do as less as possible :) In the future, I really would like to get rid of the "save to draft" menu... If removing this menu makes the code safer then do it (with Jenny's approval), but otherwise keep it for now.
      (Steve) ya I think so, we should remove the save to draft if we could autosave(If Jenny agrees to do so)
  • bug 1038176 - SMS app launch latency regressed in v2.0
    • Julien took this bug for system/homescreen part, I could focus the loading time in bug 1041967
  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Some I could see some script could be put to lazyloader because they are not necessary for launch call path, but any additional action might lead the unexpected error before everything is loaded. Maybe we could disable the pointer events to prevent other action until lazyloader complete?
      (Julien) maybe you can already try to do some lazy loading without checking for correctness, just to see if it makes the launch time shorter (in production mode) ?
      (Steve) Sure, I can take some safest options to lazyload and profiling first
      (Julien) I mean, you can even try to lazy load more things (even if things are not working yet) and see if this improves launch time :)
  • bug 1015390 - [SMS] Implement new startup loading events
    • Patch landed and we can see the new result on datazilla now
      (Julien) \o/
      (Oleg) Could anybody give me a link ? :)
      (Julien) https://datazilla.mozilla.org/b2g/ relevant measurements start with "startup" (bottom of the screen)
      (Oleg) Thanks!
      (Julien) someone should put a screenshot for datazilla in the demo part :)
  • bug 1041303 - [Tarako][SMS][Notification] Long delay between tapping the new SMS notification in utility tray and displaying the SMS
    • Instead of reducing the loading time, I suggest my colleague to showing the splash screen right after tapping on the notification. The loading time didn't improve in the patch because we didn't have much choice if they want to solve this ASAP, but it actually 'looks' faster because user could know app is launching at that moment.
      (Julien) I've seen the patch is specific to SMS. Don't we have the same issue with Dialer (missed call notification) and others (Email for example) ?
      (Steve) Ya... I also mentioned the Email case in the comments, but seems no one care about other cases :-/
      (Julien) we're neither release manager nor system peers, so... :)

Today:

Julien

  • spent most of my time answering mails about CMAS, the 2.0 performance regression
  • spent some time with Gabriele's GSOC student: he'll change how the "delete" mode works to make it possible to "mark as read/unread" as well, and he needs to understand how some things work.
  • bug 944249: move the send button and segment info management to compose.js
    • unit tests changes are finished and green
    • I want to integrate event_dispatcher to ThreadUI instead of redoing the event machinery
    • won't change the event machinery in Compose because it was existing before the patch

Today:

  • investigate bug 1038176 from the homescreen point of view
  • bug 944249: use event_dispatcher for the new events

Oleg

  • bug 1040215 - [Messages] Move initSentAudio out of enableSend
    • Reviewed, the lates patch, r+'d (landed).
  • bug 898364 - Moving conversation thread database from Gecko to Gaia by introducing DataStore API
    • Will look through the latest answers in datastore etherpad.
  • bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
    • Prepared patch and sent it for review (in review).
  • bug 1042104 - [B2G][Messages] App panel that's sliding in is not visible during transition
    • Noticed the regression caused by one of the latest core layout patches; App panel content isn't visible during transition between panels. Content appears only once transition is finished.
    • Created reduced test case and found culprit commit.
  • bug 1041779 - [Messages][MMS] Download button styles are broken
    • Reviewed tiny patch from Arnau, but noticed that "Download" button is jumping a bit when transitioned to "Downloading..." state, asked Arnau to look into it.
  • bug 1026694 - Access to attach button
    • Started to work on it, asked Fang to provide image assets since icon color has changed + noticed that we didn't have @2x assets for this icon previously.
      (Julien) so that's why it looked somewhat fuzzy. What about the other icon on the header?
      (Oleg) I know that "close" icon also doesn't have @2x asset. We need to inspect everything and raise question to VD about it. I can take care of it. Oh seems "close" isn't used in our stylesheets..
      (Steve) And don't forget to compress the image by yourself(with Gabriel' tool) => tools/png_recompress.sh
      (Oleg) yep
      (Julien) too bad I missed close in bug 1035727 :(
  • bug 829820 - Ability to mark selected SMS threads as read/unread
    • Had several discussions with Kumar about this bug and how to mark thread as unread, looked a bit into the code, but not much, just skimmed through to spot any obvious problems.

Today:

  • Will handle review comments for the patches that currently in review;
  • Will work on bug 1026694

Day 3: 24th July

Steve

  • bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
    • After discussion with Jenny, she tends to agree that we autosave and with image input saving mechanism. It's product call now whether we should implement this for 2.0(although it looks like we still have some problem in home screen and system)
      (Oleg) Just came in mind, if we don't show "discard draft" anymore how can I discard draft in message thread or we will still show that option to the user? To be honest it's not clear to me how thread drafts work at all :) Once I created draft in the existing thread I not sure how to remove it, if I clear input it disappears, but after app restart I see it again. Sorry for bothering if it's another issue :)
      (Julien) Yeah, we have some behaviors that can be tuned. It was supposed to be tuned before shipping, but we never found time with Steve due to blockers. Especially discarding drafts is painful at the time, you're totally right. That said, it makes quite sense that when we press back and enter the thread again, we get the same state. IMO we should even load the draft in beforeEnter instead of afterEnter :) But we'd need an easy way to clear the input.
      (Oleg) Yeah, we need to think of something, maybe we'll plan something for the next sprint.
      (Julien) We especially need UX input from Jenny :)
      (Oleg) Yep, I'll look into draft related issues we have, and ask for UX feedback in some of them, that is the most annoying
      (Steve) I've discussed this with Jenny, it's not confirmed yet but here is what she plans to do: We withdraw the option menu and always autosave. When back to thread view, we will always show the toaster that notify user we saved the draft.
      (Julien) let's discuss this separately :) We can file a separate "draft polish" meta bug to discuss things there. Or on the wiki like Contacts team do.
  • bug 1038176 - SMS app launch latency regressed in v2.0
    • Will investigate the thread rendering delay issue
  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • First step profiling result comes out: I just move 10 script that with not break the app launching into lazyloader, but the result didn't that efficiency: It only reduce 10~30ms in general on master/2.0/1.3t(but lazyloading these 10 scripts took 300ms). Next I could try lazyload everything then init to see the result.
  • bug 1041303 - [Tarako][SMS][Notification] Long delay between tapping the new SMS notification in utility tray and displaying the SMS
    • R+ about the launching the app right after notification clicked with splash screen. Partner might want both fixes(including the disable costcontrol receiving system message).
      (Julien) on bug 1040020, they say it's still 3 seconds when clicking the notification.
      (Steve) Well, it's true because it didn't shorten the time to showing the complete threads...It just show the splash screen ASAP
      (Julien) ah yeah, I thought they said that _launching_ the app was still 3 seconds, but now I read that it's "displaying a message" that takes 3 seconds. If that's matters to them maybe we can try to show it earlier (eg: bypass the transition, things like this)

Today:

  • Create a patch for bug 1037661(at least confirm whether we should do it for v2.0) and profling for about bug 1041967

Julien

  • spent most of my time on the 2.0 performance regression (bug 1038176)
    • looks like every bit is slower
    • homescreen should use "touchend", will try to provide a patch today. With this change vertical homescreen performance for launch is ~ the same than old homescreen
    • the facebook contact lookup makes things slower too, I'll try to look up the actual code today (I don't really want to...)
    • Using SMS from v1.3 on Gecko v2.0, I clearly see that each thread is still slower
      (Steve) Dose that mean a possible performance regression in gecko api(might not be the RIL's problem)
      (Julien) Yep, it's possible (even likely :) ) A real profile comparison will tell (SMS v1.3 on Gecko v2.0 vs SMS v1.3 on Gecko v1.3)
    • we also start rendering threads later in SMS v2.0 compared to SMS v1.3 (on same gecko). Will investigate this bit today.
  • bug 1037661: pressing home discard MMS when resizing
    • I'm pushiing hard to remove the blocker status.
    • I'd stil want the work Steve is doing on it, just not in 2.0 because it's changing core functionality.
  • bug 944249: move the send button and segment info management to compose.js
    • slowly moved here, mostly reordered some commits
    • I'll ask feedback from Oleg today, even if I've not finished the full patch, to make things move faster.
  • bug 1040020: launching time on Tarako
    • looks like the partners really want this
    • I'm asking for expectations vs current measurements
    • the bug is not 1.3t+ (yet ?)
    • talked about this with Wilfred, he sent the notice to Ravi, the Tarako Performance Manager (or something). We'll see.
  • moved forward with handling UX and Design requests for remaining v2.1 refresh work. Good news: the things I didn't want to do are WONTFIX ;) \o/

Today:

  • investigate bug 1038176 from the homescreen point of view
  • look at the various reviews

Oleg

  • bug 898364 - Moving conversation thread database from Gecko to Gaia by introducing DataStore API
    • Put some new comments and replies to Julien's comments. I still think that we need MessageManager to fire specific events (onMessageSending, onMessageReceived, onDelievered and etc) instead of just "onChange|onRemove" since we have a bunch of logic in panels that needs this differentiation.
  • bug 1041779 - [Messages][MMS] Download button styles are broken
    • Reviewed the latest patch, r+'d, asked for v2.0 approval (waiting for v2.0 approval).
  • bug 1026694 - Access to attach button
    • Prepared patch, but still waiting for new assets from Fang (in progress).
      (Julien) sorry, I thought we had everything, but looks like I didn't look close enough :(
      (Oleg) It's ok, I think it won't block that much
  • bug 1042747 - [Messages] Some image assets are missing @2x version
    • Filed this bug to get missing @2x assets for "corrupted", "attachments" and "draft" icons (waiting for ni? from Fang).
    • Also I'd like to use chance to remove unused resources, "clear" and "close" icons.
    • Discovered that we have regression that prevents displaying "not-downloaded" icon in report view. I guess v2.0 affected too, maybe even v1.4 - will check. Though nobody noticed it. For master patch I'd rather wait for Report view VR.
      (Julien) might make sense to file a separate bug for the regression, and ask blocker status
      (Oleg) yeah, will do this.
  • bug 829820 - Ability to mark selected SMS threads as read/unread
    • Left comment on Kumar's PR on inefficient mark as "unread" method, he's marking as unread all incoming messages, while we need to mark only the latest incoming one.
      (Julien) or even, any one :) (but I think the first one is the latest anyway)
  • bug 1003843 - Follow up to bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads
  • Other:
    • As Julien noted we have massive Graphics\Layout regression in Gecko :( Moreover my phones are constantly rebooting with the latest PVT, will roll back to some old version to work on bugs more comfortably.

Today:

  • Will handle review comments for the patches that currently in review;
  • Update assets once I get it;
  • Will work on bug 1003843
  • Will examine draft related issues we have and ask for UX feedback

Day 4: 25th July

Steve

  • bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
    • Since it's moved to backlog, do we still need to create another draft issue for it?
      (Julien) if 2 independant patches can be made, then we can do 2 bugs :) otherwise we don't need to.
  • bug 1038176 - SMS app launch latency regressed in v2.0
    • In bug 1041303, it seems module init might also affect rendering with obvious delay. Will take a deep look to see which module init affected most(settings init take ~100ms!)
      (Julien) I've seen that the initRecipients in ThreadUI.init takes a lot of time too. But we haven't changed this much since v1.3... Looks like it provokes at least a reflow, which we can try to avoid in the startup. Maybe we can try to call init in beforeEnter only?
      (Steve) That's what I'm trying to do in bug 1041967, to delay the other module loading and init. Doing init in beforeEnter sounds reasonable, but maybe it could affect the panel transition animation.
      (Julien) yep, we need testing...
      (Oleg) just on the related note, I'm experimenting with calling init in lazy getter like this https://github.com/mozilla-b2g/gaia/pull/21997/files#diff-af7a3fb259f614cb38f498ee6deedb0dR459. So once any code really needs it, init is called automatically. But yes it needs testing.
  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency

https://www.youtube.com/watch?v=uyN3Q1j9aB4&list=UUkM1XSMB9c0p9684qCa6ZAA

  • Discuss with Jenny about the new message report UX spec:
https://drive.google.com/a/mozilla.com/file/d/0Bx_3KVci6YdOU3VqU1FfQnhYWlk/edit?usp=sharing
    • (Oleg) Do I need to some special permission for this? I can't see it with my Mozilla's Gmail account..
      (Julien) I don't either. Steve, can you ask Jenny to make it open by default?

Today:

  • Create a patch for bug 1037661(at least confirm whether we should do it for v2.0) and profling for about bug 1041967

Julien

  • spent most of my time on the 2.0 performance regression (bug 1038176)
    • looks like every bit is slower
    • homescreen should use "touchend", will try to provide a patch today. With this change vertical homescreen performance for launch is ~ the same than old homescreen
      • provided a patch, proved to be more difficult than expected, because Gecko automatically prevents mouse events while scrolling, but not touch events. => bug 1043293
    • the facebook contact lookup makes things slower too
      • looked it up but didn't see an obvious gain
    • we also start rendering threads later in SMS v2.0 compared to SMS v1.3 (on same gecko). Will investigate this bit today.
      • did a profile but again, nothing very obvious
    • published the profiles on the bug
  • bug 1037661: pressing home discard MMS when resizing
    • out of blockers list :)
      (Oleg) yay!
  • bug 944249: move the send button and segment info management to compose.js
    • didn't move much
  • bug 1040020: launching time on Tarako
    • Wesley pushed back, might come back though.
    • we now have clearer expectations

Today:

  • continue the perf investigation

Oleg

  • bug 1041779 - [Messages][MMS] Download button styles are broken
    • Still waiting for v2.0 approval. Should I ask approval from anyone specific or just approval request without specific person is fine? (waiting for v2.0 approval).
      (Julien) I usually ask to :bajaj but she's in holiday. You can ask :lmandel.
      (Oleg) Ok, thanks!
  • bug 1026694 - Access to attach button
    • Updated patch with the latest assets from Fang, but since I've rebased patch on master now it depends on "bug 1043518 - Typing a long message or contact-name in SMS app will push the "send" / "add contact" buttons offscreen" as it will be really difficult for reviewer to understand that patch works correctly.
      (Julien) yeah, those unexpeced blockers are really unfortunate
  • bug 1042747 - [Messages] Some image assets are missing @2x version
    • Just got @2x resource from Fang, will prepare patch today. Also filed bug for the "not-downloaded" status in report view (in progress).
  • bug 1043273 - [Messages][MMS] Report view doesn't indicate that MMS hasn't been downloaded
    • Filed bug and asked for v1.4? blocker status (waiting for blocker status).
      (Julien) I think it's too late for 1.4 but well. You can NI :lamndel too here.
      (Oleg) Ok, maybe it will become v2.0? then. To be honest I'd rather make it for 2.1 only :) Don't see much value in this indicator :)
  • bug 1003843 - Follow up to bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads
    • Prepared patch, asked for UX feedback, but since requirement is going to change will wait for new spec. As per latest comment from Jenny I think it's more [p=2] now.
  • bug 1043445 - [Messages][MMS] It's impossible to send or manually download MMS with "smartmobil.de" SIM
    • Spent some time bisecting this strange issue that affected only one my SIM card, found APN configuration bug that caused that, asked for v2.0 blocker status and ni?'d guy who introduced that config change. Looks like that bug was already causing some issues for ATT SIM card previously.
      (Julien) I hope we won't need to wait for other users to fail...
  • bug 1042887 - Cannot scroll in messages app
    • Since it was reviewed and landed outside SMS team, will verify that everything works as expected. Currently I've noticed the issue that thread is not fully displayed (just small fraction of thread is visible, the rest is rendered but hidden). Will check..
  • bug 1043518 - Typing a long message or contact-name in SMS app will push the "send" / "add contact" buttons offscreen
    • Will review that too if you guys don't mind. I know Julien doesn't like when somebody asks for review not from SMS peers :)
      (Julien) hey in this case I asked for it in the other bug ;) I can't blame him ! I'm fine if you review it but don't hesitate to ask if you need anything. Cases to check are mostly: short message, long message, being able to scroll the composer, add lots of recipients and still being able to focus; in the thread view, being able to scroll the messages to the top and to the bottom whatever the message length. (Maybe we should make these cases integration tests)
      (Oleg) sure, I'll try to check as much cases as I can imagine :)
      (Oleg) Regarding to integration tests - after such problems, I think we should do it! :) Not sure though if current assignee should do it, I think I can...
      (Julien) Yep, we can file a separate bug for this
      (Oleg) Ok, will file issue for integration tests.

Today:

  • Will handle review comments for the patches that currently in review;
  • Will review consequences of bug 1042887.
  • Will examine draft related issues we have and ask for UX feedback (didn't have time for that yesterday)
  • Will file issue for integration tests for thread panel.

Day 5: 28th July

Steve

  • bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
    • Not much update here, I think it's reasonable to created another bug for draft handling issue
  • bug 1038176 - SMS app launch latency regressed in v2.0
    • See bug 1041303, I'll utilize EventDispatcher to notify that we could continue the pending request
      (Julien) you don't like my Promise-based idea ? :)
      (Steve) Hmm, it some how more straight forward using the event handling, I'll update later and you can give more feedback then.
      (Julien) ok, event can be good too but it looks a little more complex. (but not clearly different)
  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Patch created, loading time and indexedDB request performance seems improved with lazyload in delay init. About the css minified, my sysplatform colleague already tried before, but it was depreciated because the performance didn't improve much. But maybe concatenate css files could still able to improve the loading time. Will try it manually.
  • Discuss with Jenny about the new message report UX spec:
    • Some more discussing, she will public the latest spec later and we might remove the received message status anyway in the latest spec

Today:

  • Still on bug 1041967, will update patch again with tests.

Julien

  • spent most of my time on the 2.0 performance regression (bug 1038176)
    • bug 1043293: make new homescren use "touchend": I have a working patch with working unit tests, but marionette JS tests are failing and I'm stuck. Kevin proivided a patch over the week end so I'll look at it again.
    • the facebook contact lookup makes things slower too
      (Steve): It does affect the message DB cursor iteration speed a little bit, when both things running at the same time.
      (Julien) okay; could be better to load all cached contacts for the first threads in memory somehow, but not sure if the complexity is worth it...
      • didn't look at this again. A possible idea is to cache the lookups in a local indexeddb or other storage so that we can access them possibly faster, at least for the 10 first threads.
    • we also start rendering threads later in SMS v2.0 compared to SMS v1.3 (on same gecko).
      • Steve provided a good patch in bug 1041967, I'm confident this will fix this
  • at last spent time to answer Oleg's patch on Event Emitter: bug 1041124
    • some ongoing discussion about the event model but nothing blocking the progress

Today:

  • Will try to finish the patch for the homescreen
  • also make the patch for bug 944249 ready for review (I want to do some code, investigating perf stuff is so boring and I'm not good at it)

Oleg

  • bug 1026694 - Access to attach button
    • Prepared patch and sent it for review (in review).
  • bug 1042747 - [Messages] Some image assets are missing @2x version
    • We agreed with Pavel that this bug can be duped in favour of "bug 1035687 - [SMS] - check missing images".
  • bug 1003843 - Follow up to bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads
    • As we're waiting for the new spec, moved bug back to the "NEW" status.
  • bug 1043445 - [Messages][MMS] It's impossible to send or manually download MMS with "smartmobil.de" SIM
    • Silence here...
      (Julien) best would be that you enable the RIL and MMS logs, and tcpdump, and then ask needinfo Bevis with these informations. https://github.com/bevis-tseng/Debug_Tools
      (Oleg) as far as I remember I did this, but logs were clear, looks like configuration prevents that activity, but will check again. Haven't checked with tcpdump yet. Thanks for the link!
      (Julien) yeah, it's pretty clear it's because of the MVNO change, you're right, so probably don't need to provide these logs.
      (Oleg) Ok
  • bug 1042887 - Cannot scroll in messages app
    • Reviewed consequences of the initial emergency patch, found out that loading messages by chunks on scroll was broken, so prepared fix for it (landed).
  • bug 1043518 - Typing a long message or contact-name in SMS app will push the "send" / "add contact" buttons offscreen
    • Reviewed patch from Daniel, looked fine just asked to add "min-width: 0" for the message-body too as we had problems with long strings inside message bubbles after Daniel's patch (landed).
    • Filed follow-up about integration tests that can help to prevent such breakages in the future - "bug 1043903 - [Messages][Tests] Add integration tests for the thread panel with a large number of messages"
  • bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
    • Fixed some review comments from Julien, will continue today.
  • bug 1044224 - [Messages][Tests] Generate assets on the fly instead of loading it with XHR
    • Prepared initial patch for utils tests only and asked for feedback (awaiting for feedback).
  • bug 1043903 - [Messages][Tests] Add integration tests for the thread panel with a large number of messages
    • I'm thinking to give it a try today, since it's quite important after all that flex bugs :(

Today:

  • Will handle review comments for the patches that currently in review;
  • Will leave feedback for "bug 1035687 - [SMS] - check missing images"
  • Will examine draft related issues we have and ask for UX feedback (didn't have time for that yesterday)

Day 6: 29th July

Steve

  • bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
    • Discussed with Jenny and she need a little more time for the spec if we really need autosave, so I'm create another bug for it.
  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Patch updated with LinckActionHelper reset removal.
  • Tarako issue about insufficient app storage space....
    • Partner are arguing that contact app might occupied too much pace(30MB, tarako only got ~60MB when system is clean...), Not sure how many contacts they added or imported from FB/gmail, but we might need some solution/workaround for it. Just looked into contact photo and we might have some room if we reduce the size of image(contact photo imported from FB will saved as PNG by default. Maybe we need to convert to jpg before saving to DB).
      (Julien) what's the bug # ?
      (Steve) I just asked by pm to investigate the contacts side, will find them for the bug # later => bug 1045503
      (Julien) an easy win is.... remove the concatened files from the zip files !!
      (Steve) concatened files?
      (Julien) you can look at the zip files for applications; there are both the gaia_build_defer_index.js file and all the other files that we don't use anymore in production mode.
      (Steve) I see, you mean removing the scripts after we concatened them
      (Julien) yep. At least try manually and see if this makes a good win.
      (Steve) Thanks, I'll talk to yuren about it.
  • Discuss with Jenny and Fang about the new message thread ui view spec:
    • We might have a little bit different bubble styling in the future, and maybe removing the spin cursor for less cpu consumption.

Today:

  • Still on bug 1041967, will update patch again with tests.

Julien

  • performance stuff:
    • bug 1043293: make new homescren use "touchend": not moved much yesterday.
    • bug 1041967: reviewed the good patch from steve, will review again today. With this patch, the initial delay is barely noticeable.
  • bug 944249: send button and segment info refactoring: at last I've put a patch into review !
  • Filed bug 1045058 with a WIP patch to make Compose use EventDispatcher

Today:

  • Will try to finish the patch for the homescreen
  • fix review comments for bug 944249
  • investigate bug 1035471 only to find possible solutions so that I can ask Fang about it
  • need to look at CMAS implementation in a separate app; notably look at attention screen and discuss with dialer peers and gabriele about it.

Oleg

  • bug 1026694 - Access to attach button
    • Got feedback, Steve noticed that Compose tests are failing, investigating at the moment. Looks very strange, sync test causing timeout, locally it just hangs, no errors in console (investigating)
      (Julien) ping me if necessary !
      (Oleg) Sure, thanks!
  • bug 1035687 - [SMS] - check missing images
    • Left feedback to Pavel, some images weren't fully removed, some caused UI inconsistency, and large amount of images that were compressed didn't change size in reality, so I'm in doubt why do we need to update images in the patch if nothing is changed in terms of size.
  • bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
    • Fixed the rest of review comments, will send for review today (in progress).
  • bug 1044224 - [Messages][Tests] Generate assets on the fly instead of loading it with XHR
    • Got feedback+, will continue with other tests once I have spare time (in progress).
  • bug 1015841 - [Messages][Refresh] Recipients panel visible area handling
    • While experimenting with different solutions found a v2.0-v2.1 bug - "bug 1045493 - [Messages] It's impossible to activate recipients input field once all recipients were deleted in expanded mode";
      (Julien) I can test on v1.4/v1.3 to see if this is a regression (NI me)
    • Going to provide JS based solution just in case we don't find CSS\HTML one as I don't see currently any low risk CSS-only change (in progress).
      (Julien) and do you have high risk ideas ? :)
      (Oleg) I mean risk in terms of performance (like if we replace translateY with max-height or something, that will cause reflow of underlying compose container). I see that we use translateY to show panel. Is that done for high performance?
      (Julien) it's done so that the animation when swiping the panel is smooth. We can't change it :)
      (Oleg) Yep, and we have a bunch of dependencies on the height of recipient panel: composer container, suggestion list
      (Julien) I don't see a CSS-only solution for this but I'm not very good at CSS ;)
      (Oleg) I don't see either :) So at least we'll have something to think about, take or not take js solution. I don't like to implement JS solutions for such things :)
      (Julien) that's why we left it out for v2.0. But I admit it does not look good currently.

Today:

  • Will handle review comments for the patches that currently in review;
  • Will leave feedback for "bug 1035687 - [SMS] - check missing images"
  • Will work on JS solution for bug 1015841.

Day 7: 30th July

Steve

  • bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
    • Jenny declined the draft auto saved idea. Since release driver changed the memory testing target to 319MB and it not reproducible on 319 MB limitation, maybe we should close it?
      (Julien) I'm sad that Jenny doesn't like to autosave, but maybe this needs more UX thought than doing it in urgency. If there is no more bug and no more work, I guess we can close this.
  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Patch Landed and request for 2.0 approval.
      (Julien) I also added a blocker request (blocks a blocker)
  • bug 1045503 - [tarako][contacts] we should reduce the use of storage by contacts app
    • I might need to look into this issue before Francisco reply...
      (Julien) I'll ping him later on. But if the issue is about toDataURL/toBlob it can be easy to fix. Note that the facebook code is maybe in shared.
      (Steve) If we need to toBlob convert , the main problem would be performance... Doing contact import and toBlob at the same time seems very dangerous on Tarako(For both CPU usage and memory usage)
      (Julien) I mean, maybe they're doing it already. Actually I'm quite sure they already save a thumbnail at import time (instead of using mozsamplesize, see bug 1024553)
      (Steve) For thumbnail, yes they did it in import time,
    • Yuren already have a bug to the removing the script, but since they are focus on the usage in contacts DB, we might need to provide a quick testing patch for converting the format ...
  • bug 944249 - [Messages] move the segment information request and size check to compose.js
    • Reviewing, still half way but I might need to give a patch for 1045503 first... :-/ One main issue is the in the updateSegmentInfoThrottled. We should avoid to trigger it in some situation(like subject change)
      (Julien) I'll look into this specific issue today, thanks !

Today:

Julien

  • performance stuff:
    • bug 1043293: make new homescren use "touchend": moved forward with fixing the tests. It's quite new for me because it's integration tests using marionette JS. Fortunately I already looked at them earlier :) Some tricky issues still.
    • bug 1041967: reviewed and landed.
    • I'll ping Gabriele to have further profiles especially around thread rendering.
  • bug 944249: send button and segment info refactoring: in review
  • bug 1035471: Tamil characters are cut off; we have a possible cause but I still don't get why this sometimes works. I asked 2.0 on this and won't work more on this until we have a clear blocker status.
  • discussed with Anthony about CMAS-in-a-separate app, especially relating to attention screen. I'll try to do a PoC today, to show the feasibility. I still need to discuss with Gabriele to understand why the whole cell broadcast feature was made in System app.
  • reviewed the MADAI bug 959011: send predefined messages when rejecting a call. Discussed also with Anthony about it, and we want to do further tests to understand better how returning results with activities work. Especially differences between window and inline activities.

Today:

  • Will continue the homescreen patch
  • fix review comments for bug 944249
  • look more at CMAS implementation in a separate app

Oleg

  • bug 1026694 - Access to attach button
    • Found out that lack of "type=button" on attach button element was causing unit tests to fail. Fixed. (landed)
  • bug 1035687 - [SMS] - check missing images
    • Left my feedback in bugzilla and github. Since Pavel asked review from SMS peer, removing feedback request from myself :)
      (Julien) will redirect the review to you ;)
      (Oleg) :) ping-pong. What do you think about images that didn't change size in the patch that was intended to reduce size? I think it's unnecessary risk if we don't have value...
      (Julien) I can have a look ;)
      (Oleg) Yeah, that would be nice :)
  • bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
    • Fixed the rest of comments and sent for review (in review).
      (Oleg) Julien, please don't review it until I rebase it on the latest master, I see I'll have conflicts with the latest Steve's lazy load and your EventDispatcher.offAll patches :)
      (Julien) oki, maybe remove the R request until then?
      (Oleg) Yep, will do
  • bug 1044224 - [Messages][Tests] Generate assets on the fly instead of loading it with XHR
    • I think I'll have time today to finish it (in progress).
  • bug 1015841 - [Messages][Refresh] Recipients panel visible area handling
    • Prepared JS-only WIP patch and asked for feedback to avoid wasting time on improvements in case it isn't accepted.
  • bug 1035279 - [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file
    • Removed enums and reduced errors.js unit tests (in review).

Today:

  • Will handle review comments for the patches that currently in review;
  • Hopefully will work on bug 1044224 and bug 1043903.
    (Julien) maybe you can also have a look to some nominates? bug 1043273 for example, or bug 1035471.
    (Oleg) I'll finish bug 1044224 since I need just a bit time already :) And will look into nominations, not sure about bug 1043273 though - nobody made it as blocker and we don't need it in v2.1. bug 1035471 sounds worth of investigating - will check.

Day 8: 31st July

Steve

  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Backed out on 2.0 because of python UI test crash... But I think it's not related to our patch anyway.
  • bug 1045503 - [tarako][contacts] we should reduce the use of storage by contacts app
    • Find out the root cause in canvas.toBlob api, Need to be careful about the image mime type for conversion next time
  • bug 944249 - [Messages] move the segment information request and size check to compose.js
    • Finish the review, I think the most of part is good. The only concern is we might need to minimize the calling of getSegment api. I think we won't need it in MMS while composing mms.
  • bug 983172 - Parsing jpeg header information for downsampling the image for thumbnail
    • It's great to see some image utility in shared! Still reading the image utility and thinking what we can take for thumbnail(maybe we could use ImageUtils.resizeAndCropToCover() directly, or simply use getSizeAndType and downsample directly for saving more memory if we don't need the precise size)

Today:

  • will start 983172 for saving more memory in image handling case.
  • Clean up the reset of review.

Julien

  • performance stuff:
    • bug 1043293: make new homescren use "touchend": looked at it a little but couldn't find the solution to one of the issue I have in the tests, I intend to focus more on this today.
    • pingued Gabriele, he's busy with other things but hopes to do this soon.
      • do any of you know how to interpret a profile? I tried but I can't find anything very useful :/
      (Oleg) I hoped that anybody from you can explain it to me someday :D
      (Julien) I can do _some_ interpretation ;)
      (Steve) What would you expect from the profiling result? Which function or API takes the most of time in the call path?
  • bug 944249: send button and segment info refactoring: in review
    • changed a logic about what we do when the user changes the subject
    • need to look at Steve's latest comment: what happens if we don't update the segment info in "mms" mode?
      (Oleg) will it be fine if we have MMS just because of subject, and once we remove subject, do we update segment info right away? Don't remember
      (Julien) currently I don't, but I'd request the segment info as soon as we move back to "sms" if I do this change.
      (Steve) Ya I think that would be necessary if we don't check segment while composing mms.
  • reviewed various other patches, nothing much to say :)

Others:

  • lots of madai bugs were changed to confidential, so if you need access to one of these bugs ask me
  • David Flanagan landed a good image util in shared/js/image_utils.js, we should try to use it where necessary (ex: bug 983172)

Today (about the same than yesterday ;) ):

  • Will continue the homescreen patch
  • fix review comments for bug 944249
  • look more at CMAS implementation in a separate app
  • need to look at the MADAI predefined response bug too.

Oleg

  • bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
    • Rebased on the latest master, resolved conflicts and sent for review (in review).
  • bug 1044224 - [Messages][Tests] Generate assets on the fly instead of loading it with XHR
    • Introduced assets_helper for loading and generating assets in tests and replaced with it every direct call to XHR in other tests (in review).
  • bug 1015841 - [Messages][Refresh] Recipients panel visible area handling
    • Got feedback+, just noticed that at the end of transition to-panel its height slightly reduced. I can spot it on flame, but not on buri, will check in browser. Not sure what is the reason.
    • Was thinking about css only solution again - still can't think of any solution that wouldn't affect performance.
      (Oleg) So, guys, should I proceed with JS solution or ...?
      (Julien) if we don't see slowness with the JS solution, I think we can go with it. We should try with a workload with a lot of threads (to see/feel the reflows). You can also turn on the reflow counter to see if the counter is bigger, but I'm wary of false alerts here.
      (Julien) since it does not happen in the thread, but in the composer, we also have a lot less elements to deal with.
      (Oleg) Yeah, it's for composer panel only, not sure that workload affects it anyhow
      (Julien) a big several-threads workload would affect, because the threads are loaded in the inbox, and so can be part of reflows. But if the change we make here is well contained, then it should not affect them. I don't really know how to check this except that it takes a lot of time or it does not. See http://paulrouget.com/e/fxoshud/
      (Oleg) So you mean the case when threads are loading (in ThreadListUI -> getThreads) and we enter into compose panel at the same moment?
      (Julien) no: when we're in the composer, the inbox panel is still "displayed" off screen. So it can be part of a reflow if a change in the composer _can_ affect it (the rules are quite complex). But maybe it does not in this case !
      (Oleg) Oh, ok I'll try to check, thanks for the link!
      (Julien) There is another very useful link that I can't find right now, I'll ask and share later
  • bug 1035279 - [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file
    • Landed (landed).
  • bug 1046248 - [Messages] Set explicit background image size for "Add attachment" button
    • Noticed that I forgot to add explicit background size for add attachment button that led to bigger-than-expected icons on HD devices (landed).
  • bug 1035471 - [B2G][2.0][l10n][SMS] Tamil: "(No Recipient)" string is cut off in the messages list.
    • Started to look into that. Can reproduce it on my flame, for now I see that this text is affected by BB styles only, will investigate further.
      (Julien) if you can understand why it does not reproduce on some cases (Flame 2.1), I'd be happy :)
      (Oleg) I'll try to find out cases where it doesn't rerpo and compare :)

Today:

  • Will handle review comments for the patches that currently in review;
  • Will work on bug 1035471 and bug 1015841.

Day 9: 1st August

Steve

  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Found a bug on v2.0, some master only scripts is added in lazyloader while uplift automatically... Create another patch to fix it.
  • bug 944249 - [Messages] move the segment information request and size check to compose.js
    • Current patch is fine except conflicts, just wondering if we could refine the updateSegmentInfoThrottled timing in the future.
      (Julien) what do you have in mind?
      (Steve) I still prefer that we don't call SegmentInfo api while mms, but it's fine to refine in the future
      (Julien) in MMS mode, maybe we can call it only when we remove characters ? :) (later)
      (Steve) Maybe, we can give it a try but no need to change it for now
  • bug 983172 - Parsing jpeg header information for downsampling the image for thumbnail
    • Ongoing. Using image utils getSzie and resize api in attachment thumbnail generation. But we might still need to keep the logic for resizing for mms image attachment.

Today:

  • will start 983172 for saving more memory in image handling case.
  • Clean up the reset of review.

Julien

  • performance stuff:
    • bug 1043293: make new homescren use "touchend": landed !
    • will ping gabriele again today, to know when he'll be able to profile. We need to know this for next sprint planning.
  • bug 944249: send button and segment info refactoring: in review
    • looked at Steve's suggestion, but it breaks one use case: when we switch to MMS because of a long message, then remove characters to switch back to SMS
  • started a prototype for CMAS:https://github.com/julienw/gaia/compare/cmas-poc
    • wip for now
    • uses attention screen and notification, I want to see what's missing to make it a separate app
    • mail discussion with Michael Henretty about the notification API for some remaining issues
      (Steve) Just raise this issue to system platform part, we will need to consider whether it's necessary to cover callscreen(Both of them are attention screen, so we need to define the new index level for it)
      (Julien) yeah, it's not clear, you're right.
      (Steve) Bruce and Wilfred will discuss this next week(hope they will remember this)
      (Julien) ok !
      (Steve) BTW, it's still possible to de-scope the spec if they really want it in v2.1
      (Julie) you mean, don't do all the spec, but only part of it, as long as the general feature is here?
      (Steve) "Maybe" we will just need to fire a notification and using the system dialog for showing the message like before(call broadcast).

Others:

  • Thread UI redesign: please have a look at the spec in bug 1030925. Can we do this in v2.1? Feedback to Fang? Difficult points? Split in several bugs?
    (Oleg) I'll take a look, but I really want to do thread UI redesign in v2.1 :)
    (Steve) I thought the spec is not 100% confirmed yet? But I think we can provide our suggestion to them if some feature is not easy to implement
    (Oleg) yeah, it's good to spot such issues earlier
    (Julien) I don't really like that we do yet another redesign after the recent one... So, have a look and we can decide what to do next sprint :)
    (Oleg) hopefully we can freeze the latest redesign for several minor versions :)

Today:

  • finish the CMAS POC
  • need to look at the MADAI predefined response bug too.
  • will try to lower my needinfo+review request queue by looking at very old requests

Oleg

  • bug 1044224 - [Messages][Tests] Generate assets on the fly instead of loading it with XHR
    • Fixed review comments and sent for review (in review).
  • bug 1015841 - [Messages][Refresh] Recipients panel visible area handling
    • Prepared patch + wrote unit tests for the affected parts, tested on device and haven't noted any performance issues, but would be nice to have more trained eye to look at this.
      (Julien) If you have a Buri you can look using this
      (Oleg) I tried on Flame with x-heavy load, on Buri with light one, will try on Buri with x-heavy (with HUD reflow-junk enabled, don't see much differences with or without load, but it's the first time I used it :) maybe I'm missing something, visually it works ok).
    • Yesterday Flame build had touch caret enabled and I spotted two issues with it inside SMS:
      • bug 1047241 - [Touch Caret] Touch Caret doesn't follow input if it's focused and moved programmatically. It's when we move recipients panel to show 1.5 lines. Created reduced test case for this that reproduce the issue in nightly.
      • bug 1021499 - [Touch Caret] Touch caret might be truncated by keyboard. Caret is truncated by autosuggestions bar, filed quite a long ago.
    • I don't see touch caret anymore in today build :0, will check once again, maybe it was enabled by mistake or just backouted.
    • Still trying to understand small glitches with recipient panel in Flame, will try to create test case to see if it's Gecko\Flame problem.
  • bug 990021 - [Messages] We should show the correct error message when trying to download a MMS in airplane mode
    • Rebased my old patch on the latest master (was waiting for my errors patch to be landed) and asked for review (in review).
  • bug 1035471 - [B2G][2.0][l10n][SMS] Tamil: "(No Recipient)" string is cut off in the messages list.
    • I can't find build\conditions when this issue isn't reproduced, even on v1.4 if I put Tamil string via App Manager (there is no Tamil lang in v1.4 afaik) I see truncation.
    • It's not blocker nomination anymore. Should we investigate further? I noticed issues with Tamil not only in SMS, in first time screen there are some issues with it too.
      (Julien) if it's not a blocker, I think we can safely ignore unless you really want to fix it :)
      (Oleg) Nope, don't really like such issues :)

Today:

  • Will handle review comments for the patches that currently in review;
  • Will see if I can find cause for issue with Flame and recipient panel that I mentioned above.
  • Will work on either bug 1035471 (Tamil issue) or find something else to work on

Day 10: 4th August

Steve

  • bug 1041967 - [Messages] do some safe lazy load to improve launch latency
    • Conflicts on v2.0 fixed and landed(thanks!)
  • bug 944249 - [Messages] move the segment information request and size check to compose.js
    • Landed on master
  • bug 983172 - Parsing jpeg header information for downsampling the image for thumbnail
    • Create 2 WIP for more feedback, plan A use image utils for size and resizing. Plan B simply use get size and using an approximate size image for thumbnail(with css background-size: cover)
      (Julien) rough intuition: as long as we take care to the ratio, I think background-size will work better. Maybe not for very big images? So maybe we can do both depending on the size of the image?
      (Steve) If we can't fetch the size correctly, maybe we can just ignore the image? If the image is way too big(bigger than sample size can handle)... Not sure if it's possible to make app oom even after downsampling
      (Julien) yep maybe in the SMS/MMS case we don't need to handle this case... :)
  • Some code review for bug 990962 and bug 990021, but all of them looks fine.

Today:

  • Patch for 983172
  • Sniff more bugs.

Julien

  • performance stuff:
    • bug 1043293: make new homescren use "touchend": backed out because of test failures ! Fixed the failures and a try is running right now.
    • Gabriele added some things on the bug, it's not very clear and what I think should be done looks complicated. Happy to get suggestions from you ;)
  • bug 944249: send button and segment info refactoring: landed!
  • my prototype for CMAS is finished for now: https://github.com/julienw/gaia/compare/cmas-poc
    • will produce a video today (both for demo and for UX to have a look)
    • uses the attention screen
  • reviewed bug 1041967 from steve (lazy load) for v2.0
  • reviewed bug 1015841 from Oleg (JS solution to the recipient panel height handling)

Others:

  • worked on a Notification issue affecting SMS: when a notification is still displayed at reboot, the app is launched because of the "show" event: bug 1046828
    • I'll try to do some unit tests for this gecko part, not sure I'll succeed ;) but in the long term this can make a meaningful difference for this API we use a lot

Today:

  • prepare tomorrow's sprint planning, I'll send you the link to the etherpad so that you can have a first look to the bugs
  • do some demos for this sprint
  • need to look at the MADAI predefined response bug

Oleg

  • bug 1044224 - [Messages][Tests] Generate assets on the fly instead of loading it with XHR
    • Rebased on the latest master, there were some conflicts because of the latest refactoring patches (in review).
  • bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
    • Rebased on the latest master, there were some conflicts because of the latest refactoring patches (in review).
  • bug 1015841 - [Messages][Refresh] Recipients panel visible area handling
    • Fixed first review comments and asked for review once again (in review).
  • bug 990021 - [Messages] We should show the correct error message when trying to download a MMS in airplane mode
    • Got r+ (landed).

Other:

  • Looked into thread view and composer redesign, doesn't look difficult, I have only two concerns:
    • We need to change subject styling once again, so as per latest spec it will lead to markup change that may be not so easy;
    • Per latest spec box-shadow is going to be used for the messages in the thread, so not much value but probably performance impact.
      (Julien) we can raise the concern to Fang. For shadow maybe we can use a repeating image instead, as it looks to be always the same ?
      (Oleg) Sure, will ask Fang, but is it just assumption or we have real measurements, I had problems with it in the past, not sure how it's fast today. Btw, do we have some sort of "progressive enhancement"? Like disabling border-shadow for low memory devices.. or smth.
      (Julien) not that I know. The issue is not for low memory btw, it's more about CPU.
      (Oleg) Sorry, yes I mean low-end devices
      (Julien) one of the possible culprit for the v2.0 launch issue is the shadow we have on the contact picture (but it's also with border-radius, so it's more difficult to paint...). In the end, what I mean is that the shadow should not bring too much performance issues, because we can just use an image instead if necessary. But use an image only if needed.
      (Oleg) Ok, I'll try to measure message elements with it and without it for big thread.
      (Julien) do it only when you'll start implementing ;)
      (Steve) One thing comes to my mind: We used to have a concern in the spinning cursor, do we need to remove it in the new conversation
      (Oleg) If you mean "sending" indicator? Then it's removed with 'Sending...' text
      (Steve) Oh, she did it :p I just suggested her that we can remove it last week
      (Oleg) :) I like it more than spinner

Today:

  • Will handle review comments for the patches that currently in review;
  • Will see what blockers/nominations/most-wanted/papercuts we have to pick up next issue.

Demos

bug 1041967: [Messages] do some safe lazy load to improve launch latency.

Side by side comparison video

  • Cold launch time on datazilla

bug 1026685: CMAS proof of concept using an external application

see the bug's attachment for a video of the POC.

bug 990021: We should show the correct error message when trying to download a MMS in airplane mode.

  • Before

  • After

bug 1026694: Access to attach button.

  • Before

  • After

bug 1015841: Recipients panel visible area handling.

  • Before

  • After

  • Before

  • After

Retrospective

Previous sprints' actions

  • invite all people that work on SMS to daily meetings (this time, we were missing Pavel, Marina)
  • better identify that bugs will target the same area (eg: composer bugs); ideally we need to span them on several sprints, so we need to identify well in advance
  • Try harder to take only actionable and clear bugs
  • define what the scrummaster role is/should be (not for this sprint though)
    (Julien) started something at https://etherpad.mozilla.org/sms-scrummaster, we can discuss this later
  • estimate quality metrics only once every 3 sprints.
  • bugs that we take out of the sprint use [sms-sprnt-<number>] in their whiteboard.
    (Julien) did it work well? I think it did!

What was good in the last sprint

  • Even we got 1.3t/2.0 blockers, we still manage to complete whole promised tasks(almost, except the missing visual spec)
  • we finished the sprint ! (except for the not-ready bug)
  • I (Julien) did things out of the SMS app, good to change context, maybe not good for comms ;)
    (Oleg) +1 for changing contexts, trying to always have some not-so-hard side bug to switch mind.

What was bad in the last sprint

  • Unfortunate coincidence for the sprint: hard 2.0 performance blocker, flex-box regressions, no UX spec for one sprint bug, just p=1 though.
  • the burndown chart looks weird
    (Julien) reason is easy: we don't subdivise big bugs into smaller tasks. I think we should do it (not smaller bugs, just smaller informal tasks inside the bug (ex: change event in Compose, use event in ThreadUI, update unit tests, etc)) so that we can both make estimates better and see burndown chart go down. What do you think?
    (Oleg) Do you mean just mention this informal tasks in bugzilla comment and then update it (to make easier to build burndown chart)?
    (Julien) yep; maybe we can edit user story to do this? "Technical" way to do it is not so clear, but we should do it.
    (Steve) I think using meta bug is enough for big issue? Using user story might get confused, but for the compose refactoring issue, I think we can do better to split into smaller tasks to implement it step by step
    (Julien) look at https://bugzilla.mozilla.org/show_bug.cgi?id=944249 and similar bugs: they're really big, and yet it's difficult to subdivise in small bugs (because it makes no sense to have separate patches).
    (Julien) smaller tasks, yes, that's what I propose :) but smaller bugs ? do you think the bugs would be meaningful by themselves?
    (Steve) Hmm... maybe you are right, abusing the bug seems not a good way either, but having a multiple patches for one referenced bug... Might be some problem for uplifting?
    (Julien) to make better estimates, we just need to have the tasks in the planning etherpad. But for burndown we need to have them elsewhere.
    (Oleg) The only problem I see here, is that I can reduce point value for my subtask only if it passed review, so can we develop-and-review on subtask basis? Otherwise burdown chart can go up and down :)
    (Julien) subtasks should be before review; it's more the steps to do the final patch. "review + review follow-ups" can be one or 2 subtasks by itself. But we can say "bug completion: 2 / 5" if p=5 and we did the subtasks for 2 points. Also, we'd estimate the substasks and not the bug.
    (Julien) if you want, we can do the first part today: only subdivise in tasks during planning, but not using it for burndown (and so not putting it in bugs at all yet)?
    (Oleg) I think it would be better to try to split first, agree.
    (Steve) We could try it +1
    (Julien) ok, let's do this as first step, to get used to subtasking :)
  • performance issue: we don't really know how to move forward
    (Julien) what can we do about this? Be better at profiling? ;)
    (Steve) Better understanding about the profiling result :p
    (Oleg) Btw, did reporters tried the latest build with lazy loading, are they satisfied?
    (Steve) Not sure... But with touchend/lazyloader patch, I think it's quite close(launch time)
    (Julien) I still see a big difference with 1.3 when rendering threads. The _start_ of the rendering is similar to v1.3 thugh.
    (Steve) Some styling like shadow and border radius might affect rendering
    (Julien) in my personal test, I don't have any contact picture (or at least only 2 or 3), and it seems I see differences.
    (Steve) You mean even we don't render any contact photo, the rendering still slower?
    (Julien) yes, at least, it seems. I think that the first panel rendering is also slow because that we open 4 different DBs instead of 2... I completely removed the Facebook request in contacts.js and it was really faster :) So maybe there is something to look there. But its difficult to see in profiling.
    (Steve) Yes... I have no idea how to proof the performance regression by facebook request, even we know removing it could perform better.
    (Julien) I don't even have facebook enabled ;)
    (Julien) OK, let's move forward, we'll discuss about this again in planning.

Any questions

  • Efforts for new visual refresh? It seems our visual/UX would prefer to refresh them all again
    (Julien) for v2.1 (since we're already at second sprint) I think we can try to do things that don't change the markup? I discussed with Wilfred about this, but didn't have the time to finish what we discussed. His reasoning is that Haida is more important than refresh, but if we can't finish haida, then we must do some refresh. (I'm not sure I agree, but he's owner :) ). Still the refresh is not committed by itself, so we can take it lightly, except the commited things like "highlight actionable items"
    (Julien) I'd really like that we move forward with the IndexedDB in SMS app, because there are a lot of things we can't do because of this, so if some refresh can't be done because of this, I'm fine. But then we need to divide the refresh work, and it's maybe more work than just doing it?
    (Julien) thoughts?
    (Steve) Not sure about the IndexedDB in message spp, you mean creating threads DB by ourself (with datastore changes?)
    (Steve) Personally I would not prefer doing huge refresh in close release. But dividing the request and prioritize them is reasonable for me.
    (Julien) first step (IMO) is to have a DB without datastores :)
    (Oleg) Just to understand, what we can do with IDB if we have it? Store drafts or ..?
    (Julien) store things without going to gecko: contact information, thumbnails (eg for video), MMS data without decoding SMIL each time, keep error reasons; can help not having all threads/all messages always in the DOM
    (Julien) ok, let's divide the refresh during planning.

Actions for next sprint

  • subdivise bigger bugs in subtasks for planning only
  • divide the refresh in smaller prioritizable tasks
Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/SMS/Scrum/2.1S1&oldid=1002680"