Gaia/SMS/Scrum/2.2S13

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

List of bugs

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

Bugzilla link

ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
1010216 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI --- [sms-sprint-2.2S11][p=2] FIXED
1050823 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Messages][Refactoring] Revise "ThreadUI.updateHeaderData" call while retrieving threads --- [sms-sprint-2.2S11][p=1] FIXED
1155534 [Messages][NG] Extract NewMessage view from Conversation view --- [p(2.2S13)=1][p(2.2S11)=5] WONTFIX
1156464 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app 2.2+ [3.0-Daily-Testing][p=1] FIXED
1160232 Steve Chung [:steveck] [SMS][Text Selection] Attempting to 'select all' in the TO: field of a new message will select text from both the TO: field and the message area 2.2+ [3.0-Daily-Testing][p=1] FIXED
1162027 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Messages][New Gaia Architecture] extract inbox/index.html --- [p=1] FIXED
1162028 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Messages][NG] Extract views/conversation/conversation.html --- [p(2.2S13)=1][p=3] FIXED
1162030 Julien Wajsberg [:julienw] [Messages][NG] Figure out how navigation works --- [p(FxOS-S4)=2][p(FxOS-S3=3][p(2.2S13)=2][sms-sprint-2.2S14] FIXED
1162031 [Meta][Messages][NG] Migrate business logic to bridge-based services --- [p=3] WONTFIX

9 Total; 0 Open (0%); 7 Resolved (77.78%); 2 Verified (22.22%);


Remaining points and burndown chart

google chart api url for Sprint 2.2S13

Burndown chart
Remaining points
Start 13
Day 2 13
Day 3 11
Day 4 11
Day 5 11
Day 6 11
Day 7 11
Day 8 10
Day 9 8
Day 10 8
Day 11 8
Day 12 8
Day 13 8
Day 14 8
Day 15 8
End 7


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

ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
1161985 Steve Chung [:steveck] [Messages][NG] Split recipient and non-compose related styling from compose.css --- [sms-sprint-2.2S13] FIXED

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


All SMS issues tracked for this sprint (target milestone)

Bugzilla link

ID Assigned to Summary Blocking b2g Feature b2g Resolution
1162017 SMS sprint 2.2S13 --- --- INCOMPLETE
1166863 Kevin Grandon :kgrandon [Messages] Convert string.contains to string.includes --- --- FIXED

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


Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 6th May

Steve

  • bug 1155542 - [Messages][New Gaia Architecture] Centralizing the global components/styling into a folder
    • Patch updated with some test media path fixing(might need to create another bug for file xhr loading in assetHelper)
  • bug 1156719 - [Messages][New Gaia Architecture] remove static wait screen markup and set it as shared widget
    • Might apply julien's suggestion for backward compatibility
  • bug 1160232 - [SMS][Text Selection] Attempting to 'select all' in the TO: field of a new message will select text from both the TO: field and the message
    • Discuss with Jenny and she prefer to disable the recipient pill selection. Will give a quick patch today
      (Julien) what do you think? I think there could be cases where the user wants this but maybe that's edge cases? Also this should fix the other related bug 1160244.
      (Steve) I think selection for unwrapped(editing) text is enough to me, and Jenny thought selection for the wrapped element seems not really necessary as well... Maybe typing an existing contact is much easier?
      (Julien) if we can still select in an "editing" pill then I think it's ok for me.
      (Steve) Sorry not sure what's the "editing" pill?
      (Julien) I mean, what you said, the "unwrapped" :) the "contenteditable" one
      (Steve) ah, ok. That's what we propose now. And will take a look for 1160244
      (Julien) if we keep the editing pill, then bug 1160244 will still exist ;)

bug 1160261 - [SMS][Text Selection] Copy & Cutting a block of text that includes an attachment will remove the attachment but Pasting that block back will not restore it

    • Discuss with platform and UX and they don't have a clear plan for supporting the non-text selection yet. Will try to push ux if we could have an alternative solution without API support or we should just leave it.
  • gaia-component stuff
    • Not much progress.

Today:

  • Create subtasks for composer/conversation seperation.
  • shared folder structure polishing.
  • Fix the attachment menu for closing the option menu manually.

Julien

Not much yesterday besides the Sprint planning. I had a conference in the evening and had to prepare the presentation :/ I think I found a bug in our support for getUserMedia though.

(Oleg) Heh, can you point me to this bug? I'm actively using this in my side project :)
(Julien) I did not file it yet but getUserMedia doesn't capture my camera at all on master -- and also the user is not asked if the permission status is "Ask"...
(Oleg) Ah okay, I use v2.2 :)
(Julien) Ok, I haven't tried v2.2 yet, but I'll send you my test app so that you can try :) Yep! Maybe it's me !

