Closed Bug 1015388 Opened 5 years ago Closed 5 years ago

[Contacts] Implement new startup loading events

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S6 (18july)
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: Eli, Assigned: arcturus)

References

Details

(Keywords: perf, Whiteboard: [c=automation p= s=2014.07.18.t u=] [p=4])

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #837668 +++

We need to measure when the app is usable by the user. For that we'll need to send an event (the moment is specific to the app) to |window| that the performance test will be able to receive.

The events for implementation are outlined in bug 996038.
Bug 996038 introduces new events outlining the phases of application startup. Each of these 5 events needs to be implemented.
Summary: [Contacts] "ready to use" perf measurement → [Contacts] Implement new startup loading events
As an FYI, this implementation needs to land in 2.0 as it is important for meeting release performance acceptance criteria.

https://wiki.mozilla.org/FirefoxOS/Performance/Release_Acceptance
Hi Eli,

have some doubts about when to launch the events cause of the nature of the contact app.

As we load the list content dynamically, but we allow the user to interact before this list is done, even the first contact is displayed, should we launch mo-content-interactive when the user is ready to interact with the frame (add contact and settings) or when the very first contact is displayed in the list?
Flags: needinfo?(eperelman)
Assignee: nobody → francisco
From looking at the Contacts app, Add Contact and Settings are elements that exist within the chrome of the application. That means when these elements are ready to be interacted with, you will trigger 'moz-chrome-interactive'.

I would consider the Contact list to be the core interaction of the application, and so once the user is able to start interacting with the list (regardless of whether there are any contacts in the list or not), then you should trigger 'moz-content-interactive'.

Does that make sense?
Flags: needinfo?(eperelman)
Definitely, makes sense since the interaction with the list is key,  so we will fire the event when we draw the first screen with contacts.

This list is really tricky since it doesn't load completely, but the user can interact at the very moment we display the first batch of contacts.
Whiteboard: [c=automation p= s= u=] → [c=automation p= s= u=] [p=4]
Target Milestone: --- → 2.0 S6 (18july)
Attached file Pointer to PR 21453
Attachment #8451677 - Flags: review?(jmcf)
Attachment #8451677 - Flags: feedback?(eperelman)
Comment on attachment 8451677 [details] [review]
Pointer to PR 21453

Need to add the app to the whitelist at [1].

[1] https://github.com/mozilla-b2g/gaia/blob/master/tests/performance/startup_events_test.js#L24
Attachment #8451677 - Flags: feedback?(eperelman) → feedback-
(In reply to Eli Perelman, :Eli from comment #7)
> Comment on attachment 8451677 [details] [review]
> Pointer to PR 21453
> 
> Need to add the app to the whitelist at [1].
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/master/tests/performance/
> startup_events_test.js#L24

Thanks for that, I read it but forgot to add to the PR.

Also here is a summary of the events used with this PR:

- moz-chrome-dom-loaded fired when we receive the 'load' event in index.html
- moz-chrome-interactive fired when setup the listeners on the first elements on the screen: search, add contact and settings
- moz-app-visually-complete fired when we remove the class 'hide' fromt he body
- moz-content-interactive when the first batch of contacts is rendered
- moz-app-loaded just after we fired the moz-content-interactive since the contacts will be loading, but the app is totally usable.
Comment on attachment 8451677 [details] [review]
Pointer to PR 21453

Hi Eli,

new version of the patch with your suggestion.

Thanks!
Attachment #8451677 - Flags: feedback- → feedback?(eperelman)
Attachment #8451677 - Flags: feedback?(eperelman) → feedback+
Hi Francisco,

I left some comments on GH

best
Hi Jose,

I've just updated the bug with your suggestions.

Thanks!
Flags: needinfo?(jmcf)
thanks Francisco, I left a couple of comments on GH
Flags: needinfo?(jmcf)
Attachment #8451677 - Flags: review?(jmcf) → review+
Landed in master:

https://github.com/arcturus/gaia/commit/274fe36aac50743dc3705956544d246ab6f3d7a7
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Francisco, could you please have this uplifted to v2.0 branch based on my remarks in comment 2?
Flags: needinfo?(francisco)
Comment on attachment 8451677 [details] [review]
Pointer to PR 21453

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment] This is required for achieving performance acceptance criteria 
https://wiki.mozilla.org/FirefoxOS/Performance/Release_Acceptance
[Bug caused by] (feature/regressing bug #): feature needed for 2.0
[User impact] if declined: We wont be able to achieve acceptance criteria
[Testing completed]: Yes, unit test added
[Risk to taking this patch] (and alternatives if risky): No ristk since we are launching events when we reach different phases of the app
[String changes made]:
Attachment #8451677 - Flags: approval-gaia-v2.0?
Flags: needinfo?(francisco)
Attachment #8451677 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
Whiteboard: [c=automation p= s= u=] [p=4] → [c=automation p= s=2014.07.18.t u=] [p=4]
You need to log in before you can comment on or make changes to this bug.