Gaia/SMS/Scrum/4

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

Contents

List of bugs

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

Bugzilla link

Full Query
ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
990537 Julien Wajsberg [:julienw] [DSDS] Messaging. Apply Visual Refresh to DSDS scenarios. --- No cf_feature-b2g [p=2] FIXED
1021513 Steve Chung [:steveck] [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode 2.0+ No cf_feature-b2g [p=1] FIXED
1022644 Steve Chung [:steveck] [Messages] Can't open the recipient panel if there are only 2 lines of recipients 1.3T+ No cf_feature-b2g [p=2] FIXED
1025552 Oleg Zasypkin [:azasypkin] [Messages][Refactoring] Refactor attachment.js and specifically move rendering part to a separate module --- No cf_feature-b2g [p=1] FIXED
1026575 Oleg Zasypkin [:azasypkin] [B2G][SMS] Message preview in Messages app thread view disappears after opening app 2.0+ No cf_feature-b2g [2.0-daily-testing][p=2] FIXED
1033260 Julien Wajsberg [:julienw] [Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only) --- No cf_feature-b2g [p=1] FIXED
1033403 Julien Wajsberg [:julienw] [Messages] We don't stop rendering if we tap "back" too soon --- No cf_feature-b2g [p=1] FIXED

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


Remaining points and burndown chart

google chart api url for Sprint 4

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


SMS issues handled by the SMS subteam outside of the sprint (blocks the sprint bug 1028276 with whiteboard "not-part-of-initial-sprint")

Full Query
ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
1008127 Pavel Ivanov [:ivanovpavel][:pivanov] UX [Messages][Refresh] Subject handling in the Composer --- No cf_feature-b2g [sprint2 p=3][sprint3 p=2][not-part-of-initial-sprint] FIXED
1008912 Oleg Zasypkin [:azasypkin] 'MMS' in sms app doesn't translate into other language --- No cf_feature-b2g [sprd309681][not-part-of-initial-sprint] FIXED
1013296 Arnau March [:arnau] ( not working in Firefox OS anymore :( ) Compose. Change send button to an paper plane icon --- No cf_feature-b2g [p=1][not-part-of-initial-sprint] FIXED
1022755 Julien Wajsberg [:julienw] Possible race in the SMS navigation code 2.0+ No cf_feature-b2g [p=3][not-part-of-initial-sprint] FIXED
1030160 Steve Chung [:steveck] [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines 2.0+ No cf_feature-b2g [not-part-of-initial-sprint] FIXED
1034637 Oleg Zasypkin [:azasypkin] [Messages] Utils.js unit tests are failing when run locally --- No cf_feature-b2g [not-part-of-initial-sprint] 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
990537 Julien Wajsberg [:julienw] [DSDS] Messaging. Apply Visual Refresh to DSDS scenarios. --- 2.0 FIXED
1008127 Pavel Ivanov [:ivanovpavel][:pivanov] UX [Messages][Refresh] Subject handling in the Composer --- --- FIXED
1008912 Oleg Zasypkin [:azasypkin] 'MMS' in sms app doesn't translate into other language --- --- FIXED
1013296 Arnau March [:arnau] ( not working in Firefox OS anymore :( ) Compose. Change send button to an paper plane icon --- --- FIXED
1021513 Steve Chung [:steveck] [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode 2.0+ --- FIXED
1022644 Steve Chung [:steveck] [Messages] Can't open the recipient panel if there are only 2 lines of recipients 1.3T+ --- FIXED
1022755 Julien Wajsberg [:julienw] Possible race in the SMS navigation code 2.0+ --- FIXED
1025552 Oleg Zasypkin [:azasypkin] [Messages][Refactoring] Refactor attachment.js and specifically move rendering part to a separate module --- --- FIXED
1026575 Oleg Zasypkin [:azasypkin] [B2G][SMS] Message preview in Messages app thread view disappears after opening app 2.0+ --- FIXED
1030160 Steve Chung [:steveck] [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines 2.0+ --- FIXED

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


Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 25th June

Steve

  • bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
    • Partner reported that the issue still exist, but I could not reproduce it...
  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • Feedback+, still working on the test
  • bug reviewing:
    • bug 925404 - [B2G] [SMS] Always include the phone number in the SMS Thread UI, even if the carrier is known: r=me
    • bug 1025552 - Refactoring for attachment rendering: No serious issue discovered right now, maybe we can land for this sprint.
    • bug 974867 - [MMS]Auto suggestion for email address: Some suggestion gave, the test still failed.
    • bug 959201 - [Messages][Drafts] Wrong Cursor position in the message compose of a Draft: Some feedback given and r+

Today:

  • Try to clean(or reduce) the review queue
  • Update patch in bug 1022644

Oleg

  • bug 008127 - [Messages][Refresh] Subject handling in the Composer
    • We finally have patch that works, and don't see any issues! It requires JS changes, but it's much less risky now. So I prefer to go with it instead of changing layout and fixing regressions later on. Tightly collaborated with Pavel yesterday, it speeds up the process a lot. Some cleanup is left from both CSS and JS sides, once we finish, Pavel will ask for review from Steve (in progress, almost done).
  • bug 1025552 - [Messages][Refactoring] Refactor attachment.js and specifically move rendering part to a separate module
    • Rebased on the latest master (in review).
  • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
    • Tried to reproduce it many times, with Buri and Flame, using git revisions mentioned in the bug and master, but without luck. Noticed that in video attached to the bug, timestamps for the thread and the single message in it are different that made me think that thread was manipulated somehow, but QA didn't confirm that. The only a bit similar case that I found is when we have "empty" draft for the thread (just a space or new line in message input an save it as a draft), but it's still not the same issue.

-> Steve, do you have any ideas? I'm using PVT builds, but QA mentioned some tinderbox builds, I don't really know much about it, found only something similar (https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/). Can "tinderbox vs nightly pvt" builds be the reason why I can't repro this? -> Based on QA's description, tinderbox build will produce more frequently (4 times a day or more) for finding the regression window with less effort. But basically the code base is the same. The only possibility might be the some changes that need patches from both gaia and gecko, but tinderbox build created with one side is not ready yet. But if it's still reproducible on the latest build, maybe we could ask them to try in on PVT build? -> Yeah, probably it's the only thing I can do :) Thanks! Will ask Jayme to check that with PVT. And will try to manually flash with tinderbox build they mentioned.

  • bug 1013296 - Compose. Change send button to an paper plane icon
    • Went through the bug and haven't noticed why it can depend on subject handling patch, we may touch the same stuff in CSS, but it isn't really a dependency. Asked Arnau to proceed with this patch.

Other:

    • Added demos to the Sprint 3 Demo page for the carrier header patch + closed related "bug 883911 - [SMS][MMS] Update all occurrences of "Type ? Carrier ? Number" strings to same format" as it's covered by the carrier header patch.

Today: handle review comments for attachment refactoring patch, will polish JS part for the subject handling patch.

Day 3: 26th June

Steve

-> Phew :) I thought I the only one with this strange issue and STR :) I can not reproduce it if music is always on. -> Yep, initially I thought that it caused by RemoteControls.play (when I press Play\Pause in the notification panel) which calls getSelf and due to the bug in it, onsuccess isn't fired for the rest of calls (that made from our App). But wasn't able to confirm that :( Seems I'm wrong. -> Also I can't reproduce it when I resume the song, but it ends soon and always reproduce when I have song playing at the beginning :) Mess :( -> Have you tried that only make the music app from background to foreground and not playing the song? -> Not yet, maybe I could try this one myself to clarify. -> I also will try simpler and more stable STR, but I'm "glad" that it doesn't work for SMS as it simpler and faster to test. Do you have any tips on how to use logcat more efficiently? I only use it as "adb logcat | grep Gecko"I also use grep for filter... :p Maybe you could try DDMS -> Oh, never heard about that (but just googled :) ), will check it out, thanks!It's Android Developers tool kit that have graphic UI and you could treat the logcat more convenient. -> Nice! Also forgot to mention (that happened to me only once though) that after a long testing with lots of missed notifications, even after rebooting and without Music I stopped to receive any notifications for the messages coming to "target" thread.

  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • Test added and request review
  • bug reviewing:
    • bug 1025552 - Refactoring for attachment rendering: Landed
    • bug 974867 - [MMS]Auto suggestion for email address: Partner request another review.
    • bug 1013296 - Compose. Change send button to an paper plane icon: Arnau update the patch again that might has less side effect on DSDS device. Reviewing and testing.
    • bug 959201 - [Messages][Drafts] Wrong Cursor position in the message compose of a Draft: Landed
    • bug 963043 - [MADAI][Dialer] Select phone number from Call log as Recipients from SMS App. Feedback given but they have to fix conflicts first.

Today:

  • Try to clean(or reduce) the review queue
  • Update patch in bug 1022644

Oleg

  • bug 1008127 - [Messages][Refresh] Subject handling in the Composer
    • Polished my JS part, so it's ready. Today will merge it with the latest patch from Pavel to test merged patch on device (in progress, almost done).
  • bug 1025552 - [Messages][Refactoring] Refactor attachment.js and specifically move rendering part to a separate module
    • Fixed last review comments and landed (landed).
  • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
    • After discussion with Jayme on IRC we found out correct STR for the issue, so that I can now reproduce it: user just need to open composer, send message to create new thread, once user is automatically navigated to the newly created thread, SMS app should be closed with the card view (app manager? not sure what is the common name for it). In this case onVisibilityChange is triggered and empty draft is saved (due to bug in onVisibilityChange). Then when user opens app he sees how message preview is quickly replaced with the empty draft :) I have PR for this, attaching it to the bug at the moment.
  • bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
    • While working on subject handling patch we've noticed that issue. I don't see easy and safe solution for it, so we have small workaround in the subject handling patch for this case.
  • bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
    • Spend some time trying to reproduce this issue. Finally was able to reproduce with SMS (MMS's are quickly eating mozilla's prepaid plan :))lol. Yeah, real life :) I've described what I saw in my comment to the bug, but didn't have time to systematize it to understand the reason

