Gaia/SMS/Scrum/4: Difference between revisions
(→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=== |
Revision as of 08:15, 3 July 2014
List of bugs
SMS issues handled by the SMS subteam (blocks the sprint bug 1028276)
7 Total; 7 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Remaining points and burndown chart
google chart api url for Sprint 4
Remaining points | |
---|---|
Start | 7 |
Day 2 | 7 |
Day 3 | 6 |
Day 4 | 6 |
Day 5 | 3 |
Day 6 | 2 |
Day 7 | |
Day 8 | |
Day 9 | |
Day 10 | |
End |
SMS issues handled by the SMS subteam outside of the sprint (blocks the sprint bug 1028276 with whiteboard "not-part-of-initial-sprint")
ID | Assigned to | Summary | Blocking b2g | Feature-b2g | Whiteboard | Resolution |
---|---|---|---|---|---|---|
1008127 | Pavel Ivanov [:ivanovpavel][:pivanov] UX | [Messages][Refresh] Subject handling in the Composer | --- | No cf_feature-b2g | [sprint2 p=3][sprint3 p=2][not-part-of-initial-sprint] | FIXED |
1008912 | Oleg Zasypkin [:azasypkin] | 'MMS' in sms app doesn't translate into other language | --- | No cf_feature-b2g | [sprd309681][not-part-of-initial-sprint] | FIXED |
1013296 | Arnau March [:arnau] ( not working in Firefox OS anymore :( ) | Compose. Change send button to an paper plane icon | --- | No cf_feature-b2g | [p=1][not-part-of-initial-sprint] | FIXED |
1022755 | Julien Wajsberg [:julienw] | Possible race in the SMS navigation code | 2.0+ | No cf_feature-b2g | [p=3][not-part-of-initial-sprint] | FIXED |
1030160 | Steve Chung [:steveck] | [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines | 2.0+ | No cf_feature-b2g | [not-part-of-initial-sprint] | FIXED |
1034637 | Oleg Zasypkin [:azasypkin] | [Messages] Utils.js unit tests are failing when run locally | --- | No cf_feature-b2g | [not-part-of-initial-sprint] | FIXED |
6 Total; 6 Open (100%); 0 Resolved (0%); 0 Verified (0%);
All SMS issues tracked for this sprint (target milestone)
10 Total; 10 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Sprint planning
Minutes are on a separate page.
Daily meetings
Day 2: 25th June
Steve
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Partner reported that the issue still exist, but I could not reproduce it...
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- Feedback+, still working on the test
- bug reviewing:
- bug 925404 - [B2G] [SMS] Always include the phone number in the SMS Thread UI, even if the carrier is known: r=me
- bug 1025552 - Refactoring for attachment rendering: No serious issue discovered right now, maybe we can land for this sprint.
- bug 974867 - [MMS]Auto suggestion for email address: Some suggestion gave, the test still failed.
- bug 959201 - [Messages][Drafts] Wrong Cursor position in the message compose of a Draft: Some feedback given and r+
Today:
- Try to clean(or reduce) the review queue
- Update patch in bug 1022644
Oleg
- bug 008127 - [Messages][Refresh] Subject handling in the Composer
- We finally have patch that works, and don't see any issues! It requires JS changes, but it's much less risky now. So I prefer to go with it instead of changing layout and fixing regressions later on. Tightly collaborated with Pavel yesterday, it speeds up the process a lot. Some cleanup is left from both CSS and JS sides, once we finish, Pavel will ask for review from Steve (in progress, almost done).
- bug 1025552 - [Messages][Refactoring] Refactor attachment.js and specifically move rendering part to a separate module
- Rebased on the latest master (in review).
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
- Tried to reproduce it many times, with Buri and Flame, using git revisions mentioned in the bug and master, but without luck. Noticed that in video attached to the bug, timestamps for the thread and the single message in it are different that made me think that thread was manipulated somehow, but QA didn't confirm that. The only a bit similar case that I found is when we have "empty" draft for the thread (just a space or new line in message input an save it as a draft), but it's still not the same issue.
-> Steve, do you have any ideas? I'm using PVT builds, but QA mentioned some tinderbox builds, I don't really know much about it, found only something similar (https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/). Can "tinderbox vs nightly pvt" builds be the reason why I can't repro this? -> Based on QA's description, tinderbox build will produce more frequently (4 times a day or more) for finding the regression window with less effort. But basically the code base is the same. The only possibility might be the some changes that need patches from both gaia and gecko, but tinderbox build created with one side is not ready yet. But if it's still reproducible on the latest build, maybe we could ask them to try in on PVT build? -> Yeah, probably it's the only thing I can do :) Thanks! Will ask Jayme to check that with PVT. And will try to manually flash with tinderbox build they mentioned.
- bug 1013296 - Compose. Change send button to an paper plane icon
- Went through the bug and haven't noticed why it can depend on subject handling patch, we may touch the same stuff in CSS, but it isn't really a dependency. Asked Arnau to proceed with this patch.
Other:
- Added demos to the Sprint 3 Demo page for the carrier header patch + closed related "bug 883911 - [SMS][MMS] Update all occurrences of "Type ? Carrier ? Number" strings to same format" as it's covered by the carrier header patch.
Today: handle review comments for attachment refactoring patch, will polish JS part for the subject handling patch.
Day 3: 26th June
Steve
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Ask help from Oleg, but I can reproduce the issue with his step in https://bugzilla.mozilla.org/show_bug.cgi?id=1010690#c102. Will investigate further and inquire other help from system platform.
-> Phew :) I thought I the only one with this strange issue and STR :) I can not reproduce it if music is always on. -> Yep, initially I thought that it caused by RemoteControls.play (when I press Play\Pause in the notification panel) which calls getSelf and due to the bug in it, onsuccess isn't fired for the rest of calls (that made from our App). But wasn't able to confirm that :( Seems I'm wrong. -> Also I can't reproduce it when I resume the song, but it ends soon and always reproduce when I have song playing at the beginning :) Mess :( -> Have you tried that only make the music app from background to foreground and not playing the song? -> Not yet, maybe I could try this one myself to clarify. -> I also will try simpler and more stable STR, but I'm "glad" that it doesn't work for SMS as it simpler and faster to test. Do you have any tips on how to use logcat more efficiently? I only use it as "adb logcat | grep Gecko"I also use grep for filter... :p Maybe you could try DDMS -> Oh, never heard about that (but just googled :) ), will check it out, thanks!It's Android Developers tool kit that have graphic UI and you could treat the logcat more convenient. -> Nice! Also forgot to mention (that happened to me only once though) that after a long testing with lots of missed notifications, even after rebooting and without Music I stopped to receive any notifications for the messages coming to "target" thread.
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- Test added and request review
- bug reviewing:
- bug 1025552 - Refactoring for attachment rendering: Landed
- bug 974867 - [MMS]Auto suggestion for email address: Partner request another review.
- bug 1013296 - Compose. Change send button to an paper plane icon: Arnau update the patch again that might has less side effect on DSDS device. Reviewing and testing.
- bug 959201 - [Messages][Drafts] Wrong Cursor position in the message compose of a Draft: Landed
- bug 963043 - [MADAI][Dialer] Select phone number from Call log as Recipients from SMS App. Feedback given but they have to fix conflicts first.
Today:
- Try to clean(or reduce) the review queue
- Update patch in bug 1022644
Oleg
- bug 1008127 - [Messages][Refresh] Subject handling in the Composer
- Polished my JS part, so it's ready. Today will merge it with the latest patch from Pavel to test merged patch on device (in progress, almost done).
- bug 1025552 - [Messages][Refactoring] Refactor attachment.js and specifically move rendering part to a separate module
- Fixed last review comments and landed (landed).
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
- After discussion with Jayme on IRC we found out correct STR for the issue, so that I can now reproduce it: user just need to open composer, send message to create new thread, once user is automatically navigated to the newly created thread, SMS app should be closed with the card view (app manager? not sure what is the common name for it). In this case onVisibilityChange is triggered and empty draft is saved (due to bug in onVisibilityChange). Then when user opens app he sees how message preview is quickly replaced with the empty draft :) I have PR for this, attaching it to the bug at the moment.
- bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
- While working on subject handling patch we've noticed that issue. I don't see easy and safe solution for it, so we have small workaround in the subject handling patch for this case.
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Spend some time trying to reproduce this issue. Finally was able to reproduce with SMS (MMS's are quickly eating mozilla's prepaid plan :))lol. Yeah, real life :) I've described what I saw in my comment to the bug, but didn't have time to systematize it to understand the reason
Other: Today: will review patch from Steve related to recipient panel with 2 lines, send patch for bug 1026575 for review and handle review comments + send subject handling patch for review if don't notice any serious issues while testing on device. Will try to find the root cause for Tarako issue with missed notification.
Day 4: 27th June
Steve
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Will verify with latest build with gecko patch bug 1026737 landed
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- r+, will land to master and v1.3t
- bug 1021513 - [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode
- Will create patch today. Just set the transitionend event listener on the correct element will fix this issue.
- bug reviewing:
- bug 974867 - [MMS]Auto suggestion for email address: Still have a small issue for the multi-resolution icon.
- bug 1013296 - Compose. Change send button to an paper plane icon: Arnau update the patch again that might has less side effect on DSDS device. no update today.
- bug 959011- [MADAI][Dialer] Sending pre-defined message during call reject - Explain the idea from julien and Anthony to partner about the quickReply module and separate html entry.
Today:
- Try to clean(or reduce) the review queue. bug 1026575 and bug 1008127 for the first priority because of v2.0 blocker.
- Land bug 1022644 and create patch for bug 1021513
Oleg
- bug 1008127 - [Messages][Refresh] Subject handling in the Composer
- Tested on device, looks good to me (in review).
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
- Prepared simple patch that doesn't respect Thread.recipients.length when auto-saving draft in the Thread panel and sent for review (in review).
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Tried to reproduce it on today's build (since "getSelf()" patch has been uplifted, https://bugzilla.mozilla.org/show_bug.cgi?id=1026737#c29) and at the first look I don't see issue. Maybe it needs more tries to occur, will check(ya I'm also checking with the patch uplifted, but I have no idea about the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1010690#c106 )
-> Did you try to apply it? You mean the gecko patch? No, I mean call getSelf before our own getSelf (without gecko patch)?No I haven't, and it looks weird to do so :p Yes! :) I know it won't work without gecko patch, I saw it while testing previously, when dispatchNotification is called several times in a row (all previously missed notifications)
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- Reviewed, looks good, r+'d.
Today: will handle review comments for patches in review + going to look into next blocker we have "bug 1022755 - Possible race in the SMS navigation code"
Day 5: 30th June
Steve
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Will verify with latest build with gecko patch bug 1026737 landed(didn't have time to do it last week...)
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- r+, but v1.3t need another implementation. So I'll commit another patch for 1.3t.
- bug 1021513 - [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode
- Landed on master
- bug reviewing:
- bug 974867 - [MMS]Auto suggestion for email address: Conflicts fixed and need another review.
- bug 1013296 - Compose. Change send button to an paper plane icon: Landed.
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app: Some suggestion given, but the patch looks fine
- bug 1008127 - [Messages][Refresh] Subject handling in the Composer: Some feedback given, patch works great but it need to fix the conflicts.
Today:
- Try to clean(or reduce) the review queue. Hope I could have some time for partner's patch...
- Create v1.3t patch for bug 1022644
Julien
Today: Reading up all my mails, and trying to keep up with what happened during my break :)
Oleg
- bug 1008127 - [Messages][Refresh] Subject handling in the Composer
- Updated JS part according to review comments (retrieving subject input line height with "getComputedStyle"). Asked Pavel to update his PR with my latest changes (in review).
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
- Updated patch according to review comments (cleaning up ThreadUI.recipients in "afterLeave" if next view isn't Composer + unit test) (in review).
- bug 1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground
- Cleaned up ni?=me as it's waiting for verification from Spreadtrum QAs. Will look once again if they still have this issue (awaiting QA verification).
- bug 1021513 - [Messages] Recipients list container scroll up automatically when dragging down the container for multiline recipients list mode
- Reviewed, looks good, r+'d (landed).
- bug 1022755 - Possible race in the SMS navigation code
- Still looking into this (can be reproduced without reference workload, I can reproduce it with thread with two MMS if quickly press Back button). Navigation.slide code looks fine to me except of memory leak as we've never unsusbscribed from "transitionend" (tried to unsubscribed on the wrong element), so number of listeners is growing proportionally to number of navigation between panels (in progress).
Other:
- We have two new 2.0 blockers: bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines (awating decision from UX) and bug 1022575 - Received SMS store (without text) on check balance.
Today: will handle review comments for patches in review + investigate bug 1022755
- (Julien) you need a gecko patch before bug 1022755
- (Oleg) What Gecko patch?
- (Julien) sorry, mixed with bug 1022575 (same digits, different positions ;p)
Day 6: 1st July
Steve
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- r+, Land on master and v1.3t. may need uplift to v1.4 manually
- (Julien) don't forget to ask approval, I NI you :)
- r+, Land on master and v1.3t. may need uplift to v1.4 manually
- bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
- Discuss the possible solution with UX
- (Oleg)-> Did you agree on any particular solution? I liked your proposition to disable Enter at all (if I got it correctly) :)
- (Steve) yes, she understood what you said and she will reply on the bugzilla. Disabling all the enter might be the answer
- (Julien) I'd say that if we don't want to allow new lines, "enter" should move to the next input...
- (Steve) well, she did concerned about that (having a button without any function), so switch to message input is still a candidate
- (Julien) ok. But should all this be done in this 2.0+ bug or in a separate bug? Since we want to keep blockers as low as possible, I'd really like that we only get the 1.4 behavior (that we don't need endless discussions to know) and do better things for v2.1 in a separate bug.
- (Oleg) Didn't dig into the code deeply yet, but changing to previous behaviour maybe more risky :)
- (Steve) Since we did a lot of changes for 2.0, I prefer Oleg's thought
- (Julien) my only concern is that it will take more days to know the perfect UX and it's not urgent to have the perfect UX while it's urgent to fix blockers.
- (Steve) I can trace back the behavior in v1.4 and see if it's reasonable to follow the same behavior
- (Julien) ok thanks !
- Discuss the possible solution with UX
- bug reviewing:
- bug 974867 - [MMS]Auto suggestion for email address: Review+, waiting for their commit refined
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app: r+ and landed
- bug 1008127 - [Messages][Refresh] Subject handling in the Composer: r+ and landed
Today:
- One review request from partner.
- Fix blocker(bug 1030160) and triaging other message bugs.
Julien
- Read my mails, did some triage
Others: worked with jgriffin about the changes we need to make to TBPL for bug 874510 (upgrade mocha) Today: will do reviews for partners (MMS by email) and start the DSDS refresh (bug 990537).
Oleg
- bug 1026575 - [B2G][SMS] Message preview in Messages app thread view disappears after opening app
- Landed.
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- Reviewed v1.3t patch (landed).
- bug 1022755 - Possible race in the SMS navigation code
- Found out that Navigation patch didn't regress it, we had this behaviour a while ago (I was able to reproduce it even on v1.4). Navigation patch just made the problem more noticeable (back button doesn't work and content is cleared). The problem I see is that everything is done correctly in JS to navigate to a new panel (at least I've not found a reason yet), but visual transition between panels (I don't mean CSS Transition itself, it can be reproduced even without it) is stuck in the middle (or even in the beginning). "data-position" on wrapper element is correct, but panel that is currently visible is not (if in App Manager you turn off "position:absolute" first for".panel" class and turn on then - everything will become as it should). The problem seems to occur when the time gap between changed data-position class(applied to the wrapper) and appending something to the DOM (like adding new message date group element) is really small. Just an experiment, I made ".messages-date-group" as "inline" element and I can't reproduce issue anymore, if I make it "block" again the issue is reproduced. Can it be related to some kind of interrupted reflow, I don't really know :) ? I need your advise here guys, do you have any ideas?
- (Julien) so it's the same than https://bugzilla.mozilla.org/show_bug.cgi?id=912012 ?
- (Oleg) Sounds similar, but not sure, as navigation events are in the right order, yes we need to somehow stop rendering, requesting and etc. Like Promise.abort() for async operations.
- (Julien) one idea: is do we still use hashes? Maybe because of hashes the "browser" tries to show the element with that id ?
- (Oleg) mm, why then it works if I switch between block<->inline? I'll check your idea with hashes, btw. Thanks!
- (Julien) I don't know for the switch block/inline :) I can also investigate on the issue if you're blocked, just ping me later today if necessary.
- (Oleg) Yep, thanks, if I feel that can't think of any other ideas, I'll ask for your help :) Thanks!
- (Steve) Would that help if we ignore any pointer events while page transition?
- (Julien) could be a good idea, but I'd still like to know the root cause
- (Oleg) But seems that navigation\slide is performed consequently, and not in the middle of each other, and problem still occurs. We also loading message thread asynchronously, when navigation is actually ended we're still appending something to the dom. I'll investigate further and give you more food for thoughts :)
- Found out that Navigation patch didn't regress it, we had this behaviour a while ago (I was able to reproduce it even on v1.4). Navigation patch just made the problem more noticeable (back button doesn't work and content is cleared). The problem I see is that everything is done correctly in JS to navigate to a new panel (at least I've not found a reason yet), but visual transition between panels (I don't mean CSS Transition itself, it can be reproduced even without it) is stuck in the middle (or even in the beginning). "data-position" on wrapper element is correct, but panel that is currently visible is not (if in App Manager you turn off "position:absolute" first for".panel" class and turn on then - everything will become as it should). The problem seems to occur when the time gap between changed data-position class(applied to the wrapper) and appending something to the DOM (like adding new message date group element) is really small. Just an experiment, I made ".messages-date-group" as "inline" element and I can't reproduce issue anymore, if I make it "block" again the issue is reproduced. Can it be related to some kind of interrupted reflow, I don't really know :) ? I need your advise here guys, do you have any ideas?
Today: work on bug 1022755 (race condition while navigating from one panel to another) + pick up some smaller bug just to switch my mind (like localizing MMS label) :)
Day 7: 2nd July
Steve
- bug 1022644 - [Messages] Can't open the recipient panel if there are only 2 lines of recipients
- 1.4 and 2.0 uplift request approved
- bug 1030160 - [Messages][MMS] Subject is considered empty (placeholder is displayed) even if it has several empty lines
- Made a PR for ignoring all the return key
- (Oleg) will you remove CSS hack that we made for subject handling?
- (Steve) I think pavel remove them in the latest subject patch, but I'll f? you to confirm it again, thanks.
- (Oleg) Ok, I'll check
- Made a PR for ignoring all the return key
- bug 1027593 - [SMS] Error displaying long messages
- Start to investigate it today
- (Julien) Note Oleg's investigation below too
- (Steve) Thanks for reminder! Just saw the assignee still empty
- (Oleg) Oh, sorry, anyway will talk to Doug and post result to the bug
- Start to investigate it today
- bug reviewing:
- bug 990537 - [DSDS] Messaging. Apply Visual Refresh to DSDS scenarios: Feedback given but it looks fine overall.
Today:
- Found a bug in subject field: When we are in the middle of the recipient with some suggestion contacts below, clicking the option menu for adding the subject will not wrap the recipient and clear the suggestion list.
- (Julien) File a bug already ? :)
- (Steve) Still editing! It might need to nominate for 1.3t since all the version could reproduce it...
- (Julien) If there is a workaround (clicking elsewhere would then do the right thing) I think it's enough to ask for a blocker on 2.0.
- Fix blocker(bug 1027593) and triaging other message bugs.
Julien
- mainly worked on the DSDS refresh bug 990537
- waiting for ui-review
Today: will do follow-ups for that bug and reviews for blockers and partners. Will also address needinfo, especially the one for the navigation issue.
Oleg
- bug 1022755 - Possible race in the SMS navigation code
- There are not much updates on this, I've posted all investigation results I have to the bug comment and asked Julien for the help with it (in progress).
- Also noticed that if we press Back to quickly when we entered message draft, this draft disappears from the thread list. Looks like another problem but with similar steps.
- bug 1008912 - 'MMS' in sms app doesn't translate into other language
- Prepared patch that uses localized "MMS" label in message composer and thread list panels. Send for review (in review).
- bug 1027593 - [SMS] Error displaying long messages
- Spend some time trying to reproduce it on my Flame to check whether subject handling patch improved\fixed anything related. With subject handling patch I see this error (I'm in doubt if it the same as described in bug) - http://mzl.la/1m7MWEm . Before this patch I can reproduce behaviour from bug description, but if I look closer - it has the same effect, but it's not so noticeable http://mzl.la/1sWoCL6 (look below).
- (Julien) from the screenshot, it looks like a platform issue; like they don't know we scroll and then they render incorrectly
- (Oleg) yes, I'm in doubt that we can break things in this way
- (Julien) maybe needinfo :milan on the bug; or :kats. Or ask advice from Doug because he used to work in this area.
- (Oleg) Ok will talk to Doug first and ask :kats\:milan in case Doug doesn't have ideas.
- (Steve)I also think it should be platform issue, not sure why it's related to bug 1015867
- Spend some time trying to reproduce it on my Flame to check whether subject handling patch improved\fixed anything related. With subject handling patch I see this error (I'm in doubt if it the same as described in bug) - http://mzl.la/1m7MWEm . Before this patch I can reproduce behaviour from bug description, but if I look closer - it has the same effect, but it's not so noticeable http://mzl.la/1sWoCL6 (look below).
Today: will investigate bug 1027593 (error displaying long messages) and try to return to bug 1022755 (race condition while navigating from one panel to another)
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.
- Update PR (unit test part) and reply some thought. The behavior seems not easy to satisfy everyone :p
- 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
- 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.
Today: will finish review of navigation race patch and pick up next blocker.