Confirmed users
820
edits
Gaia/SMS/Scrum/FxOS-S7: Difference between revisions
Jump to navigation
Jump to search
/* Day 5: 14th September
(/* Day 5: 14th September) |
|||
| Line 187: | Line 187: | ||
=== Day 5: 14th September === | === Day 5: 14th September === | ||
====Steve==== | |||
* {{Bug|1179628}} - [Messages][NG] Lay out Settings service structure | |||
** mozMobileConnections shim landed. So the next step is splitting the settings into further: Not sure if we want to move everything into settings service, especially the static value like mms size that only needed for conversation view. Just don't think some static value should be in settings service, but not sure where would be more appropriate(view client seems not "shareable" but it doesn't need to share across all views) :/ | |||
**: (Julien) I'm not sure I follow the "view client not shareable" part of your comment here... | |||
**: (Steve) For example the mms size, we can have a fixed value for conversation for now, but what if we split the new message view in the future. Adding duplicate fixed mms size in new message view client? | |||
**: (Julien) mmsSize needs to come from settings -- some partners change it. | |||
**: (Steve) Okey I missed it, I think we can cache the value in views if we want. | |||
**: (Julien) yeah, the value doesn't change while the app is running. Also not sure this should move to Services for now, but arguable. | |||
* {{Bug|1201016}} - [Messages][NG] Migrate the current Message manager event handling to NGA. | |||
** Patch created for feedback. Also thinking about the duplicate the event fired from different instances. Is that silly if we bind the event name with app instance directly...? Because I think it's still a penalty if we receive all the events and filter in client side. | |||
**: (Oleg) I think we can at least try this option as well, in my WIP I'm becoming a bit worried about growing number of cases where we need this appInstanceId, but don't have better idea right now.... | |||
**: (Steve) It might be a little off the topic: despite current implementation we made, do you think it's a good pattern that developer need to take care about the app instance id for all the service client communication? | |||
**: (Oleg) No, I don't like it, it's quite easy to miss and brings unnecessary complexity, I've tried to solve it in my first WIP with bridge_client mixin, but it's not what I really like... But we need to figure out better solution so that service and client developers care about this much less. | |||
Today: | |||
* Address the feedback in message event handling patch and fix the duplicate event issue. | |||
* Feedback for conversation service. | |||
====Julien==== | |||
I feel like I only did bug creation (from what I've seen during my PTO) and bugzilla bug management... | |||
* I still produced a small patch in {{Bug|1183133}} with Contacts hack, to eliminate the white flash (have a green flash instead), and show David how this was looking. I'll try to move this somewhat forward with an opacity transition like Contacts, but really in background. | |||
* spent some time reading the mails about the low storage feature, had a meeting about it too. We should have an updated spec soon. Ah, just noticed Katie sent it last night: https://mozilla.box.com/s/bfrwwxdaz1o646h8tmmnlq61lv92sy3f | |||
Today: | |||
I want to: | |||
* handle review/feedback/NI queue | |||
* work on the system messages issue | |||
If all this moves forward well, I could: | |||
* continue the prototype caching the thread list to a single db (including contacts/drafts/etc). | |||
====Oleg==== | |||
Will take unexpected day off on Tuesday, so worked on the past weekend instead, and will have planned PTO on Wednesday. | |||
* {{Bug|1176976}} - [Messages][Drafts] Remove the draft saving/replacing action menu | |||
** No progress (in review). | |||
* {{Bug|1198266}} - [Messages] Use ConversationService in the application | |||
** Wasn't able to have numbers comparable with master with nested iframe, but only if all services are in the same window on startup, so worked on another WIP to have services in window on startup and then upgrade ConversationService + MessaginService to SharedWorker and MozMobileMessageShim from window to alwaysLowered window. It's likely not the best way to handle this, but at least it was easy to keep all these upgrades in single-and-easily-switchable ServiceManager (awaiting feedback). | |||
** Unfortunately I was wrong about perf improvement in alwaysLowered window - it just was silently failing due to the lack of right permission, so numbers are still bad :/ Updated perf numbers on the bug and github benchmarking app. | |||
** Found bug in alwaysLowered window that prevents me from testing WIP on device "{{Bug|1204299}} - [System] alwaysLowered window steals focus from the main application window". | |||
** Just some observation: alwaysLowered window is bound to the particular app instance (they are placed in the same parent node from the System app POV), so once instance is closed alwaysLowered window is closed as well. So even that e.g. activity instance has access to alwaysLowered window created by main instance (via window.open with window name and empty URL) we can't really use it as it will disappear once main instance is closed. So that's why I still use appInstanceId trick. | |||
**: (Julien) maybe a silly question: if we use the command "window.open('...', 'name')", it will create the window if not existing, and otherwise return it, right? And all mozAPI shims are stateless. So do we really need the appinstanceID ? | |||
**: (Oleg) Yes, it will re-create window if you set URL, if not it will create window with empty URL. What did you mean by '...' - is it empty string or actual URL? The main problem is that this window can die, while SharedWorker service connected to it - will not, that will break connection. | |||
**: (Julien) you can always use the actual URL. | |||
**: (Oleg) But this will re-create window once again or I missing something? At least this is what I've seen. The only way to get the same reference is to omit URL and provide "window name" only. And this is what mentioned in mdn for window.open | |||
**: (Julien) Mmm yeah that's right. (note this should not recreate window but reload the URL in the same window -- but for us it's the same issue) | |||
**: (Oleg) If I remember correctly System app re-created it - since the id of the window had changed. Ah about Desktop - yeah maybe - haven't tried :) | |||
**: (Julien) yeah but on Desktop that's not happening, I think... so maybe there is an issue in the System app here. (but for us we don't want to reload the page anyway). - right. | |||
**: (Julien) and is it possible to first request the window, know that it does not exist, and open another one? Or maybe that's what you're doing already ? | |||
**: (Oleg) If I call window.open('', 'window_name') and window hasn't been created - we'll have new window created with empty URL I think - not null - but need to double check. So I use sessionStorage currently to understand if this window has been created..... Don't have better idea right now. And activity instance has it's own "session" so they are separated. | |||
**: (Julien) OK; it doesn't feel we have the right tools... | |||
**: (Oleg) Yep, and alwaysLowered is just temp workaround due to absence of SW, openWindow and etc.... So we're doing gaia workarounds for Gecko/System workarounds :) | |||
** Also confirmed that both SharedWorker and alwaysLowered window stays alive (and communication between them! :)) when we navigate from one document to another in a split view mode (and when refresh page with f5 as well), checked only Fx Desktop (needs some fix in our desktop mock shims though), but not on a device due the issue above. | |||
Other: | |||
* Left feedback for "{{Bug|1201016}} - [Messages][NG] Migrate the current Message manager event handling to NGA". | |||
Today: | |||
* Will handle review/feedback/need-info requests; | |||
* Will work on review comments and assigned bugs. | |||
=== Day 6: 15h September === | === Day 6: 15h September === | ||
=== Day 7: 16th September === | === Day 7: 16th September === | ||