Other: Today: will review patch from Steve related to recipient panel with 2 lines, send patch for bug 1026575 for review and handle review comments + send subject handling patch for review if don't notice any serious issues while testing on device. Will try to find the root cause for Tarako issue with missed notification.

Day 4: 27th June

Steve

  • bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
    • Will verify with latest build with gecko patch bug 1026737 landed
  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • r+, will land to master and v1.3t
  • bug 1021513 - [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode
    • Will create patch today. Just set the transitionend event listener on the correct element will fix this issue.
  • bug reviewing:
    • bug 974867 - [MMS]Auto suggestion for email address: Still have a small issue for the multi-resolution icon.
    • bug 1013296 - Compose. Change send button to an paper plane icon: Arnau update the patch again that might has less side effect on DSDS device. no update today.
    • bug 959011- [MADAI][Dialer] Sending pre-defined message during call reject - Explain the idea from julien and Anthony to partner about the quickReply module and separate html entry.

Today:

Oleg

  • bug 1008127 - [Messages][Refresh] Subject handling in the Composer
    • Tested on device, looks good to me (in review).
  • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
    • Prepared simple patch that doesn't respect Thread.recipients.length when auto-saving draft in the Thread panel and sent for review (in review).
  • bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground

-> Did you try to apply it? You mean the gecko patch? No, I mean call getSelf before our own getSelf (without gecko patch)?No I haven't, and it looks weird to do so :p Yes! :) I know it won't work without gecko patch, I saw it while testing previously, when dispatchNotification is called several times in a row (all previously missed notifications)

  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • Reviewed, looks good, r+'d.

Today: will handle review comments for patches in review + going to look into next blocker we have "bug 1022755 - Possible race in the SMS navigation code"

Day 5: 30th June

Steve

  • bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
    • Will verify with latest build with gecko patch bug 1026737 landed(didn't have time to do it last week...)
  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • r+, but v1.3t need another implementation. So I'll commit another patch for 1.3t.
  • bug 1021513 - [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode
    • Landed on master
  • bug reviewing:
    • bug 974867 - [MMS]Auto suggestion for email address: Conflicts fixed and need another review.
    • bug 1013296 - Compose. Change send button to an paper plane icon: Landed.
    • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app: Some suggestion given, but the patch looks fine
    • bug 1008127 - [Messages][Refresh] Subject handling in the Composer: Some feedback given, patch works great but it need to fix the conflicts.

Today:

  • Try to clean(or reduce) the review queue. Hope I could have some time for partner's patch...
  • Create v1.3t patch for bug 1022644

Julien

Today: Reading up all my mails, and trying to keep up with what happened during my break :)

Oleg

  • bug 1008127 - [Messages][Refresh] Subject handling in the Composer
    • Updated JS part according to review comments (retrieving subject input line height with "getComputedStyle"). Asked Pavel to update his PR with my latest changes (in review).
  • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
    • Updated patch according to review comments (cleaning up ThreadUI.recipients in "afterLeave" if next view isn't Composer + unit test) (in review).
  • bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
    • Cleaned up ni?=me as it's waiting for verification from Spreadtrum QAs. Will look once again if they still have this issue (awaiting QA verification).
  • bug 1021513 - [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode
    • Reviewed, looks good, r+'d (landed).
  • bug 1022755 - Possible race in the SMS navigation code
    • Still looking into this (can be reproduced without reference workload, I can reproduce it with thread with two MMS if quickly press Back button). Navigation.slide code looks fine to me except of memory leak as we've never unsusbscribed from "transitionend" (tried to unsubscribed on the wrong element), so number of listeners is growing proportionally to number of navigation between panels (in progress).

Other:

    • We have two new 2.0 blockers: bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines (awating decision from UX) and bug 1022575 - Received SMS store (without text) on check balance.

Today: will handle review comments for patches in review + investigate bug 1022755

    • (Julien) you need a gecko patch before bug 1022755
    • (Oleg) What Gecko patch?
    • (Julien) sorry, mixed with bug 1022575 (same digits, different positions ;p)

Day 6: 1st July

Steve

  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • r+, Land on master and v1.3t. may need uplift to v1.4 manually
      (Julien) don't forget to ask approval, I NI you :)
  • bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
    • Discuss the possible solution with UX
      (Oleg)-> Did you agree on any particular solution? I liked your proposition to disable Enter at all (if I got it correctly) :)
      (Steve) yes, she understood what you said and she will reply on the bugzilla. Disabling all the enter might be the answer
      (Julien) I'd say that if we don't want to allow new lines, "enter" should move to the next input...
      (Steve) well, she did concerned about that (having a button without any function), so switch to message input is still a candidate
      (Julien) ok. But should all this be done in this 2.0+ bug or in a separate bug? Since we want to keep blockers as low as possible, I'd really like that we only get the 1.4 behavior (that we don't need endless discussions to know) and do better things for v2.1 in a separate bug.
      (Oleg) Didn't dig into the code deeply yet, but changing to previous behaviour maybe more risky :)
      (Steve) Since we did a lot of changes for 2.0, I prefer Oleg's thought
      (Julien) my only concern is that it will take more days to know the perfect UX and it's not urgent to have the perfect UX while it's urgent to fix blockers.
      (Steve) I can trace back the behavior in v1.4 and see if it's reasonable to follow the same behavior
      (Julien) ok thanks !
  • bug reviewing:
    • bug 974867 - [MMS]Auto suggestion for email address: Review+, waiting for their commit refined
    • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app: r+ and landed
    • bug 1008127 - [Messages][Refresh] Subject handling in the Composer: r+ and landed

Today:

  • One review request from partner.
  • Fix blocker(bug 1030160) and triaging other message bugs.

Julien

  • Read my mails, did some triage

Others: worked with jgriffin about the changes we need to make to TBPL for bug 874510 (upgrade mocha) Today: will do reviews for partners (MMS by email) and start the DSDS refresh (bug 990537).

Oleg

  • bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
    • Landed.
  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • Reviewed v1.3t patch (landed).
  • bug 1022755 - Possible race in the SMS navigation code
    • Found out that Navigation patch didn't regress it, we had this behaviour a while ago (I was able to reproduce it even on v1.4). Navigation patch just made the problem more noticeable (back button doesn't work and content is cleared). The problem I see is that everything is done correctly in JS to navigate to a new panel (at least I've not found a reason yet), but visual transition between panels (I don't mean CSS Transition itself, it can be reproduced even without it) is stuck in the middle (or even in the beginning). "data-position" on wrapper element is correct, but panel that is currently visible is not (if in App Manager you turn off "position:absolute" first for".panel" class and turn on then - everything will become as it should). The problem seems to occur when the time gap between changed data-position class(applied to the wrapper) and appending something to the DOM (like adding new message date group element) is really small. Just an experiment, I made ".messages-date-group" as "inline" element and I can't reproduce issue anymore, if I make it "block" again the issue is reproduced. Can it be related to some kind of interrupted reflow, I don't really know :) ? I need your advise here guys, do you have any ideas?
      (Julien) so it's the same than https://bugzilla.mozilla.org/show_bug.cgi?id=912012 ?
      (Oleg) Sounds similar, but not sure, as navigation events are in the right order, yes we need to somehow stop rendering, requesting and etc. Like Promise.abort() for async operations.
      (Julien) one idea: is do we still use hashes? Maybe because of hashes the "browser" tries to show the element with that id ?
      (Oleg) mm, why then it works if I switch between block<->inline? I'll check your idea with hashes, btw. Thanks!
      (Julien) I don't know for the switch block/inline :) I can also investigate on the issue if you're blocked, just ping me later today if necessary.
      (Oleg) Yep, thanks, if I feel that can't think of any other ideas, I'll ask for your help :) Thanks!
      (Steve) Would that help if we ignore any pointer events while page transition?
      (Julien) could be a good idea, but I'd still like to know the root cause
      (Oleg) But seems that navigation\slide is performed consequently, and not in the middle of each other, and problem still occurs. We also loading message thread asynchronously, when navigation is actually ended we're still appending something to the dom. I'll investigate further and give you more food for thoughts :)

