Gaia/SMS/Scrum/2.2S13: Difference between revisions

Gaia/SMS/Scrum/2.2S13 (view source)

Revision as of 13:07, 6 May 2015

5,291 bytes added , 6 May 2015

→‎Day 2: 6th May

Jwajsberg

Confirmed users

820

edits

@@ Line 93: / Line 93: @@
 == 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 ===
 === Day 4: 8th May ===