Today: I want to:

  • update wiki
  • do necessary reviews
  • start looking at little-browser

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).
  • I'd like to work on the deduplication logic for network alerts, it seems important for users (bug 1067938)

Oleg

  • bug 1156631 - [Messages] ThreadList&Thread separation: separate CSS and image files
  • Fixed last nits, got r+ and landed (landed).
  • bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure
    • Resumed work on this (in progress).
  • bug 1050823 - [Messages][Refactoring] Revise "ThreadUI.updateHeaderData" call while retrieving threads
    • Updated PR with two "notification" integration tests - one that runs application directly by "notification" system message and second one that fires "sms-received" system message, closes Messages, opens Utility Tray and taps on notification (in review).
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • Prepared first patch to get early feedback (awaiting feedback).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Investigating possible solutions:
      • If we just remove "#notification" from manifest we won't have delayed Inbox loading for this case (run app from notification);
      • If we keep the hash and remove it right before we subscribe for system message - it doesn't work for some reason, didn't investigate much though - Julien, did you try something like this in your test app?
        (Julien) nope I didn't try this. I'll add this case in my test app for bug 818000.
        (Oleg) cool, thanks, let me know if it works for you.
      • Currently I only have in mind "mozHasPendingMessages('sms-received')" additional check in startup.js to delay Inbox loading.
        (Julien) pb is that it takes time as well -- but better than nothing :/ can you try to run raptor before/after if you do this?
        (Oleg) Yeah, if it works as expected. Will need to read about running raptor locally though :)
        (Steve) I've heard this API from you few months ago but never saw anyone use it :) :)
      • Will try to find other solutions as well.

Other:

  • Reviewed Steve's "move resources to shared" patch;
  • Reviewed Johan's python-to-marionette-js patch (Messages-Dialer integration test);

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 3: 7th May

Steve

  • bug 1155542 - [Messages][New Gaia Architecture] Centralizing the global components/styling into a folder
    • Patch in review(might need to create another bug for file xhr loading in assetHelper)
  • bug 1156719 - [Messages][New Gaia Architecture] remove static wait screen markup and set it as shared widget
    • no progress, move to background
  • bug 1160232 - [SMS][Text Selection] Attempting to 'select all' in the TO: field of a new message will select text from both the TO: field and the message
    • Patch landed and ask for approval, BTW I don't have any good idea for bug 1160244 now, maybe just wait for next visual refresh in recipient part.
      (Julien) yep; it's really not easy. Only thing I could think of is catching the "contextmenu" event (for longpress) on the empty space and programmatically focus + start select interface. Is it possible ?
      I thought programmatically blur/focus to simulate the focus on recipient part, but the refocus will not 100% work
      (Julien) I think we already "focus" on click, but can we start the user select interface? (I think we can, like for the message bubble, right ?)
      (Steve) Maybe I can try to trigger selection, not sure if it work(because the menu is different)
      (Julien) anyway, not in the sprint, not a blocker, so really not a priority :)

bug 1160261 - [SMS][Text Selection] Copy & Cutting a block of text that includes an attachment will remove the attachment but Pasting that block back will not restore it

    • UX suggest cutting the text only and leave the non-text item... Seem platform will not support this case either. So pend for now :/
    (Julien) From a user point of view I think this is really weird that the non-text disappears even that it's not copied. I think this should not happen... this is just broken.
  • Create subtasks for composer/conversation separation.
    • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css
    • Some discussion about now we split from conversation.js.
  • gaia-component stuff
    • Move to background

Today:

  • Create more subtasks for composer/conversation separation in js part.
  • shared folder structure polishing.
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Julien

Remember: I'm away from tomorrow to next week :)

  • updated the sprint wiki and created the necessary bugs
  • added the new testcase to bug 818000: removing the hash after launching the app does not bring the queued system messages.
  • had a look at bug 1156464 about the notification issue and fabrice cleared the situation. Good !
  • reviewed bug 1050823 which add a whole bunch of integration tests \o/ Thanks Oleg !
  • answered our contributor in bug 1153885 -- please keep a look at this when I'm away :) Okay :)
  • reviewed the simple user selection patch for the 2.2+ bug 1160232. Thanks Steve !
  • proposed a solution for dogfooder bug 1161521 about error messages
  • had to work with David S to explain what we did in the SMS app in 2012 for french fiscal reasons.
(Oleg) Sounds mysterious  :) Is it smth open to share? Just out of curiosity  :)
(Julien) we get money from french government because we do "research" (improving our field's state of the art) -- and the fiscal services will watch our previous reports to see if we haven't cheat. French government is getting harder with the BAFA companies that "optimize" their fiscal taxes, and they put Mozilla in the same bag (which is IMO not right but hey :) ). Also in France we have no benefit so no tax on the benefit; basically the government is giving us back money (of course there is still a tax on our salaries so we're still giving taxes in the end :) which is normal). Well that's basically it.
(Oleg) Wow, thanks for exhaustive explanation! Good to know :)
(Steve) Interesting, don't know if there's similar rules in Taiwan, but I think Taipei office didn't have this kind of "reward" at least :)
(Julien) we had to do a big file to explain what we do, what is new in the field, etc. It was so painful that we didn't do it for 2013. But we might do it again for 2014.
(Steve) Well yeah you still need to paid some other efforts for it