Today: work on bug 1022755 (race condition while navigating from one panel to another) + pick up some smaller bug just to switch my mind (like localizing MMS label) :)

Day 7: 2nd July

Steve

  • bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
    • 1.4 and 2.0 uplift request approved
  • bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
    • Made a PR for ignoring all the return key
      (Oleg) will you remove CSS hack that we made for subject handling?
      (Steve) I think pavel remove them in the latest subject patch, but I'll f? you to confirm it again, thanks.
      (Oleg) Ok, I'll check
  • bug 1027593 - [SMS] Error displaying long messages
    • Start to investigate it today
      (Julien) Note Oleg's investigation below too
      (Steve) Thanks for reminder! Just saw the assignee still empty
      (Oleg) Oh, sorry, anyway will talk to Doug and post result to the bug
  • bug reviewing:
    • bug 990537 - [DSDS] Messaging. Apply Visual Refresh to DSDS scenarios: Feedback given but it looks fine overall.

Today:

  • Found a bug in subject field: When we are in the middle of the recipient with some suggestion contacts below, clicking the option menu for adding the subject will not wrap the recipient and clear the suggestion list.
    (Julien) File a bug already ? :)
    (Steve) Still editing! It might need to nominate for 1.3t since all the version could reproduce it...
    (Julien) If there is a workaround (clicking elsewhere would then do the right thing) I think it's enough to ask for a blocker on 2.0.
  • Fix blocker(bug 1027593) and triaging other message bugs.

