Confirmed users
383
edits
Gaia/SMS/Scrum/2.2S4: Difference between revisions
m
→Day 5: 13th January
| Line 303: | Line 303: | ||
=== Day 5: 13th January === | === 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 ;) | |||
* {{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 :) | |||
* {{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 | |||
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 | |||
=== Day 6: 14th January === | === Day 6: 14th January === | ||
=== Day 8: 15th January === | === Day 8: 15th January === | ||