Today: I want to:

  • finish reviews
  • start looking at little-browser

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).
  • I'd like to work on the deduplication logic for network alerts, it seems important for users (bug 1067938)

Oleg

  • bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure
    • No progress since yesterday (in progress).
  • bug 1050823 - [Messages][Refactoring] Revise "ThreadUI.updateHeaderData" call while retrieving threads
    • Got r+, fixed review nits and landed (landed).
    • It unblocks "[Messages] Display existing thread when sending a message using phone-number-/email-link context menu" that I work on in background and integration test part for "#notification" blocker.
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • No updates since yesterday (awaiting feedback).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Prepared v2.2 patch with "mozHasPendingMessage", the main difficulty was that when we remove "#notification", Navigation.init (that should be called before any navigation happens) parses hash and immediately starts navigation to default panel (maybe in master we can decouple "init" and "navigation", they look like a separate "functions" anyway), so patch tries to prevent navigation to default panel if we have pending "notification" message;
    • Measured performance of "mozHasPendingMessage" for v2.2 branch with Raptor (please note that it doesn't work for Flame on v2.2 out of the box yet - see bug 1155814, to fix it locally you can just install the latest Raptor version with "npm install gaia-raptor@1.4.1"). So it looks like there is no big perf penalty and Fabrice confirmed this as well.
    • Today will tune v2.2 patch + add unit tests (no plans for integration test on v2.2 since our marionette tests diverged from v2.2, not sure if it makes sense to uplift marionette-only bits to v2.2 in a separate patch altogether) + master patch (maybe do smth smarter) with unit and integration test.
      (Julien) on v2.2 please test throughly before landing while I'm not here :) all situations like being in a thread and tapping the notification for another thread, killing the app, etc.
      (Oleg) Yeah, sure!

Other:

  • Discussed python-to-marionette-js patch with Johan again, still want it to be less coupled with Dialer and without redundant inheritance :)

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 4: 8th May

Oleg

  • bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure
    • No progress since yesterday (in progress).
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • Got feedback and replied, will handle comments (in progress).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Prepared patch removes "toPanelFromHash", received feedback from Julien, replied. WIll experiment with moving initdefaultpanel to InboxView; (in progress)
    • Added integration test for this case;
    • When I added "mozHasPendingMessage" our notification tests became red, spend some time understand the issue - mozHasPendingMessage is always false in B2G if called too early after startup - discussed with Kan-Ru and filed bug with test app and Scratchpad scipt to reproduce "bug 1162899 - [B2G Desktop] navigator.mozHasPendingMessage always returns false when queried too early in app startup path". I'm wondering if this race problem is "real" and can happen on device.

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Steve

  • On PTO

Julien

  • On PTO

Day 5: 11th May

Steve

  • bug 1155542 - [Messages][New Gaia Architecture] Centralizing the global components/styling into a folder
    • Landed
  • Create subtasks for composer/conversation separation.
    • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css, will create a WIP for recipients.css separation
    • Create a WIP for clean up some duplication related to compose part.
  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Start some experiment about the bridge lib. Before start it we might need to solve the naming conflict issue first, but I don't think our build environment will support browserify naively and we might need to browserify manually, will try to find a proper way for rename the threads module first.

Today:

  • Solving the threads.js naming conflict temporary.
  • Create more subtasks for composer/conversation separation in js part.
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Julien

  • Absent/no report

Oleg

  • bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure
    • No progress since yesterday (in progress).
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • Handled most comments will ask for review today (in progress).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Handled part of the review comments and involved Steve into discussion, my main concern is that Julien's proposition is risky for v2.2, going to prepare patch for review today once we work out good solution (in progress).
  • bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu
    • Rebased on the latest master since a lot of conflicting changes landed, will be ready for review once "bug 1153885 - [Messages] Remove Utils.getContactDisplayInfo" is fixed (in background).

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 6: 12th May

Steve

  • Create subtasks for composer/conversation separation.
    • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css, will create a WIP for recipients.css separation
    • Got some feedback from form duplication clean up WIP. Will polish it in background.
  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Utilize browserify to package the lib into another name for testing first. Will start from draft(since mobilemesage/contact seems unable to work in worker yet)
      (Oleg) You'll probably need to keep eye on my PR that modifies drafts as well to have less conflicts :)
      (Steve) yeah I know you're also working on this part
  • Gave some feedback for notification system message issue