Julien

  • mainly worked on the DSDS refresh bug 990537
    • waiting for ui-review

Today: will do follow-ups for that bug and reviews for blockers and partners. Will also address needinfo, especially the one for the navigation issue.

Oleg

  • bug 1022755 - Possible race in the SMS navigation code
    • There are not much updates on this, I've posted all investigation results I have to the bug comment and asked Julien for the help with it (in progress).
    • Also noticed that if we press Back to quickly when we entered message draft, this draft disappears from the thread list. Looks like another problem but with similar steps.
  • bug 1008912 - 'MMS' in sms app doesn't translate into other language
    • Prepared patch that uses localized "MMS" label in message composer and thread list panels. Send for review (in review).
  • bug 1027593 - [SMS] Error displaying long messages
    • Spend some time trying to reproduce it on my Flame to check whether subject handling patch improved\fixed anything related. With subject handling patch I see this error (I'm in doubt if it the same as described in bug) - http://mzl.la/1m7MWEm . Before this patch I can reproduce behaviour from bug description, but if I look closer - it has the same effect, but it's not so noticeable http://mzl.la/1sWoCL6 (look below).
      (Julien) from the screenshot, it looks like a platform issue; like they don't know we scroll and then they render incorrectly
      (Oleg) yes, I'm in doubt that we can break things in this way
      (Julien) maybe needinfo :milan on the bug; or :kats. Or ask advice from Doug because he used to work in this area.
      (Oleg) Ok will talk to Doug first and ask :kats\:milan in case Doug doesn't have ideas.
      (Steve)I also think it should be platform issue, not sure why it's related to bug 1015867

Today: will investigate bug 1027593 (error displaying long messages) and try to return to bug 1022755 (race condition while navigating from one panel to another)

Day 8: 3rd July

Steve

  • bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
    • Update PR (unit test part) and reply some thought. The behavior seems not easy to satisfy everyone :p
      (Julien) That's why I wanted tthe v1.4 behavior so that we don't need to discuss ;) But we'll find something that works fine, I'm not worried.
  • bug 1029230 - [B2G][Messaging]Horizontal line dividing message thread and compose text area does not account for auto-suggest bar: After some investigation, this issue should belongs to graphics issue(And the line should belong to keyboard app).
  • bug reviewing:
    • bug 990537 - [DSDS] Messaging. Apply Visual Refresh to DSDS scenarios: Feedback given but it looks fine overall.
    • bug 1033260 - [Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only)
      • I still nominate for v1.3t since the remaining contact will not dismiss even focus on message input. Working on it.

