Confirmed users
383
edits
Gaia/SMS/Scrum/4: Difference between revisions
Jump to navigation
Jump to search
→Daily meetings
(→Oleg) |
|||
| Line 311: | Line 311: | ||
===Day 8: 3rd July=== | ===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=== | ===Day 9: 4th July=== | ||
===Day 10: 7th July=== | ===Day 10: 7th July=== | ||