Today:

  • Create more subtasks for composer/conversation separation in js part.
  • Start from moving the draft into worker and utilize the threads lib.
  • Review draft handling patch
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Julien

  • Absent/no report

Oleg

  • bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure
    • Started to work on this again, remove some more InboxView-ConversationView dependencies (related to contact change, drafts update and few others) (in progress).
    • I still see that we have three dependencies that I don't have good plan for:
      • When we enter conversation we need to mark conversation as read in InboxView (and when this conversation is rendered, it was a problem when app was opened from notification for example) - here we can probably rely on future service that will emit appropriate event and local IDB;
      • ConversationView currently decides whether or not InboxView will show "draft saved" bottom banner - will probably be resolved once we change drafts auto save/discard behavior discussed in dedicated email thread recently;
      • When we delete message in conversation view and if it was the last one - we should update Conversation in InboxView - we can probably resolve it with our own messaging service that fires event (we currently have ondeleted event in mozMobileMessage but it only contains messageId, so that InboxView can't know from which thread message was deleted).
(Steve) About the deletion in Inbox, I think you could get threadid from Threads, but you might need to expose a method for it(or fire a event from Threads once we move it to "service")
(Oleg) Yeah I was thinking about our custom service that knows from which thread message was deleted, with just mozMobileMessage event I need single messages map in threads to do fast lookup, or Threads.js has single messages map already?
(Steve) Ya I think Threads.js maintains a messages map now
(Oleg) Good, will check this out, thanks! If we delete message then it should guarantee it was added to this messages map. I think we don't have cases when message is deleted without visiting thread (only if we remove conversation from InboxView, but in this case we don't need to update conversation :))
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • Handled feedback comments and asked for review (in review).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Got Steve's feedback, Steve do you think we can have v2.2 solution for both v2.2 and master (I plan to have integration test for master once dependency is resolved, not sure if v2.2 gets this fix - bug 1162899 - [B2G Desktop] navigator.mozHasPendingMessage always returns false in in-process app) and improve for master later if needed? (in progress).
(Steve) Shouldn't we nominate 1162899 as 2.2 blocker as well? I'm fine if we use same approach for 2.2/master(actually I'm not sure if we can get much benefit from changing navigation part in master now)
(Oleg) Yeah, I'd keep it as in v2.2 patch currently, it will likely change in master anyway, maybe we'll have much better idea for ng later.
  • bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu
    • No progress since yesterday (in background).

Other:

  • Left feedback for Steve's patch related to moving toasters to Compose;
  • Left some more thoughts on improving inter-app integration tests in Johan's PR.

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 7: 13th May

Steve

  • Create subtasks for composer/conversation separation.
    • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css, WIP created for early feedback
    • Got some feedback from form duplication clean up WIP. Will polish it in background.
  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Discussed with Oleg about the first step for migrating to threads.js. We might need to rewrite our Draft module into async require instead of sync direct access. Create bug 1163955 for this async promise base Drafts
  • reviewed for notification system message issue

Today:

  • Find a proper way to rewrite drafts in async.
  • Review draft handling patch, looks good and works great without any regression. Will take a deeper look then.
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Julien

  • Absent/no report

Oleg

I'm on PTO starting from tomorrow till Monday

  • bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure
    • More improvements and unit tests, replaced Threads.js dependency with mock_threads.js in inbox and conversation unit tests since Threads will become service anyway and won't be able to use it directly in tests (in progress, waiting for dependency).
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • Waiting for review (in review).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Prepared v2.2 and master patch (almost the same + integration test) and asked for review for v2.2 patch (in review);
    • Tried all cases I can imagine in v2.2 and master - haven't noticed any problems so far.
    • "bug 1162899 - [B2G Desktop] navigator.mozHasPendingMessage always returns false in in-process app" is landed, will check today if it reached Treeherder and if so will ask for review for master patch as well;
    • Tried to port notification integration test to v2.2 as well - but it requires a lot of code we did in master (e.g. mock_storages) + the same test that uses system utility tray lib doesn't work in v2.2 like it did in master, so decided to not spend much time on it.
  • bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu
    • No progress since yesterday (in background).

Other:

  • Left some feedback and suggestions for bug 1153885 - [Messages] Remove Utils.getContactDisplayInfo

Today:

  • Will handle review/feedback/need-info requests; Steve's PR is in priority.
  • Will work on review comments and assigned bugs.

Day 8: 14th May

Steve

  • Create subtasks for composer/conversation separation.
    • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css, Got feedback and will work in background
    • Got some feedback from form duplication clean up WIP. Will polish it in background.
  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Start to profiling the result after introducing the threads library. Will update on bug later
  • bug 1163955 for this async promise base Drafts
    • Start to investigate whether it's necessary to rewrite all methods into promise. If the service sync callback won't take much time, maybe we can still keep sync methods for now.
  • reviewed for notification system message and drafts refactoring patch
  • Message bug reply

Today:

  • Investigate whether it's necessary to rewrite drafts in async.
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Julien

  • on PTO

Oleg

  • on PTO

Day 9: 15th May

Steve

  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Service callback might be pended because of busy main thread, will create a WIP that a workable inbox panel with draft service
  • bug 1163955 for this async promise base Drafts
    • Instead of make every method into promise, another idea is to maintain a simplified draft cache in inbox view. Will apply this idea in bug 1162031 WIP
  • Reply some message related bugs

Today:

  • Create the WIP for bridge experiment
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Julien

  • on PTO

Oleg

  • on PTO

Day 10: 18th May

Steve

  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Wilson confirmed that service message might be delayed because of busy thread, so for the first experiment I tried caching the drafts for inbox and start to fetch/render message after drafts cache ready. I've added some profiling result for it and this approach might introduce ~400ms delay for visually loaded(But I don't think it's a fair comparison because the original visually loaded didn't consider the draft rendering)
  • bug 1163955 for this async promise base Drafts
    • See bug 1162031 and I might tried this approach instead because the delay of service message return. Will add some thought about draft caching and what we might be able to do for current master.
  • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css
    • Reply the feedback an discuss the naming for composer widget and view.
  • Reply some message related bugs