Today:

  • Found another bug in subject field...: When suggestion string select and input in subject, it might exceed the max length limitation because the suggestion string didn't go through the key down/up checking.
  • Fix blockers and triaging other message bugs.

Julien

  • worked on the DSDS refresh bug 990537
    • r+ by steve, waiting for review from Anthony
    • found an issue for accessibility (bug 1033692) about how the indicators are made. height:0 and font-size:0 should be used when we want the screen-reader to read the text, but we don't want that the other users see the text. Here, for "MMS", we want that nobody can see it when it's not a MMS... And same for the counter indicator that is not "visible" by the screen reader (but it was like this before too)
  • bug 1022755: the race condition in the navigation code; it was really a race condition in the ThreadUI code, but I also made a change to the navigation code. Basically, while we slide, we should be in no panel (so isCurrentPanel returns false).
    • found another issue where we don't stop rendering if we press the back button too quick (bug 1033403); I have a working patch without tests, I'll try to finish this today.
  • Other:
    • answered Doug about how we do Scrum, along with some thoughts.
    • filed issues for intermittent on Travis (mostly integration tests, maybe it's a good thing we don't do any in SMS...)
    • helepd the sheriffs to find the source of a problem (related to a change made for bug 874510 about upgrading mocha). Turns out we forgot to uplift a test fix in v1.4 (and Travis was not using it).

Today: I want to do mostly reviews today, as the reviews for partner wait for some days now :( Will also try to finish bug 1033403

    • (Steve) How about bug 974867 - [MMS]Auto suggestion for email address ? Should we wait for them to fix the commit log? (Or should we land it by ourself)
      (Julien) You can fix it yourself and land, I think :)
      (Steve) ok ... I think we waste many time on such details
      (Julien) you mean, if you do it yourself, or if we ask them to do it and wait?
      (Steve) -> ask them to do it and wait
      (Julien) Yeah, I agree. This whole bug was a complete waste of time, but I hope that it will be easier for next bugs then (hopefully the same developer will work on it). Otherwise it's just easier to do it ourselves...

