List of bugs
SMS issues handled by the SMS subteam (blocks the sprint bug 1162017)
9 Total; 9 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Remaining points and burndown chart
google chart api url for Sprint 2.2S13
| Remaining points | |
|---|---|
| Start | 13 |
| Day 2 | 13 |
| Day 3 | 11 |
| Day 4 | 11 |
| Day 5 | 11 |
| Day 6 | |
| Day 7 | |
| Day 8 | |
| Day 9 | |
| Day 10 | |
| Day 11 | |
| Day 12 | |
| Day 13 | |
| Day 14 | |
| Day 15 | |
| End |
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 | --- | No cf_feature-b2g | [sms-sprint-2.2S13] | FIXED |
1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%);
All SMS issues tracked for this sprint (target milestone)
| 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; 2 Open (100%); 0 Resolved (0%); 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 ;)
- Discuss with Jenny and she prefer to disable the recipient pill selection. Will give a quick patch today
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.
- Investigating possible solutions:
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 :)
- 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.
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.