Today:

  • Add more conclusion for bridge experiment result and the next action item
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Tamplate.js

Oleg

  • bug 1162027 - [Messages][New Gaia Architecture] extract inbox/index.html
    • Prepared patch, will rebase on master, verify and ask for review (in progress).
  • bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI
    • Got review, landed (landed).
  • bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app.
    • Got review for both master and v2.2, and approval for v2.2 (landed).
  • bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu
    • Rebased on the latest master, waiting for "bug 1153885 - [Messages] Remove Utils.getContactDisplayInfo".

Other:

  • Left feedback on "bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css".

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 11: 19th May

Steve

  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
    • Await for Wilson's update about the busy service issue and asking feedback in bug 1163955
  • bug 1163955 for this async promise base Drafts
    • Asking for the early feedback about the drafts implementation in inbox view. I listed 2 approaches about always access drafts by bridge and create a cache for drafts.
      (Julien) I have several thoughts already but I'll add them soon on the bug; but mostly I don't think we need to workaround performance issues yet -- mostly report them. For example Francisco told me that the _first_ postMessage with a worker is very long, but that this should/will be fixed.
      (Oleg) Then we should probably notify master dogfooders if any that performance is going down :) Oh I also see new raptor tests on Treeherder - won't it block us from landing (though we can probably do it manually without autolander)?
  • Creating another meta bug for moving Threads into service and follow bug for implantation details
    • (Julien) I only wonder if we should not wait for having the DB ? Or do you think this is needed to have the service (even without DB) before moving forward?
      (Oleg) I'd say we need service with API that will be the same when we have DB (ideally :)), but probably need your update about local DB to better understand how it will work and what data it will contain.
      (Julien) I think we need to create the API just like we would do for a server API; so maybe starting with an etherpad to decide how the API should look like ?
      (Steve) I have the same thought like Oleg said that it might be the same when we have DB, but maybe you have another thought about the DB implementation
      (Julien) Oleg says: we need to have the same API than when we'll have the DB; you say: we'll have the same API than we have now when we'll have the DB. Not the same ;)
      (Oleg) We can discuss on etherpad to avoid confusion then. I mainly interested in what info about thread local DB will have
      (Steve) Ah , ok I misunderstood it :p
      (Julien) Steve, can you take the lead of starting the etherpad about this?
      (Steve) https://etherpad.mozilla.org/ng-message-threads-api
  • bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css
    • R+ and landed on master.

Today:

  • Create bugs for moving Threads/Drafts to server
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Template.js

Julien

I mostly read through my mail and bugmail. Today: I want to:

  • do reviews
  • start looking at little-browser

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).
  • I'd like to work on the deduplication logic for network alerts, it seems important for users (bug 1067938)

Oleg

  • bug 1162027 - [Messages][New Gaia Architecture] extract inbox/index.html
    • Prepared patch, asked for feedback (awaiting feedback/in progress).
    • Playing with composite startup.js, not sure if I can come up with something smart in this PR.
  • bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu
    • Rebased on the latest master, waiting for "bug 1153885 - [Messages] Remove Utils.getContactDisplayInfo".
      (Julien) maybe you can try to a little more actively help the contributor? Like asking on the bug how it goes, etc? (I can switch the mentoring to you :) )
      (Oleg) Hah, I talked to him on GitHub mostly :)
      (Julien) if you're still in contact with him on github it's fine :)