Oleg

  • bug 1022755 - Possible race in the SMS navigation code
    • Tested Julien's patch on device, the latest one works great, doing code review at the moment (in review).
  • bug 1008912 - 'MMS' in sms app doesn't translate into other language
    • Landed.
  • bug 1027593 - [SMS] Error displaying long messages
    • Discussed it with Doug, found easy STR and filed a bug to Core ("bug 1033383 - Text that is being typed inside scrollable contenteditable container is blurred"). It's likely a dupe of the "bug 1027851 - [B2G][E-mail]When composing an email, everything typed after pressing the spacebar when typing in a recipient's email address is blurry", but it's not clear yet as per Doug any tiny detail can lead to different bugs in painting even if it looks similar.
      (Julien) does that reproduce for you on Buri? I couldn't reproduce myself... Maybe it's only in HD phones?
      (Oleg) Nope, haven't tried, but will try as our bug is reproduced on Buri as per QA, so to be sure that we're fixing the right one.
      (Julien) Thanks, maybe it's me ;)
      (Steve) Is that reproducible when APZ off?
      (Oleg) If I remember correctly, yes, I've tried with APZ turned off, but no any difference, Doug mentioned the feature they implemented few weeks ago that may influence that - "(Doug): it looks like the bottom section is not being signaled to paint. we paint a small region outside the regular displayport in low-res starting a few weeks ago"
      (Steve) Ok thanks for sharing

Today: will finish review of navigation race patch and pick up next blocker.

Day 9: 4th July

Steve

  • bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
    • Tried to add the space to the end manually, but it didn't work as I expected... will update to the bugzilla
      (Julien) ok, then I guess we'll move forward with your current solution
  • bug 1033260 - [Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only)
    • Fire patches for v1.3t and master separately.
  • bug reviewing:
    • bug 990537 - [DSDS] Messaging. Apply Visual Refresh to DSDS scenarios: Feedback given but it looks fine overall.
    • bug 974867 - [MMS]Auto suggestion for email address: Refine the log and land to master

Today:

  • Found another bug in subject field...: When suggestion string select and input in subject, it might exceed the max length limitation because the suggestion string didn't go through the key down/up checking. I didn't create it yet... wondering if we need to fix it.
  • Next week I'll be called up for military service for one week(7/5 ~ 7/11)

Julien

  • worked on the DSDS refresh bug 990537
    • r+ and landed on master
    • needs an altenative for v2.0 due to the string change... I asked accessibility team if removing the aria-label is good enough from v2.0.
  • bug 1022755: we should not try to scroll if we're not in the 'thread' panel
    • final patch waiting for travis
    • also fixed the bad removeEventListener call, and added lots of tests for renderMessages (which were missing for a long time)
  • bug 1033403: if we press "back" quickly, we still render messages
    • finishing tests right now, will ask review in a few minutes
    • the issue was that we reset the "stopRendering" flag too late (in afterEnter) so if we press "back" between beforeEnter and afterEnter (which sets "stopRendering" to true), stopRendering was reset to false before it was checked. Now we don't even call getMessages if stopRendering is "true" when we call renderMessages.
  • bug 1032061: tried to trigger an error while autodownloading a MMS to see if we have a correct notice. But I couldn't send a MMS at all yesterday for some reason...
    • Could one of you try to do this? (my idea was to enable "airplane mode" when I see a network activity)
      (Oleg) will try
      (Steve) +1

Today: will try hard to not work on any new patch and do only needinfo and reviews. I also want to move forward with some changes for Travis, but this will maybe wait for monday.

Oleg

  • bug 1022755 - Possible race in the SMS navigation code
    • Reviewed (waiting for check-in).
  • bug 1027593 - [SMS] Error displaying long messages
    • Made sure that it's reproduced on Buri in the same way. Yes, it's :) It just needs more lines of text.
    • There is also a good progress on dependencies, almost all of it landed on mozilla central.
  • bug 1024835 - [MMS] Receiver receive a garbage message when receiving a MMS if turn off auto retrieve mode
    • Tried to reproduce, but couldn't. As Julien mentioned it can be reproduced only with some operators.
  • bug 990020 - [B2G][SMS] A MMS that has not been downloaded yet will display a "Missing SIM card" message after changing the SIM to a different valid one
    • Have small patch for this with dummy strings. Whom can I ask about the right strings? :)
      (Julien) you can come up with a somewhat working string, and then ask :matej for a better string, with some context so that he can understand.
      (Oleg) Ok, thanks. I'm also wondering whether it should be something generic, will "SimNotMached" error be thrown for other cases too, do you know something on that?
  • bug 985273 - [DSDS] SIM labels of missed calls & sms in Notification is different
    • Going to fix that, looking into places where we use SIM indicators strings

