Closed Bug 1087845 Opened 6 years ago Closed 6 years ago
[Settings] The timing of dispatching visually complete event is not realistic
182 bytes, text/html
We dispatched the event right after settings innerHTML but it is not the timing of what users are perceived. We should dispatch the event after the inserted DOM is localized.
EJ, would you mind review the simple patch? Thanks.
Attachment #8510026 - Flags: review?(ejchen)
Comment on attachment 8510026 [details] Link to https://github.com/mozilla-b2g/gaia/pull/25425 Let's see whether this fixed the profiling tools or not, r+. == Reference == https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=music,settings&app=settings&gaia_rev=e09e1734ad523cf6&gecko_rev=e8610076a5ff&plot=median
Attachment #8510026 - Flags: review?(ejchen) → review+
Thanks, EJ. master: 739c80eba6e2ce9c3cda9661f882c445fa7f0cc4
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I suspect this is the right thing to do, but has anyone from product been able to comment on this? It's not quite a requirements change, but it's an understanding-of-requirements change.
Should have flagged NI in comment 4
The new timing for visually complete in settings app is the menu items of the initial panel is displayed and localized. Hardware related information may not be ready at that time as it requires time consuming operations. I'm not sure where the original requirement from so flagging Bruce for details.
Flags: needinfo?(arthur.chen) → needinfo?(bhuang)
I'm not sure if this is the right thing to do. App Visually Complete is an event to be fired when the screen stops being updated. That's the time when the timer in users head that is measuring "how long does the app takes to load" stops. If we fire it before the screen is stable, we kind of cheat on this test in order to get good grades. I see two solutions to that: 1) We alter the performance criteria for selected apps to use a different timestamp. For Settings, maybe we can use 'moz-chrome-interactive' instead - that's exactly when the UI is ready and usable, but some of the content that will be on the screen is still loading (SIM card status, Wifi etc.) - same problem was reported by Camera app folks. 2) We modify our UX to mitigate the feeling that Settings app is not ready to use until this additional data is loaded. Currently, if you launch Settings you can't use it until wifi/antenna is loaded - you can't enter any panel, click on any toggle etc. That means that the app is not usable until it happens. If we can modify the UX to make the app fully usable except of the items related to the hardware components that are loading, then we could get closer to being able to claim that 'app-visually-complete' happens before the hardware states are being ready. I would personally recommending going for 1 and 2 together. Eli, what do you think?
oh, and we offer navigator.mozL10n.once() wrapper which is a bit better than using raw 'localized' event listener :)
The original requirement is well-documented in bug 996038: > 'moz-app-visually-complete': Emitted when the application designates that it > is visually loaded, e.g. the "above-the-fold" content exists in the DOM and > has been marked as ready for display: e.g. not `display: none`. So this event is the marker to determine when the app appears ready to use. Before the implementation of the moz-* events, the legacy performance marker was located pretty close to where 'moz-app-visually-complete' is located now (I remember, because I did the original implementation of the Settings app :) ). I partially agree with Gandalf here. I don't think solution 1 is proper. I think the problems that solution 1 try to solve are already addresses in other events. Solution 2 is spot on and is what I recommend. I propose that you re-evaluate the Settings app from a UX perspective, and consider UI changes and async UI  paradigms to improve the experience. Couple that with moving the event to the location where the app REALLY appears to be visually ready and work on your baseline from there.  https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity
(In reply to :Eli Perelman from comment #9) > Before the implementation of the moz-* events, the legacy performance marker > was located pretty close to where 'moz-app-visually-complete' is located now By this I mean it was located pretty close to where it was before this bug's change moved it.
The reason I moved the place of emitting moz-app-visually-complete is because after bug 1007600 landed we dynamically insert DOMs of the initial panel when launching. I misunderstood the meaning of the event that it should only be emitted when everything stops updating. I would incline not include the availability of the information from the hardware in the major performance indicator as it does not (and should not) block users from configuring settings. Settings app now feels like "blocked" by the hardware is because both timing of information becoming available and items becoming interactable are pretty close. I think we should try to enable the menu items faster. When the menu items are enabled, we fire moz-content-interactive (there is no functional chrome in settings app). We should answer the following questions (specific to settings app) with the UX input before moving forward: - What can be considered as visually completed? - Which event can be used a the major performance indicator? What do you think?
(In reply to Zibi Braniecki [:gandalf] from comment #8) > oh, and we offer navigator.mozL10n.once() wrapper which is a bit better than > using raw 'localized' event listener :) If I insert a new DOM element after navigator.mozL10n.once(), does it call to navigator.mozL10n.once() again after the newly added element gets localized?
(In reply to Arthur Chen [:arthurcc] from comment #11) > Would answer the following questions (specific to settings app) with the > UX input before moving forward: > - What can be considered as visually completed? When the screen stops updating. > - Which event can be used a the major performance indicator? I think that for Settings it should be moz-content-interactive. We still want to keep moz-app-visually-complete because it impacts the user perception and we want to track hardware/driver updates here. I believe that getting menu items usable earlier, caching menu options availability (so that they are not popping out after firstPaint) and visually deemphasizing hardware indicators so that once they are added it doesn't feel like a major UI update, are three things major wins we can have here.
You need to log in before you can comment on or make changes to this bug.