Other:

  • Reviewed "bug 1161985 - [Messages][NG] Split recipient and non-compose related styling from compose.css";
  • More discussion on "new" integration test approach with Johan - getting closer;
  • Tried to run Simulator 3.0 in WebIDE with custom profile and provided contributor with the steps.
  • Noticed pretty sever graphic (probably) issue in sms - jumping and black squares when user navigates back from composer to inbox and save/discard draft dialog was displayed - will check again on the latest PVT and file a bug if it's still the case.
    • (Steve) Isn't it solved by backing out bug 1162383(from the information in bug 1164357)?
    • (Oleg) I guess no, I've used the latest PVT build it should have contained that back out I think
    • (Steve) Hmm but I can't not reproduce it from PVT build in last Friday, anyway I think QA should verify this since it's marked as resolved
    • (Oleg) Honestly they look like different issues, but can't say for sure :) Will check again

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 12: 20th May

Steve

  • bug 1162031 - [Messages][New Gaia Architecture] use the bridge with a shared worker
  • bug 1163955 [Messages][New Gaia Architecture] Preparation work for moving Drafts into back-end service
    • Oleg have some idea about the merge all the data into one local cache. But do we need to wait for all the data/cache for rendering the message? I have some concern about this draft caching idea if there's lots of draft data, so merging all the data into cache would be much harder to decide when we can start rendering.
      (Oleg) It was Juiien's idea to return "full" thread from Threads service :) But I was thinking about smth similar, but I'm not sure how fast will we be if store drafts in IDB and nowhere else, like we need full list only once when we return all threads. Maybe we can discuss on etherpad further
      (Julien) yes, this is out of the scope of the standup but it's good to have this conversation :)
      (Steve) yeah let's discuss in etherpad
  • Creating https://etherpad.mozilla.org/ng-message-threads-api for thread service discussion, will read the new feedback for yesterday.
  • Review the markup split patches from Oleg.

Today:

  • Create bugs for moving Threads/Drafts to server
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Template.js

Julien

  • spent time helping a contributor on bug 1153885
  • spent time with Jacob and Francisco to explain them how we work; they want to show what we do at Whistler (there will be a 30-minute presentation done by us) so Jacob would like to know what we can show .. but he said it's fine to wait one more sprint and we can show what is ready at that moment.
  • spent also some time on non-SMS issues
  • added my thoughts on the API etherpad https://etherpad.mozilla.org/ng-message-threads-api

Today: I want to:

  • do reviews
  • start looking at little-browser (I'm quite sure I'll be able to start this at last !)

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).
  • I'd like to work on the deduplication logic for network alerts, it seems important for users (bug 1067938)

Oleg

  • bug 1162027 - [Messages][New Gaia Architecture] extract inbox/index.html
    • Got feedback, will handle comments and make patch review-ready (in progress).
    • Spent some time to figure out how to split startup files between views so that it possible to use for current main index and in-iframe cases at the same time - didn't come up with smth good, so delayed it for now.
  • bug 1162028 - [Messages][New Gaia Architecture] extract conversation/index.html
    • In the meantime investigated what dependency we have to run conversation in a separate document/iframe - it's activity handler (played with this, added WIP patch for your feedback), InboxView (we'll have 3 direct dependencies after bug 1162027 that can be solved with services) (in progress)

Other:

  • Left feedback on Steve's WIP;
  • Filed regression bug about black artificats with video, but in late evening noticed that master isn't usable at all - dialogs in SMS can't be closed - it was crazy, will check today with fresh mind :)
    (Julien) I think Alexandre discussed about this on #gaia, it's been backed out (but I think it's a gecko issue)
    (Oleg) Ah, good, no need to worry then :)
  • Reproduced security issue with directional marks in URLs - pretty funny :)
    (Julien) could you reproduce when receiving a message ?
    (Oleg) I just add this unicode symbol into message.body programmatically when MessageManager returns it - but I believe it's quite possible to do with real sms clients/online-gateways. Maybe we can ni? Bevis to be sure that non-printable chars can pass in real world. I thought that reporter reproduced it with real sms.
    (Julien) I'm not so sure :) That's why I also asked about e-mails because this is likely much more easy with e-mails. With emails we could also have HTML emails like <a href='http://ba.fraudulous.com'>http://ba.com</a>, I know I receive such phishing emails anyway, and I'm not sure we do anything about this in FxOS email client. And this is also likely more widespread too (chat applications?) so I think the solution should be elsewhere, like in Browser. I wonder how Firefox Desktop behave BTW.
    (Oleg) If you enter ctrl-shift-u-202e to URL bar it will be reverted, not sure if it behaves the same if we copy and paste. Yep in desktop, just checked
    (Julien) oki; and I'd like to know how it works when we just click such a link somewhere :) So yeah, the issue can be widespread and we need a global response :)
    (Oleg) Yep, but I feel we still need to take care of it in apps that receive external content. Will see.

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 13: 21st May

