List of bugs
SMS issues handled by the SMS subteam (blocks the sprint bug 1118192)
| ID | Assigned to | Summary | Blocking b2g | Feature-b2g | Whiteboard | Resolution |
|---|---|---|---|---|---|---|
| 1087329 | [messages] More perf improvements | --- | No cf_feature-b2g | [p(2.2S5)=1][p(2.2S4)=1] | WONTFIX | |
| 1087981 | Julien Wajsberg [:julienw] | [Message] Lazy init settings in notify.js | 2.2+ | No cf_feature-b2g | [p=1] | FIXED |
| 1089154 | Steve Chung [:steveck] | [Messages] investigate scoping CSS rules | 2.2+ | No cf_feature-b2g | [p(2.2S5)=1][p(2.2S4)=1] | FIXED |
| 1116780 | Oleg Zasypkin [:azasypkin] | [Messages] We should not focus the composer after clicking a notification | 2.2+ | No cf_feature-b2g | [p=1] | FIXED |
| 1118214 | [Messages] Investigate how we can make shared/js/date_time_helper.js more performant at executing time | --- | No cf_feature-b2g | [p=2] | WONTFIX | |
| 1118215 | Steve Chung [:steveck] | [Messages] ThreadUI.init takes too much time | --- | No cf_feature-b2g | [p=1] | FIXED |
6 Total; 6 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Remaining points and burndown chart
google chart api url for Sprint 2.2S4
| Remaining points | |
|---|---|
| Start | 7 |
| Day 2 | 7 |
| Day 3 | 7 |
| Day 4 | 7 |
| Day 5 | 7 |
| Day 6 | |
| Day 7 | |
| Day 8 | |
| Day 9 | |
| Day 10 | |
| Day 11 | |
| Day 12 | |
| Day 13 | |
| Day 14 | |
| Day 15 | |
| End |
SMS issues handled by the SMS subteam outside of the sprint (contains whiteboard "sms-sprint-2.2S4")
| ID | Assigned to | Summary | Blocking b2g | Feature-b2g | Whiteboard | Resolution |
|---|---|---|---|---|---|---|
| 988269 | Oleg Zasypkin [:azasypkin] | [Messages][Refactoring] Investigate whether ActivityHandler.isLocked is still required (follow up from bug 936729) | --- | No cf_feature-b2g | [sms-sprint-2.2S4] | FIXED |
| 1091441 | Steve Chung [:steveck] | [Messages] the thread view is flashing while loading if there are MMS | --- | No cf_feature-b2g | [sms-most-wanted][lang=js][p=2][sms-sprint-2.2S4] | FIXED |
| 1091511 | Steve Chung [:steveck] | [Flame][v2.1][Message]The number/email or URL can't be tapped if there is full-width text in this message. | 2.1+ | No cf_feature-b2g | [sms-most-wanted][lang=js][sms-sprint-2.2S4] | FIXED |
| 1118963 | Steve Chung [:steveck] | [Messages][SMS] Keyboard Lingers in thread list after Group Message, breaks UI when used | 2.2+ | No cf_feature-b2g | [2.2-Daily-Testing][sms-sprint-2.2S4] | FIXED |
| 1119013 | Oleg Zasypkin [:azasypkin] | [Messages][Subject] Focus is not given to the subject area of a message when adding a subject to the message | 2.2+ | No cf_feature-b2g | [2.2-Daily-Testing][sms-sprint-2.2S4] | FIXED |
5 Total; 5 Open (100%); 0 Resolved (0%); 0 Verified (0%);
All SMS issues tracked for this sprint (target milestone)
11 Total; 11 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Sprint planning
Minutes are on a separate page.
Daily meetings
Day 2: 7th January
Steve
- bug 1084298 - [Messages] Decoupling the all inputs query logic from DOM tree structure
- Not much progress on this.
- bug 1091441 - [Messages] the thread view is flashing while loading if there are MMS
- TaskRunner works good as well(although it might a little slower then promise all), so threadui tests needs to be revised based on promise base now.
- bug 1089154 - [Messages] investigate scoping CSS rules
- Start to replace the pseudo classes and investigate the overall performance after replacing them.
- Just a note to remind myself to ask QA Eric to create integration test from moztrap, since he is not in office this week.
Today:
- Message view flashing patch refine.
Julien
- bug 1089920: fix gaia-header performance
- discussed a lot with Wilson about this, especially about how to keep attribute values in a local object, but couldn't finish it yet.
- bug 1082618: add a README file
- Chris Mills made a corrected copy and gave some comments so I'll try to address them and lad it.
- did a simple pach + cleanup in bug 1113002 (reported by woodduck)
- waiting for approval
- bug 1116780: regression: we should not focus the composer when clicking a notification
- removed as assignee so that one of you can take it
Others:
- usual sprint planning stuff
- ideation group stuff
Today:
- will move forward some background matters (organize group MMS bugs, and drafts handling issues started some weeks ago)
- will move forward on gaia header bug
- land the README file ? :)
Oleg
- bug 1116101 - [FFOS2.0][Woodduck][HZ][FT] Unable to receive Class 0 SMS when SMS is empty
- All agreed to display empty class-0 message, I think device team can easily handle that, will ask Josh for help.
- bug 1105548 - [Messages] Notifications for messages will still be present when a message is received while in the message thread opened from contacts
- While waiting for ni? from :fabrice, asked your non-urgent feedback on the idea in general (awaiting ni and feedback).
- bug 1118214 - [Messages] Investigate how we can make shared/js/date_time_helper.js more performant at executing time
- Started investigating this thing and some other related stuff, here are some results:
- Lazy loading data_time helper right before first usage looks ugly, will see how much time it will take if I cache navigator.mozHour12 in local or async storage. Almost all time (30 ms on flame for processing this file) 25-26ms is spent on mozSettings.createLock().get() to get initial value.
- "navigator.mozContacts.addEventListener" in ThreadListUI.init takes about 18ms if I measured it correctly :) Looks like we can add this listener later, after first page rendered.
- I noticed that we have default Gecko read ahead pref equals to 7 (http://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MobileMessageDB.jsm#69) that is why I see that when we load the last thread in the first page we spent ~200ms only to retrieve it, while just a few ms or even less to retrieve prev threads. If I decrease firstPanelCount just from 9 to 8 - I see much improvement, but if I change it to even 15 I don't see much regression because of read ahead thing :) Btw on Flame only 8 thread in the first page.
- (Julien) I suspect there is a memory impact on changing this too, but why not, good idea :)
- (Julien) "much improvement" what do you mean?
- (Oleg) I used make test-perf, 30 runs (2 times each), with and without change, 1552 -> 1358 on engineering build for moz-visual-complete.
- (Julien) ah yeah, I see what you mean; do you think we can ask Bevis to increase the read ahead pref to 9 or 10 ? Another idea is to make the API fetch more in background ahead of time when we consumed all but 1 or 2.
- (Oleg) The strange thing that I tried to change it manually and nothing changed, maybe I changed pref incorrectly :( Used Julien's addpref tool that always works as expected
- (Steve) I think we could adjust the value by ourself, but we had better confirm with him
- (Julien) re: addpref tool, depends on where the pref is stored, but it should work :/ yeah we can ask Bevis to have his insight.
- (Oleg) yep, let's ask, also unrelated, tried "setContact(node) -> setTimeout(() => this.setContact(node))", it shaved just ~6ms for every thread, not much improvement.
- (Julien) looks like it can be overriden by settings: http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/settings.js#548 and so it could be set by the SMS app :) (except we'd need to call mozSettings, which is costly :p)
- (Steve) yes, it should be be changeable from settings
- (Oleg) tried both "ril.sms.maxReadAheadEntries and dom.sms.maxReadAheadEntries", but it's better to check with anyone else :)
- (Julien) we can follow-up on IRC yep
- Started investigating this thing and some other related stuff, here are some results:
Other:
- Advised 3 workarounds for the "bug 1112959 - [FFOS2.0][Woodduck][SMS]The message list isn't refresh after save a draft in other".
Today:
- Will handle review/feedback/need-info requests; Steve's patch is the first.
- Will work on review comments and assigned bugs
Day 3: 8th January
Steve
- bug 1091441 - [Messages] the thread view is flashing while loading if there are MMS
- TaskRunner version patch with unit test changes complete, asking for another review(sorry Oleg :(, I still choose the taskRunner solution in the end)
- bug 1089154 - [Messages] investigate scoping CSS rules
- Removed some pseudo classes in the thread list view first. Will test the performance later.
Julien
Not much progress on anything yesterday, ideation group took a lot of time + couldn't really focus after what happened in Paris.
- (Oleg) yeah :( Hope everything is more or less fine right now
- (Julien) I'll be able to focus :) will see what happens here..
- bug 1089920: fix gaia-header performance
- didn't move yesterday
- bug 1082618: add a README file
- not much progress
- did a simple pach + cleanup in bug 1113002 (reported by woodduck)
- got approval, will land soon on 2.1 (need to test on a device first :) )
Others:
- ideation group stuff
- bug 1115224: some issues around gaia-header auto-resize in Settings
- bug 1118829: unit testing and app:// broken in Firefox. (we'll move to Mulet, but this should be planned and expected, not a side-effetct of a patch)
Today:
- will move forward some background matters (organize group MMS bugs, and drafts handling issues started some weeks ago)
- will move forward on gaia header bug
- land the README file
Oleg
- bug 1116101 - [FFOS2.0][Woodduck][HZ][FT] Unable to receive Class 0 SMS when SMS is empty
- Luke is helping on this, will answer to his concern regarding to proposed fix today (in progress)
- (Julien) I answered too ;)
- (Oleg) Ah, thanks!
- Luke is helping on this, will answer to his concern regarding to proposed fix today (in progress)
- bug 1118214 - [Messages] Investigate how we can make shared/js/date_time_helper.js more performant at executing time
- Prepared two WIPs, one with lazy load date_time_helper on deman + local-storage cache to display date with previous format and second one with lazy load only. Will post it to the bug. Currently numbers aren't impressing at all. Maybe if start lazy load only after first page is loaded then we'll have improvement. Will comment about that with numbers in a few minutes (in progress)
Other:
- Left feedback for mms flickering patch.
Today:
- Will experiment with read ahead pref using Julien's hint with omni.ja;
- Will handle review/feedback/need-info requests;
- Will work on review comments and assigned bugs
Day 4: 9th January
Steve
- bug 1091441 - [Messages] the thread view is flashing while loading if there are MMS
- Patch given with some feedbacks return, stil updating to move queue into local
- bug 1089154 - [Messages] investigate scoping CSS rules
- The overall performance didn't improve much after removing the classes (Only ~10ms less, maybe it's only 18 selectors removed and there is still more in shared BB). Will find a buri for more testing.
- (Julien) 10ms is not that bad, but maybe not worth it now given the risk. You can continue look if we have some in BB :)
- (Steve) So we can just refine BB if the selector do affect the performance? or other method to avoid them instead of modify BB styling directly
- (Julien) if we find something in BB that _really_ affects performance, I think it's better to modify BB because this can affect all apps. But it's a lot of work, so it needs to be worth it...
- (Steve) I see... Because 10ms seems not a persuasive number :p
- (Julien) yep; Vivien would tell that 10 + 10 + 10... :) but I think it depends on the complexity of the change, so clearly I wouldn't want to change BB and all apps for 10ms, 1 day before branching :p
- (Steve) ok
- The overall performance didn't improve much after removing the classes (Only ~10ms less, maybe it's only 18 selectors removed and there is still more in shared BB). Will find a buri for more testing.
bug 1118154 - [FFOS7715 v2.1] [dolphin] FFOS can not receive Cell Broadcast messages on SIM2
- Patch given for reporter to test.
Today:
- Keep profiling the result after removing all the pseudo classes on buri
- Refine the flashing patch.
- Half-day PTO this afternoon
Julien
- bug 1089920: fix gaia-header performance
- fixed most issues + wrote unit tests
- there is a regression in the "automatic" behavior, I need to check why. Likely a small issue.
- bug 1082618: add a README file
- not much progress
- did a simple pach + cleanup in bug 1113002 (reported by woodduck)
- landed
Others:
- bug 1118829: unit testing and app:// broken in Firefox. landed.
Today:
- will review Oleg's patches
- will move forward some background matters (organize group MMS bugs, and drafts handling issues started some weeks ago)
- will move forward on gaia header bug
- try to land the README file
Oleg
- bug 1116101 - [FFOS2.0][Woodduck][HZ][FT] Unable to receive Class 0 SMS when SMS is empty
- Luke prepared master and v2.0m patches, r+'ed (landed).
- bug 1118214 - [Messages] Investigate how we can make shared/js/date_time_helper.js more performant at executing time
- Measured both WIPs (2x30 runs of make-test perf on light workload), commented about that on the bug (awaiting feedback).
- bug 1087329 - [messages] More perf improvements
- Played with read ahead setting (via modifying settings.js inside omni.ja). Changed it from 7 to 8 and did tests (2x30, light workload, engineering build) - [1466, 1387], avg. 1426, with the patch from bug above (with localstorage one) = [1293, 1387], avg. 1340. For clean master numbers are [1565.8, 1567.9], avg. 1566.8. But had a hard time yesterday when was running make test-perf approx. 8 of 10 times failed with "too much recursion" error in the log, so now I can't trust the numbers :)
- ni'ed Bevis to get more insights about read ahead pref.
- (Julien) use "median" value instead of "average". We need to have this reported automatically (I should file a bug :) ) but in the mean time try to calculate yourself. I used http://mathjs.org/ in jsbin so that I could use test-perf's output.
- (Oleg) Okay, will do, thanks!
- (Julien) how do you explain that it's "moving to 8" that works fine, and not "moving to 9", given that we want to display 9 threads?
- (Oleg) Light workload contains only 8 for the first screen :) I'm not really sure when it reads "ahead", read first -> return and in the meantime read 7 or read seven and only then returns first
- (Julien) so you changed the "threads in first panel" to 8 in thread_ui.js? Trying to understand how you got your numbers.
- (Oleg) Nope, only changed setting from 7 to 8
- (Julien) ok, I'll look at your patches first and then we can discuss on IRC :)
- (Oleg) yep
Other:
- Reviewed Luke's small patch about class-0 messages without body;
- Reviewed Salva's patch about email via mms;
Today:
- Will handle review/feedback/need-info requests;
- Will work on review comments and assigned bugs
Day 5: 12th January
Steve
- bug 1091441 - [Messages] the thread view is flashing while loading if there are MMS
- New patch given with local taskRunner and some other mms parsing promise refinement.
- bug 1089154 - [Messages] investigate scoping CSS rules
- Some problem while flashing buri with fake DBs. At the mean time I'll also work on share BB class removal.
- (Julien) do you have an error "ActorParent" and the phone does not boot correctly?
- (Steve) I didn't get any error after phone reboot, but the workload just doesn't work(script does run to the end without any error).
- (Julien) ah ok; try to look if it writes to /data/local/storage/persistent or /data/local/storage/permanent; it should be the latter on newer versions of phones (and I think the script on master writes in this directory too... but can still detect earlier phones).
- (Steve) Yes, I'm trying to figure out this part as well. Thanks!
- Some problem while flashing buri with fake DBs. At the mean time I'll also work on share BB class removal.
- bug 1118154 - [FFOS7715 v2.1] [dolphin] FFOS can not receive Cell Broadcast messages on SIM2
- Seems some problem from partner's modem. CB message was sent from wrong modem so it need partner support anyway.
- bug 1118215 - [Messages] ThreadUI.init takes too much time
- Start to investigate the root cause from init.
Today:
- Keep profiling the result after removing all the pseudo classes on buri
- ThreadUI init profiling.
Julien
- bug 1089920: fix gaia-header performance
- The regression was only because I had a gecko without bug 1102502, my code works fine with a recent gecko
- discussed a lot with Wilson, he forked my patch thursday and as a result we can't directly merge my changes in his patch. He took my unit test work though and will finish the patch.
- bug 1082618: add a README file
- not much progress
Others:
- Contributed an ideation result on slack: enhanced task manager.
Today (yeah, really): :)
- will review Oleg's patches
- will move forward some background matters (organize group MMS bugs, and drafts handling issues started some weeks ago)
- try to land the README file
Oleg
- bug 1112539 - [Messages] Number-only contact details are broken in remove recipient confirmation dialog
- Finally got r+ from Arnau, rebased and landed (landed).
- bug 1116780 - [Messages] We should not focus the composer after clicking a notification
- Picked it up from Julien's patch, was thinking about possible use cases where current WIP works and doesn't, the only thing is if app is run as "new" number-less inline activity, discussed and confirmed that case with Julien. Today will see if I can handle this case in this patch or file follow up (in progress).
- bug 1087329 - [messages] More perf improvements
- Today got response from Bevis, haven't read yet :) But looks like we can increase default value for read ahead property without much penalty, it would be great if someone else except me can check that improves moz-visual-complete time.
- (Julien) I may have the time tomorrow (not today for sure)
- (Oleg) cool thanks! I don't trust myself on that matters :)
- Today got response from Bevis, haven't read yet :) But looks like we can increase default value for read ahead property without much penalty, it would be great if someone else except me can check that improves moz-visual-complete time.
Other:
- Reviewed Salva's patch that enables MMS-via-Email - haven't noticed any problems so far, will presumably r+ today;
- Provided patch for small (in terms of fix) Browser and tv_apps regression caused by my BB changes in "dialog-alert" patch "bug 1116736 - [Flame][Browser]The "Try again" button is covered and device only shows a little bit blue icon in the lower right corner."
- ideation group: recorded small demo (with a shitty quality :)) for SMS in browser connected to phone on the same network, just in case you're curious: https://www.youtube.com/watch?v=WTqaJRgn_rc&vq=hd1080
Today:
- Will handle review/feedback/need-info requests; Steve's patch is in priority.
- Will work on review comments and assigned bugs
Rishav
- bug 829820
- under review(steve)
Today
- bug 1113480 - [Mesage] Refine the file size unit in file too large dialog
- WIP
Day 5: 13th January
Steve
- bug 1091441 - [Messages] the thread view is flashing while loading if there are MMS
- Some new feedback from Oleg, will fix and reply today.
- bug 1089154 - [Messages] investigate scoping CSS rules
- More profiling result for buri and pseudo classes removal in shared BB. It's sad that only remove these classes in message seems have no improvement on buri, but removal for both message and BB could work for both devices(but not much, ~70m on flame and ~30ms on buri)
- (Julien) means that maybe if we remove only those in BB you'd have the same improvement ?
- (Steve) probably, but it's weird that it could reduce more on flame. Maybe it's because of my test round is limited (only ~10 times profiling for average time, the the value varies a lot on buri)
- (Julien) yep, I used 50 when I tested... "median" does not change much with 50, but "average" still changes a lot. BTW just filed bug 1120828 so that test-perf gives median information too, if you want you can fix it so that it's easier to measure for you ;)
- More profiling result for buri and pseudo classes removal in shared BB. It's sad that only remove these classes in message seems have no improvement on buri, but removal for both message and BB could work for both devices(but not much, ~70m on flame and ~30ms on buri)
- bug 1118215 - [Messages] ThreadUI.init takes too much time
- Some result about profiling. Compose.init does consumed some time(5ms) but Recipient init took more (~15 ms) And for deeper investigation the spent time would mainly on Recipient.View private set setup (~6ms) and reset().focus() (~5ms) . Will go deeper and profile on buri as well.
Today:
- Keep profiling the result after removing all the pseudo classes on buri
- ThreadUI init profiling.
Julien
- bug 1089920: fix gaia-header performance
- Wilson asked me review, will review today
- bug 1082618: add a README file
- not much progress
- started looking at Oleg's patch about the mozHour12 helper. Not sure about the added complexity yet, and I haven't tried on device either yet.
- (Oleg) Yep, I don't really want to introduce such complex solution for such small win, maybe you'll have better idea.
- (Julien) my plan for today is to look at mozSettings API and maybe discuss with people responsible for it; maybe we should not have such a penalty when merely accessing it. We should have it only between "get" and the result.
Others:
- Spent the day in ideation group
Today: I want to:
- review Oleg's patches
- investigate if read-ahead value changes something in SMS
- review the gaia-header patch
- move forward some background matters (organize group MMS bugs, and drafts handling issues started some weeks ago)
- land the README file
Oleg
- bug 1116736 - [Flame][Browser]The "Try again" button is covered and device only shows a little bit blue icon in the lower right corner. (regression from alert-dialog patch)
- Got r+, landed (landed).
- (Julien) do you know if it's easy to find similar cases in whole Gaia?
- (Oleg) Don't know any simple way, otherwise I found that earlier :)
- Got r+, landed (landed).
- bug 1116780 - [Messages] We should not focus the composer after clicking a notification
- Not much progress on this since yesterday (in progress).
- bug 1087329 - [messages] More perf improvements
- Trying to see if it's possible to dynamically set read ahead setting via mozSettings (in progress).
- (Julien) I'd really want to remove this possibility instead :/ this is useless and messy.
- (Oleg) I'm not really understand how such config values (that depend on device characteristics) are set for different devices? Is it done by operators or ...?
- (Julien) I think it's not set. I don't really understand what was behind this. Or maybe this is in the customization? see customization/settings.json.
- (Oleg) So currently nobody uses it (except for the default value), we need to make use of it :)
- (Julien) operator can have customization files that you don't know :)
- (Oleg) But do operators know about that setting at all? It seems quite important thing to customize.
- (Julien) I don't know, probably not :p examples in https://github.com/telefonicaid/firefoxos-gaia-latam https://github.com/telefonicaid/firefoxos-gaia-spain but that's old ones
- (Oleg) Sooo what do you prefer to do with it?
- (Julien) Have a more sensible default for a start ;) And then discuss with devices team, but I don't know who's main point of contact?
- (Oleg) Okay, can you, when you have time, just to make sure that you see difference too when default value is increased. Then I think we can proceed + I think we can ping Josh or Evelyn to make device team aware of it.
- (Julien) yep I'll do this today
- (Steve) The things I worried is it didn't improve loading time actually, it just help to provide a more accurate profiling result for 1st view ready, so it's hard to push them or even operator to customize by them-self
- (Oleg) + show first page of threads earlier to the user, or I again messed it with ThreadUI :)
- (Steve) Ya, it can improve to lazyloade earlier, but not much for user visualization
- (Oleg) Agree, it's more about statistics
- (Julien) from what I understand, if we need more than 7 threads to be displayed in first panel, then we have a penalty for last one. I agree we need to look at what happens in real life.
- (Steve) +1 that adjust the value manually first to see if it did improve something
- Trying to see if it's possible to dynamically set read ahead setting via mozSettings (in progress).
Other:
- Made a final review of Reviewed Salva's patch, r+'ed (landed);
- Almost reviewed Steve's mms-flashing patch, will finish today, everything is good, just small nits in unit tests.
- Mostly ideation stuff yesterday.
Today:
- Will handle review/feedback/need-info requests;
- Will work on review comments and assigned bugs