Confirmed users
820
edits
Gaia/SMS/Scrum/2.2S13: Difference between revisions
Day 3: 7th May
(Remaining points and burndown chart) |
(Day 3: 7th May) |
||
| Line 159: | Line 159: | ||
=== Day 3: 7th May === | === 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 === | === Day 4: 8th May === | ||
=== Day 5: 11th May === | === Day 5: 11th May === | ||