Gaia/SMS/Scrum/FxOS-S7

List of bugs

SMS issues handled by the SMS subteam (blocks the sprint bug 1202956)

Bugzilla link

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature-b2g	Whiteboard	Resolution
818000	Julien Wajsberg [:julienw]	system messages are ignored if the handler pathname is not the same as the foreground application pathname	---	No cf_feature-b2g	[sms-sprint FxOS-S7 p=3][sms-sprint FxOS-S6 p=2][sms-sprint FxOS-S5 p=3]	WONTFIX
1180592	Steve Chung [:steveck]	[Messages][NG] mozMobileConnections shim Implementation	---	No cf_feature-b2g	[sms-sprint FxOS-S7 p=1][sms-sprint FxOS-S6 p=2]	FIXED
1198266		[Messages] Use ConversationService in the application	---	No cf_feature-b2g	[sms-sprint FxOS-S8 p=1][sms-sprint FxOS-S7 p=3][sms-sprint FxOS-S6 p=2]	WONTFIX
1201016		[Messages][NG] Migrate the current Message manager event handling to NGA	---	No cf_feature-b2g	[sms-sprint FxOS-S8 p=1][sms-sprint FxOS-S7 p=1]	WONTFIX

4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Remaining points and burndown chart

google chart api url for Sprint FxOS-S7

Burndown chart

	Remaining points
Start	8
Day 2	8
Day 3	7
Day 4	7
Day 5	7
Day 6
Day 7
Day 8
Day 9
Day 10
End

SMS issues handled by the SMS subteam outside of the sprint (contains whiteboard "sms-sprint-FxOS-S7")

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

All SMS issues tracked for this sprint (target milestone)

Bugzilla link

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature b2g	Resolution
1184012	Stéphane Roucheray	[Messages] Throttle event handlers for the "input" event handlers	---	---	FIXED
1202956		SMS sprint FxOS-S7	---	---	INCOMPLETE

2 Total; 2 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 9th September

Steve

• bug 1179628 - [Messages][NG] Lay out Settings service structure
  • Start mozMobileConnections.
• bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation
  • In review.
• bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
  • Have some discussion with Oleg about the possible layout for client.
• Reply some bugs that related to message app.

Today:

• Start some layout for message event handling.
• Clean up the review

Oleg

• bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
  • No progress (in review).
• bug 1198266 - [Messages] Use ConversationService in the application
  • Trying updated bridge, couldn't make window-iframe communication work, looking into (in progress).
  • More profilings, had to build b2g by myself to get more info about setupShadowRoots, but results are controversial - data is different between runs, trying to understand what is going on.

Other:

• Started to look into "bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation.";
• Finished reading my bugmail.

Today:

• Will handle review/feedback/need-info requests;
• Will work on review comments and assigned bugs.

Julien

• In PTO

Day 3: 10th September

Steve

• bug 1179628 - [Messages][NG] Lay out Settings service structure
  • Start mozMobileConnections.
• bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation
  • r+ and waiting for green signal.
• bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
  • Working on the message clone first, maybe I will give a general clone for message since there is sms/mms for DOMMessage. In this way I might need to create a shim utils for clone method. Not sure if other shim will need clone(seems not except the DOMError).

(Oleg) Yeah, presumably only mozMobileMessageShim will need clone, btw do we have any updates on DOMError handling (in bridge I mean)?

(Steve) No from bridge as far as I know :/ But I don't want to push Wilson too much on this since there's lot of task waiting for him.

(Oleg) Heh, yeah, not that critical for us right now. He was also asking me about any news on gaia-fast-list, not sure if he reached out to you cause I don't know anything about it :)

(Steve) Oh I didn't catch up with the latest fast-list yet because the library changes frequently :p

(Oleg) Ah, okay, we can wait for more stabilized version first then.

(Steve) Yeah that's what I thought, I already tried out 2 different version of the fast-list, but maybe it's time to involve again after few weeks.

(Oleg) Okay, got it, thanks for the update! Maybe we can plan it for the next sprint.

• Clean up the review queue.

Today:

• Start some layout for message event handling.

Oleg

• bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
  • No progress (in review).
• bug 1198266 - [Messages] Use ConversationService in the application
  • Created reduced test case and filed github issue for the problem I was facing: https://github.com/gaia-components/bridge/issues/83.
  • My WIP with auto switch to SharedWorker/alwaysLowered based services is moving forward (in progress).

    (Steve) Just discussed this with other folks yesterday, we thought that the service should be flexible for user to choose/switch between window/worker thread, not just service -> worker concept. So user can designate different context to init and switch the service context between both context seamlessly. Anyway we thought is good change if we can try out different combination.

    (Oleg) Yeah, it's kind of Manager that existed in the early bridge days, that can transparently change contexts/threads :)

  • Tried new bridge with sync window-to-window messaging - works quite well from the first look, at least faster than MessageChannel.
  • Was stuck with Gecko profiler that missed gaia-header related information, asked help from Ting-Yu, got reply - need to try again. Will file a bug to somehow lazy load gaia-headers in the meantime.

Other:

• Reviewed "bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation.";
• Attended late NGA meeting on behalf of Julien.

Today:

• Will handle review/feedback/need-info requests;
• Will work on review comments and assigned bugs.

Julien

• In PTO

Day 4: 11th September

Steve

• There's a addon hackathon here, I didn't join the entire event but will still be a passer-by and voting for the result.
• bug 1179628 - [Messages][NG] Lay out Settings service structure
  • Start mozMobileConnections.
• bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation
  • Landed.

    (Julien) I was so happy when I saw this bugmail :)

• bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
  • Have a quick patch about the message clong and message relay between different context. Still fighting with the init race condition and thinking about if it's possible that message missing while initializing the bridge and connection.

Today:

• Start some layout for message event handling.
• Feedback for conversation service.

Julien

• Just read/handled my bugmail and some of the other mails yesterday

Today: I want to:

• finish handling some more complicated bugmails and mails (eg: low storage stuff)
• 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

• bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
  • No progress (in review).
• bug 1198266 - [Messages] Use ConversationService in the application
  • Created WIP-for-your-feedback with ConversationService in window context with ability to upgrade to SharedWorker context (awaiting feedback).
  • Tried to leverage new sync bridge behaviour (window->window, window->iframe via dispatchEvent), but we have a race here - if client is created before service starts listening there is no connection is established, it doesn't happen with BC - will talk to Wilson if it's expected, if yes - we'll need to initialize window clients (that uses iframe service) once service is initialized. We don't have such cases yet, but I have one in my WIP patch.

    (Julien) Note that having a sync behavior kind of defeats the purpose of services; but if we use it only for the initial loading I think it's ok.

    (Oleg) Yep, I'd like to use for startup only and then upgrade to better "channel".

  • Retested alwaysLowered window and noticed significant improvement - we spend ~200-300 ms less to create that window - so filed a bug where we can seriously consider switching to it.

    (Julien) good, this is less a headache for us :) Do we know if it's automatically closing when the app's last window is closing?

    (Oleg) IIRC, yes, but we need more concrete/definite answer from Francisco or System app guys :)

    (Julien) OK; we'll also need to check how this behaves regarding the task manager.

  • Ting-Yu's advice with -e parameter helped to get more detailed profile.

Other:

• Filed bug for possible better handling of gaia-header;

Today:

• Will handle review/feedback/need-info requests;
• Will work on review comments and assigned bugs.

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.