Steve

  • bug 1163955 [Messages][New Gaia Architecture] Preparation work for moving Drafts into back-end service
    • Update some thought about the Threads cache, a possible idea is migrate draft fetching inside Threads service and split the draft modification into another service.
  • Gave some feedback about split for inbox markup.

Today:

  • Discussion what we might need to do first for cache
  • Review Oleg's patch about inbox/conversation markup
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Template.js

Julien

  • spent time working on a way where we could use an iframe to handle system messages, but this is not really working well... especially notification/activities will still need to be in the main app. (this is for bug 1162028) + gave feedback on this bug too.
  • added a little more thoughts on the API etherpad https://etherpad.mozilla.org/ng-message-threads-api -- I see Steve is editing it so I'll look at it again today :)
  • I started looking at navigation. I was told little-browser won't be used but rather we need to look at Chris Lord's Navigation Transition polyfill: https://gitlab.com/Cwiiis/gaia-navigator. So I started looking at it and I'll start prototyping around this.

Today: I want to:

  • start looking at navigation

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).
  • I'd like to work on the deduplication logic for network alerts, it seems important for users (bug 1067938)

Oleg

Sorry guys, will miss today's standup. Also May 25th is public Holiday in Germany (I like this May in Germany, so many holidays :) )

  • bug 1162027 - [Messages][New Gaia Architecture] extract inbox/index.html
    • Fixed feedback comments and asked for review (in review).
  • bug 1162028 - [Messages][New Gaia Architecture] extract conversation/index.html
    • Got first feedback from Julien, will verify Julien's concerns today (awaiting feedback / in progress).
    • Digging into threads.js to understand how it works and how to utilize it correctly for activity-service, found small bug https://github.com/gaia-components/threads/issues/35

Other:

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Kumar Rishav and Vishnu Teja

https://etherpad.mozilla.org/sms-contributors-standup

Day 14: 22nd May

Steve

  • bug 1163955 [Messages][New Gaia Architecture] Preparation work for moving Drafts into back-end service
    • Add some thought about the cache we want. Will read the feedback later
  • Just play about the threads library that adding another iframe into service in order to test if it's possible to set the webapi that unable to run on worker thread. But I can not figure out how to make the iframe service work... :/
    (Julien) there is an example in the README I think: https://github.com/gaia-components/threads/#supplying-a-target
    (Steve) Yeah I just follow the example but service didn't response
    (Julien) I'd be happy to have a first look at the code to see if there is an obvious issue, but otherwise we can ping wilson.
    (Steve) Will ping him on bugzilla later
  • bug 1167144 - [Messages] Reduce the use of Threads.active and Threads.currentId in conversation view
    • I was thinking if it's possible to remove all the use of Threads.currentId/active and query the thread id from location.hash, but maybe it's not a good pattern and it migh
  • Gave some feedback about split for inbox markup.

Today:

  • Discussion what we might need to do first for cache
  • Review Oleg's patch about inbox/conversation markup
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Template.js

Julien

Today: I want to:

  • continue looking at navigation

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).
  • I'd like to work on the deduplication logic for network alerts, it seems important for users (bug 1067938)

Oleg

  • bug 1162027 - [Messages][New Gaia Architecture] extract inbox/index.html
    • No progress (in review).
  • bug 1162028 - [Messages][New Gaia Architecture] extract conversation/index.html
    • Since I have some initial feedback, I've moved forward here (awaiting feedback/in progress):
      • Made both client and server to behave like factory/signleton, it's actually good since I see threads.js creates subjectively too many broadcast channels (and not sure if all should be closed explicitly when app is terminated).
      • Added all required unit tests;
      • Added support for the case when we have two instance of Messages app, one - main and second is inline activity - it didn't work because activity client in the second app instance connected to service defined in instance #1 (see note https://github.com/gaia-components/threads/blob/master/lib/client/index.js#L145). Now I just create activity client & service only when app is run as activity, we don't have to do this with other system messages. So now all activity cases should work fine;
      • Alternative solution can be top context/window prefixed service-name.
      • Some more details on how it works in the same window: since we don't use ThreadsManager for the activity-service, it doesn't have to spawn neither worker or create iframe. When we create client it tries to find appropriate service via dedicated BroadcastChannel, since both service and client creates this channel they can detect each other, it's like sub-optimal when both client and service in the same context/window, but we don't have such situation in longterm, from the API standpoint I'd say they should support fast-path for such cases when context-bound centralized service registry is used.
  • bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu
    • Since this PR makes both Conversation view and ActivityHandler simpler I've just removed conflicting changes from my PR (conflict with bug 1153885) and resumed work on this bug, while sprint bugs are reviewed.
      (Julien) +1