Today: will work on bug 990020 and bug 985273.

Day 10: 7th July

Steve

  • absent for military service for one week(7/5 ~ 7/11)

Julien

  • worked on the DSDS refresh bug 990537
    • ready to be uplifted to 2.0, approval+
    • the trick was to move the string change to another file that localizers don't see. It's posible because the string is actually not localizable (it's only the sim name)
  • bug 1022755: we should not try to scroll if we're not in the 'thread' panel
    • landed
  • bug 1033403: if we press "back" quickly, we still render messages
    • proposed a patch
    • now we set the "boolean" responsible for stopping the rendering in "beforeEnter" instead of "afterEnter". Also, if this boolean is already true, we don't even request the messages, which saves some DB and IPC (and we know DB and IPC are in the main thread, so yay).
  • reviewed lots of madai bugs
    • one of them was obviously not working (some functions were just not called...) so I wrote a quite upset message
    • I have some more today
    • especially, one might need help from our side (we need to switch to MMS when adding an email recipient, and the current architecture is really bad for this), so I may start working on bug 944249
  • Other:

Today: more reviews from madai and Oleg, I'd also like to move forward with the "upgrading mocha" patch, probably my "subway work" ;) \0/

Oleg

  • bug 1027593 - [SMS] Error displaying long messages
    • Looks like all dependencies are resolved, but I was able to reproduce the same blurry issue in SMS app (it difficult to do now, but still) on today's build. Will check whether I have correct Gecko revision that includes all required patches and try once again.
      (Julien) :'( I really hope you don't have the correct patches ;)
      (Oleg): I hope too :) But I can't repro issues that was described in my simple STR (with content editable), so I'll double check.
      (Julien) ok, so maybe there is another bug, yay
  • bug 990020 - [B2G][SMS] A MMS that has not been downloaded yet will display a "Missing SIM card" message after changing the SIM to a different valid one
    • Prepared patch with two commits (1st for the fix, 2nd with small refactoring of error codes) (in review).
  • bug 985273 - [DSDS] SIM labels of missed calls & sms in Notification is different
    • Prepared small patch and sent it for review (in review). We'll still need to handle translation of this label (well, not only this) after language switch. Not sure whether we can easily update notification with the right translation on the lang switch.
      (Julien) yeah, that's a known limitation of the API, I don't think we can do anything. Might be a good idea to raise the issue in the dev-webapi mailing list though. We have the same issue with window.alert/confirm.
      (Oleg) Ok, will send question there. I initially was thinking about using notification "tag" property (in MDN mentioned that this property can be used to update\replace notification), but it's still not really handy + I haven't found how to actually replace it :)
  • bug 1034637 - [Messages] Utils.js unit tests are failing when run locally
    • Created patch that adds mock initialization to the Utils test suites that require it.
    • Found out why tests are failing on older FF version (that I've used to use to run tests locally) and passing for the latest nightly. Looks like something changed in Gecko recently so that 'navigator.mozPhoneNumberService' is no longer available when running tests that leads to the fact that some Utils test are even not executed (in review).
      (Julien) ah yeah, could be https://bugzilla.mozilla.org/show_bug.cgi?id=952486
      (Oleg) yeah, maybe

Today: will handle review comments for the patches that currently in review + review patch for the "bug 1033403 - [Messages] We don't stop rendering if we tap "back" too soon". Also would like to think how we can deal with "bug 1034100 - [Messages] in some situations, the character counter overloads the send button"

Demos

bug 1026575: Message preview in Messages app thread view disappears after opening app

  • Before

  • After

bug 1013296: Compose. Change send button to an paper plane icon

  • Before

  • After

bug 1008127: Subject handling in the Composer

  • Before

  • After

  • Before

  • After

  • Before

  • After

  • Before

  • After


bug 1008912: 'MMS' in sms app doesn't translate into other language

  • Before

  • After

bug 1030160: Subject is considered empty (placeholder is displayed) even if it has several empty lines

  • Before

  • After

bug 990537: Messaging. Apply Visual Refresh to DSDS scenarios.

  • Before

  • After

bug 1022755: Possible race in the SMS navigation code

  • Before

  • After

Retrospective

Previous sprint's actions

  • invite all people that work on SMS to daily meetings (this time, we were missing Pavel, Marina) => It seems we didn't make it... (still this)
  • 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
    (Julien) did it work better ? I was not here in the planning
    (Oleg) I'd say that we didn't do anything related to that action :)
  • New blocker which is taken by the developers should be reported in the scrum and estimate the point.
    (Julien) should we estimate the bugs we did after the fact? (I think we should not; it doesn't give much value to estimate them after the fact)
    (Oleg) agree, the value is "pre" estimation, when we can raise questions\concerns and even abandon\delay the bug
    (Julien) I like that we report the bug in the sprint (the current way is fine for me; maybe confusing if one bug is in several sprints like for the subject bug 1008127, since you added "not part of the initial sprint" it disappeared from previous sprints :) not a big deal )

