Confirmed users
383
edits
Gaia/SMS/Scrum/4: Difference between revisions
→Daily meetings
| Line 220: | Line 220: | ||
===Day 6: 1st July=== | ===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 :) | |||
* {{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 ! | |||
* 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 :) | |||
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=== | ===Day 7: 2nd July=== | ||
===Day 8: 3rd July=== | ===Day 8: 3rd July=== | ||