Other:

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 15: 25th May

Steve

  • bug 1163955 [Messages][New Gaia Architecture] Preparation work for moving Drafts into back-end service
    • Trying to put this rough idea into drafts for the relation of the "Threads" we want to maintain.
  • bug 1167495 [Messages][l10n] Fix file path changes in l10n xfail.list
    • Fix the l10n precommit hook failed problem because of invalid file path. r+
  • bug 1167144 - [Messages] Reduce the use of Threads.active and Threads.currentId in conversation view
    • Will create a patch today.
  • Reviewed Oleg's markup spiting patch and left one concern about the thread update mechanism.

Today:

  • Create a drafts about the first version of the Threads service
  • Review Oleg's patch about activity
  • Clean up the use of threads.active in conversation view
  • Some tasks for background
    • Fix the attachment menu for closing the option menu manually
    • gaia-component stuff
    • file loading in Template.js

Oleg

  • bug 1162028 - [Messages][New Gaia Architecture] extract conversation/index.html
    • Fixed next review comments, more tiny improvements, integration test for the issue Julien found, will read Julien's concerns about solution I've provided and reply (in review/in progress).
    • Discussed es6 syntax in build file a bit;
  • bug 1172902 - [Messages][NG] Use SimpleOfflineCache to cache all app resources
    • No progress so far.

Other:

  • Reviewed "bug 1169558 - [Messages][NG] Lay out Conversation service structure";
  • Reviewed "bug 1171865 - [Messages][NG] Layout mozMobileMessageShim structure";
  • Reviewed "bug 1174062 - Use click() for attachButton too";
  • Commented on Wilson simplification proposal;

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Demos

No demos this time, as the sprint was mostly technical background things.

Retrospective

What was good in the last sprint

  • We finally touched threads.js and raised some concerns
  • Small amount of v2.2 blockers allowed to concentrate on ng work
  • we could touch all libs (except service workers)
  • Have some premature idea about how we refactor our services
  • Comprehensive discussion with Johan on python-to-marionette-js integration test migration that is important for staying stable during ng work.

What was bad in the last sprint

  • We haven't done everything we planned
    • do we know why ? I don't think it's that bad, we still did most of the goals -- I don't think the goal was to land everything we planned (but we still over-committed, I think).
    • Note: David S asked me to commit to less bugs so that we can finish sprints, so that managers can rely on the fact that if we take a bug we'll do it.
    • " I don't think it's that bad" ---> no, no - it's not that bad, but still not very good :) for me main reason was that I just switched to getting rid of dependencies. Maybe not very necessary everywhere right now. "Underestimate and overdeliver"? :)
    • Sorry I'm not sure about "commit less bug",
    • (means: put less bugs in the sprint; when we put a bug in the sprint, it should mean "we're sure this bug will be done at the end of this sprint", that's what we call "committing")
    • Ok, I think we underestimate the efforts for sure(or we should put more buffer for discussing)
      • Agree, we need to discuss important things more to have agreement earlier
      • Will try to create bug with small but clear action item, that might be easier to see the progress
      • I think that was the goal of my defining use cases yesterday -- and we can rediscuss about this during planning later.
  • One more related thing - I found etherpad isn't very good for "discussions distributed in time", I mean I don't know about updates right away
    • yeah I agree -- I think you prefer google docs ?
    • Yeah, but I don't know much alternatives - we can try anything else if you guys have in mind?
    • wondering if github could offer a platform for this -- we get notifications with comments in PR.
    • Will work too, we can have kind of README/Spec of service for example that we discuss.
    • yep for example, and we could merge the changes
    • Yeah sounds good, we should try - if we have it committed it would be great to have architecture/important things docs in tree.
    • should this be in gaia or in a separate repository ?
    • Actually if we talk about service architecture I even can imagine sms/services/activity_or_conversation/README.md for example..
    • Do we need to have separate doc for services?
    • No preference, maybe one for all at first
    • No prefer +1, and having a doc should be a good start
    • So we can file a bug about landing a README (or other) with the spec, and this would be one bug to estimate later. Does this feel good?
    • "bug to estimate later." - you mean "create spec" bug that we'll estimate later today during planning? If so - then yep sounds good. This bug will block bug with actual service implementation. Yep estimate later in the meeting ;) Okay :)
  • Gecko regressions in graphics broke my usual workflow (flash the most recent gecko every day)
    • I stopped doing that ;) Now I ask somebody who flashes everyday (usually Alexandre Lissy) to know if I can flash ;)
    • Ha-ha, good way of "safe" updates!
  • We didn't plan well for the services part that might need overall redesign our structure

Any questions

No questions this time.

Actions for next sprint

  • undercommit in the sprints.
  • use bugs and github's PR for spec definition and changes