What was good in the last sprint

  • Sprint was completed
  • We've landed the rest of VR (at least the biggest parts);
  • I think we did bigger amount of work then in the previous sprint; +1
    (Julien) why did we do more work, after you ?
    (Oleg) I think we initially picked up bugs that was 100% clear and not much VR bugs that depends on UX :)
    (Julien) good point. We need to take INVEST bugs only (http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29). (mmm maybe it's not the right word here; let's say we need to take actionable and clear bugs :) )
    (Oleg) Yeah, it makes next steps more predictable and you feel better :)
    Also as we planned just 7 points for the sprint, we estimated few bugs more, like next-tasks-to-do pool. But probably if we estimate better and pick up clear bugs we won't need it.
  • Oleg did scrum master stuff (so I did less ;) ) :)

What was bad in the last sprint

  • We did a lot of work marked as [not-part-of-the-sprint] +1
  • comms standup meeting: too many of them, and in the same time, too few interactions with UX/VD in stand up.
    Yeah, I didn't feel much value from comms standup, maybe it's only me.

Any questions

  • David told me the name of our sprint is confusing and that we should use eg "2.0 S6" like everybody else. What do you think?
    (Oleg) Mmm I'm fine with the current one, but I'm not sure what other do and what 2.0 means
    (Julien) "2.0" means version 2.0, "S" means "Stabilization". "6" means "sprint 6"
    (Oleg) After all it doesn't really matter for us how it's named
    (Julien) yep, that's also what I think, we don't really mind. So next one is 2.0S6 ?
    (Oleg) yep
  • Oleg: do you want to keep the scrummaster role for the upcoming sprint? (I mean, managing the scrum pages) I can prepare the page from the planning though.
    (Oleg) I don't mind, anyway mainly you and Steve give updates on Comms, so I'd like to help anyhow :)
    (Julien) about updates, it would be better if it can cycle; maybe when it's Steve turn (it's always Steve turn first) he can ask you or me to speak instead.
    (Oleg) yeah, that should work. Agree, soon we won't have that many of Comms meetings :)
    (Julien) about the full scrum master role, we can discuss/define more formally in a few weeks what it should be, so that it's easier to make it cycle too (especially that I'll be away 3 weeks in august/september)
  • have UX/VD join our sms stand up meeting, not always, but maybe once or twice a week ?
    (Oleg) Probably on sprint planning we can see whether we'll need UX help during sprint, and plan meeting\s accordingly, it can be 0 if we don't anything to do with UX
    (Julien) stand up meetings is a good opportunity to discuss things that happen now... but maybe we didn't miss that so much after all and I'm wrong.
    (Oleg) also we'll have to ask UX what is acceptable for them :)
    (Julien) exactly; but NI works fine too for this.

Actions

  • Try harder to take only actionable and clear bugs
  • we'll use the same sprint names than everybody else. Next sprint is 2.0S6.
  • If we still have Comms standup someway, Steve can ask Oleg or Julien to speak for the team :)
  • define what the scrummaster role is/should be (not for this sprint though)
  • estimate quality metrics only once every 3 sprints.

Grades (5 is very good, 1 is very bad)

(should we keep this? I feel like it's useless after all, I feel the same for now)

(Oleg) I mean that from sprint to sprint not much changes, all characteristics still almost the same. I think it's useful for longer periods than one sprint.
(Julien) it's useful if we take actions to make them better. Maybe keep only some?
(Oleg) I think quality parameters is more long term (I believe we can't change from 3 to 4 during sprint or two), Commited vs Completed is good characteristic even for single sprint
(Julien) maybe not estimate the quality parameters in all sprints, but only once every 3 sprints ? or every version ?
(Oleg) Yeah, I like the parameters itself, but we need more time to change it, maybe 3 sprints can work, let's try
(Julien) ok, let's do this. So in this sprint, we'll estimate only commited vs completed ?
(Oleg) yep, Product Performance - is the physical performance of the app, or performance of the SMS team ? ) Sorry missed meaning of that previously, if it's about performance of SMS app (as I thought) then yes, only every 3rd sprint.
(Julien) performance of the app :) "Product" performance
(Oleg) Ok :)

Commited tasks vs Completed tasks

  • (Oleg) t=3 (a lot of [not-part-of-the-sprint])
  • (Julien) t=3 (only 3 because we did a lot of tasks out of the sprint)
(Julien) we take into account what we think we should, as a team :) do you think it makes sense?
(Oleg), yeah agree, we need to improve current situation
Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/SMS/Scrum/4&oldid=995303"