991831 - [B2G][Tarako][Cost Control] The data usage bar in the notifications pull-down menu loads in slowly

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Cost Control, defect, P2)

Description

[Rachel Pribble [:rpribble]]

Attachment: logcat.txt

Description:
After enabling the data usage alert in the cost control app, the data usage bar that displays in the notifications pull-down menu is slow to load in and 'pops' in frequently. After pulling down the notifications menu a few times, the bar will begin to load in correctly.

Repro Steps:
1) Update a Tarako to BuildID: 20140403004001
2) Tap the cost control app
3) Tap next through settings and enable the data use alert
4) Tap the home button
5) Pull down the notifications menu
6) Observe the data usage bar pop in slowly

Actual:
Data usage bar pops in slowly.

Expected:
Data usage bar loads correctly.

v1.3t Environmental Variables:
Device: Tarako v1.3t MOZ ril
BuildID: 20140403004001
Gaia: 8d212f640014db62c622e8c939ddbf8595f00438
Gecko: ddd7ba612cfe
Version: 28.1
Firmware Version: sp8810


Notes: Unable to use Firewatch debug tool.


Repro frequency: 100%
See attached: Video, logcat, desmg log

Comment 1

[Rachel Pribble [:rpribble]]

Attachment: desmglog.txt

This issue does not reproduce on the Buri v1.3 MOZ ril.

1.3 Environmental Variables:
Device: buri 1.3 MOZ ril
BuildID: 20140402164004
Gaia: c5cd3a11e91339163b351d50769eaca0067da860
Gecko: c6c7b01cdb8e
Version: 28.0
Firmware Version: v1.2-device.cfg

Data use bar can pop in on the Buri notifications menu, but does not appear in 'chunks' as seen on the Tarako.

Comment 2

[Rachel Pribble [:rpribble]]

Attachment: DataBar.ogg

Comment 3

[John Hammink]

We think that the widget should appear in less than 100 ms.  This (~3 seconds) is too slow.

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

given the time we have for tarako, and the feature is functioning, lets not block on this.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #4)
> given the time we have for tarako, and the feature is functioning, lets not
> block on this.

I think that's the wrong direction. We can't just turnaround and ship a half-backed product to rush something out the door. We have performance guidelines were supposed to follow, in which this falls under the requirement that this widget must be there immediately upon pulling down the notifications bar.

I'm asking product to chime in here to weigh in on the performance requirements for Tarako.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #4)
> given the time we have for tarako, and the feature is functioning, lets not
> block on this.

Discussed offline on a separate thread - triage decisions are not allowed to use the "feature functions, but perf is slow" argument to justify not blocking. We need to see actual analysis against our firm performance requirements for the release, especially against partner criteria and Android OS comparison. In past releases, operators have blocked on similar issues to this because the performance expectation is that the UI is immediately there upon pulling down the notification tray. As such, I'm not convinced this issue can exist & allow us to ship the device unless there's firm data disproving this.

Note - with any performance bug triage, be mindful of:

1. How does this compare to Android on similar hardware?
2. What's the user expectation for how long X operation should take?
3. What partner requirements does this operation have?

Comment 7

[Sandip Kamat]

I would put this under "perception of progress" use case so this needs to come under 1s. (or match android whichever is less on same hw, all else being equal). Adding Ravi.

Comment 8

[Marina Rodríguez [:mai]]

I don't have a tarako device. Gabriele, do you mind help us with the investigation?

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

ni? Marvin/Ravi for performance requirements

Comment 10

[Marvin Khoo [:Marvin_Khoo]]

Hi Joe,
The data usage bar in notification panel is a nice to have feature for Tarako. let's not blocking and drop the data usage bar in notification if engineer has no confidence to improve this feature.

To rpribble,
May i know the display perf (ms) differences between Buri & Tarako? want to know if there are chance to improve.

BR,
Marvin

Comment 11

[Jason Smith [:jsmith]]

(In reply to Marvin Khoo [:Marvin_Khoo] from comment #10)
> Hi Joe,
> The data usage bar in notification panel is a nice to have feature for
> Tarako. let's not blocking and drop the data usage bar in notification if
> engineer has no confidence to improve this feature.

Whether or not it's a nice to have to include it doesn't dismiss that you have poor performance here. If you aren't blocking on fixing this, then we should track this bug to remove the usage widget from tarako builds for 1.3T.

> 
> To rpribble,
> May i know the display perf (ms) differences between Buri & Tarako? want to
> know if there are chance to improve.

Buri loads the usage notification widget immediately upon pulling down the notifications tray (i.e. time in somewhere under 100 ms). Tarako is taking about 3 seconds to fully load the usage widget.

Comment 12

[Joe Cheng [:jcheng] (please needinfo)]

triage: given the time we have, we have other bugs with higher priority to fix
let's put this in backlog for product team to keep a list of improments for future low end phones. ni? Marvin

Comment 13

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #12)
> triage: given the time we have, we have other bugs with higher priority to
> fix
> let's put this in backlog for product team to keep a list of improments for
> future low end phones. ni? Marvin

I don't agree. As I said above, it's either fix it or turn it off. This is poor UX as it stands.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Joe Cheng [:jcheng] from comment #12)
> > triage: given the time we have, we have other bugs with higher priority to
> > fix
> > let's put this in backlog for product team to keep a list of improments for
> > future low end phones. ni? Marvin
> 
> I don't agree. As I said above, it's either fix it or turn it off. This is
> poor UX as it stands.

Just so it's clear - QA is taking firm stance against product's proposal here. We are unwilling to go with Marvin's suggestion, as this represents an obvious 3 second delay every single time the notification tray is pulled down with new usage data.

Comment 15

[Jason Smith [:jsmith]]

Mike - Can you have someone on your team weigh in on the severity here?

Comment 16

[Joe Cheng [:jcheng] (please needinfo)]

let's have Ravi/Marvin to evaluate turning it off @ product level

Comment 17

[Jason Smith [:jsmith]]

My major problem is the fact that this falls into the category of basic UI interactions that are commonly covered in a demo workflow. So that means every time someone decides to demo the device, the slowness becomes apparent. This also happens every single time the data usage changes, which is going to be very common when the notification tray is pulled down. So the first set of things that I need to see clarified here is:

* If you were demoing this device to an audience, would you really show off explicit slowness in the middle of a product demo on a basic UI interaction?
* If the performance is visually slow on a basic UI interaction, wouldn't that have impact on product review interpretations, as product reviews typically focus on basic workflows?
* Why is it okay for user to wait 3 seconds to have the notification tray fully load?

I'm also not convinced that support for this feature is a nice to have. Our target markets we've typically shipped in are very conscious about how their money is spent, which is why we invested a lot of time originally to be up front in our UX about explaining active data usage. We're shipping in a low end market here too. So why are we all the sudden saying that this isn't important if our users are conscious about the money they spend? What makes the story here different than the shipping situation in other releases?

Comment 18

[Jason Smith [:jsmith]]

I think I understand what Marvin is implying here - he's suggesting we remove the usage widget for 1.3T and backlog the actual fix for a later release. If it makes thinks easier, I'll file a new bug for removing the widget.

Comment 19

[Noemí Freire (:noemi)]

Hi,

First of all sorry for jumping late in the discussion.
Cost Control widget takes the same time to be initiated in v1.3 or v1.3T and beyond. The fact is that in v1.3 it is initiated in background while initiating the system (so when you go to utility tray and pull it down the widget is already initiated and because of this it immediately appears) and from v1.3T and beyond it was requested to just initiate the CostControl widget when launched to avoid memory consumption and fulfill tarako project consumption requirements (widget is launched when called it not before).
On the other hand, notice that the widget has been always loaded in "chunks" due to we need to detect if based on the mcc/mnc we will offer data usage functionality or also cost control one (balance, top ups…). what happened in v1.3 is that this effect was not visible due to the widget was loaded in advance.

So we don't see why the widget needs to be removed, it is just the way we decided to proceed to avoid memory consumption issues.

Comment 20

[Jason Smith [:jsmith]]

I don't think it makes sense to visually show chunks of a widget loading to a user. Right now, the chunk loading animation takes 3 seconds to load, which makes the usage widget feel slow visually from a user's perspective. We really need a solution that ensures that allows the usage widget to load in one second or less with a clean loading animation when the usage widget isn't loaded. I'd suggest following up with UX here to determine what should be shown when the usage widget isn't fully loaded.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #20)
> I don't think it makes sense to visually show chunks of a widget loading to
> a user. Right now, the chunk loading animation takes 3 seconds to load,
> which makes the usage widget feel slow visually from a user's perspective.
> We really need a solution that ensures that allows the usage widget to load
> in one second or less with a clean loading animation when the usage widget
> isn't loaded. I'd suggest following up with UX here to determine what should
> be shown when the usage widget isn't fully loaded.

I'll leave needinfo on UX here to get their perspective on this though.

Comment 22

[Stephany Wilkes]

I am flagging Gordon, as he has been recently working with the performance team on human (not just system) perception of issues like this. Gordon, please ni? other UX folks as appropriate, but it seems like your insight might be able to help here.

Comment 23

[Gabriele Svelto [:gsvelto]]

I've taken a profile of the widget starting up on 1.3t, the result is here:

http://people.mozilla.org/~bgirard/cleopatra/#report=519251f15cc558d228789afe4b7d8cd494c093f3

The startup takes ~1.6s but I think it's perception is made longer by the widget window appearing in three stages: first a black rectangle, then the two-panel view and then the single-panel view. There's a couple of things we could do to improve this. First I've noticed that Widget.updateUI() is being called twice, once before the initialization has finished and once afterwards. We could kill the first call as it is pointless, it seems to me like this could save ~50ms, not much but they're essentially free.

The second thing we could do is to hide the DOM elements during startup so we don't have the two panels -> one panel transition. That could save some significant time too as the widget window wouldn't be re-laid out twice.

Finally I'm not sure why the window appears as entirely black in the very beginning before the two panels are painted. Maybe there's an issue in the window manager; in any case if we could get rid of that too it would help a lot.

In a nutshell what I'm suggesting is to try and make it so that we make the widget visible only after we're done with initialization so that we know there won't be some useless and ugly looking UI transitions.

Comment 24

[Salvador de la Puente González [:salva]]

As commented on IRC and for making everyone interested on this topic aware of it just adding what has been discussed:

I think we've got rid of the widget so quickly. Please notice the widget is a key feature from UX point of view. It has been there from the beginning and the UX team has been always aware about this kind of "slow-load" can happen. We took the decision of get rid of the widget early start-up in order to reduce memory consumption and fulfill tarako requirements on this and a lot effort and time has been spent for it. This is one of the side effects.

Comment #4, comment #10, comment #12 are telling us the feature is working and it is a nice to have. Indeed, Marvin said we can drop the widget off if engineers can not stand up with a proper solution which is still under analysis (please refer to comment 23) but anyway the decision has been unilateral taken.

I really appreciate QA to defend what they consider right. All of the disciplines are doing exactly the same. Product agreed on maintaining the widget but there has not been chance for devs nor ux teams to pronounce themselves.

UX can say if this is really important or not and Gabriele is suggesting us how to improve the start-up time and I can tell you this only happens the first time (or if the OOM killer kills the widget for out of memory reasons, like in other apps) because the application needs to be open. It is true it takes no more time than other critical applications such as dialer, contact or Messaging so please, let's undo the removal to give ux and product teams the chance of taking an informed decision and dev team the possibility to improve it.

WDYT?

Comment 25

[Stephany Wilkes]

Please allow time (even a single day) for UX to weigh in here, please. We cannot jump on every bug on which we are flagged immediately. Thank you!

Comment 26

[Marina Rodríguez [:mai]]

Attachment: patch for master branch to improve the widget performance

Following the Gabriele suggestions, I've prepared this patch. Salva, do you mind reviewing the code?

Regards

Comment 27

[Mike Lee [:mlee]]

We should try Marina's patch in comment 26 before deciding to pull this feature. As mentioned earlier this feature is critical for the markets we ship in. As far as Responsive Performance Goals[1], we have them documented[2] on our FxOS Performance wiki page as well in a UX presentation on Perceived Performance[3].

The widget should appear as quickly as any other notification in the Notifications pull-down. It's content, the colored progress bar showing how much data has been used, should be rendered within 1s of opening the notifications bar.

Dragging to open the Notifications pull-down corresponds to "Hand-eye Coordination" which should happen within 100ms of your finger's movement. How quickly items in the Notifications area should be displayed may be debatable. "Perception of Progress" seems to be the reasonable guideline there which would require rendering the widget within 1s.

That said, as a user, I expect all items in the Notifications area to be already rendered before I drag the area open (hand-eye) because the Notifications area feels like something that's ready-and-waiting (cause and effect), unlike an app which needs to be tapped (cause and effect) then waited on (perception of progress) to complete launching.

[1] https://wiki.mozilla.org/B2G/Performance/Responsiveness
[2] https://wiki.mozilla.org/B2G/Performance/UserStories
[3] https://mozilla.app.box.com/s/aww17rx74k7fjds5vada

Comment 28

[Jason Smith [:jsmith]]

Agreed with salva & mike's points above.

I talked with Chris in person about this - he said he was going to chime in here on a decision on what to do here:

* Block & take the patch to get the widget back into tarako
* Not block & leave the feature out of tarako

Comment 29

[Marina Rodríguez [:mai]]

Updated the PR with the Salva comments.

I've recorded a video with the behaviour of the patch over master on buri device:
 http://youtu.be/V8zHRUKR3V4

The test for this patch are implemented on the "Bug 993949 - [Cost Control] Follow up to add unit test for bug 986358", this patch is not landed yet on master branch

Comment 30

[Marina Rodríguez [:mai]]

Comment on attachment 8405061 [details] [review]
patch for master branch to improve the widget performance

>https://github.com/mozilla-b2g/gaia/pull/18197

Comment 31

[Marina Rodríguez [:mai]]

This patch is only for master branch, I have to prepare a specific patch for Tarako branch, unless you prefer uplift the patches that were applied on master branch and they are not on v1.3T.

Comment 32

[Salvador de la Puente González [:salva]]

Comment on attachment 8405061 [details] [review]
patch for master branch to improve the widget performance

I see the patch get rid of lots of already unused or deprecated code. The improvements are noticeable in the video. Let's review those tests.

Thank you very much.

Comment 33

[Noemí Freire (:noemi)]

(In reply to marina rodríguez [:mai] from comment #31)
> This patch is only for master branch, I have to prepare a specific patch for
> Tarako branch, unless you prefer uplift the patches that were applied on
> master branch and they are not on v1.3T.

Hi,

Could qa/ux/product give their point of view about the patch in master (Comment 30) while preparing the specific patch for tarako?. Thanks!

Comment 34

[Marina Rodríguez [:mai]]

New video, after adding a background image to reduce the load time perception on the widget:
http://youtu.be/cpBZCrIaK3k
Regards

Comment 35

[Marina Rodríguez [:mai]]

Attachment: WIP patch for tarako

WIP patch for tarako branch

Comment 36

[Gabriele Svelto [:gsvelto]]

(In reply to marina rodríguez [:mai] from comment #29)
> I've recorded a video with the behaviour of the patch over master on buri
> device:
>  http://youtu.be/V8zHRUKR3V4

This is a fantastic improvement Marina, thank you for doing this! I've measured the widget startup time using the profiler on my buri and with your patch applied it drops from ~1,75s to ~1,2s which is an amazing reduction.

Comment 37

[Salvador de la Puente González [:salva]]

Thank you everybody. Thanks Jason for moving the bug and give us a chance for improvement. Hope the reduction Gabriele is talking about helps. Furthermore this allowed to improve in master as well. I will be on holidays but I know this is an important matter. Just ping me twice!

If somebody else is getting holidays as well, hope they enjoys their free time.

Comment 38

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Do we want to place the widget back in?  It was removed in bug 994493.

Comment 39

[Ravi Dandu]

This is an improvement on the data usage bar on the cost control app. Does the data usage bar happen in ~1 seconds in Tarako too? We should get it into Tarako.
Naoki, how long does it take in Tarako? If you cannot measure since it is not present, then lets the feature back in.

Comment 40

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Marina, can you needinfo me when you have the patch ready?  I will try to get it working on a private build.  I believe that you will have to turn the widget back on (maybe back out of bug 994493?).

Comment 41

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

The notification appears faster, however the values seems incorrect until you launch the cost control and then go back to the notification.  Please see video : http://www.youtube.com/watch?v=evyfv2VkICQ&feature=youtube_gdata_player

Comment 42

[Marina Rodríguez [:mai]]

Hi Naoki, 
I've updated the PR for tarako, do you mind testing the patch with your tarako device? I think your problem is fixed with this update. 
Regards and thanks for your support.

Comment 43

[Marvin Khoo [:Marvin_Khoo]]

Thanks Mike for notification. and Noemi jumping in to this!

Hi Jason,
once we have result verified by Naoki on Tarako device, could you also comment if it reach QA expectation?

moreover, Naoki also observed the cost display in notification doesn't get update until Cost control app is opened. for this, Marina also give updates to fix it.

I would say if engineer be able to fix it, and QA given ok to that, PMs are more than happy to have this feature back.

BR,
Marvin

Comment 44

[Marina Rodríguez [:mai]]

Comment on attachment 8405061 [details] [review]
patch for master branch to improve the widget performance

I've rebased the patch after uplifting to master the patch 993949 (unit test for the widget). Also, I've added another test to increase the coverage.
Salva, please, could you review the patch again?

Regards.

Comment 45

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

FYI https://github.com/mozilla-b2g/gaia/commit/bbba09c732c35d9434ecb04d5e2e41d05511f4d9 has to be backed out in order to see the widget.

Retesting it : http://www.youtube.com/watch?v=s8fyz_O_H_w&feature=youtube_gdata_player
The data seems to appear faster.

Are we only suppose to get the SIM data in the usage app?  I had both SIM and wifi usage selected in the app, only the SIM data shows.

Comment 46

[Jason Smith [:jsmith]]

If Naoki signs off on this, then let's take it & get the feature back on.

Comment 47

[Marvin Khoo [:Marvin_Khoo]]

Thanks Jason!

Comment 48

[Marina Rodríguez [:mai]]

Naoki, the widget only shows the traffic of the SIM that you've selected as default sim for data traffic, on settings.

Thanks everybody for your support!

Comment 49

[Salvador de la Puente González [:salva]]

Comment on attachment 8405061 [details] [review]
patch for master branch to improve the widget performance

Just a little nit on GitHub. Thank your for the efforts and the tests!

Comment 50

[Marina Rodríguez [:mai]]

Master: d13700d2a84b4b8ab0f2aea5af03508a34666a5f

Comment 51

[Marina Rodríguez [:mai]]

Comment on attachment 8405367 [details] [review]
WIP patch for tarako

Final patch with the unit test. Salva, could you review the patch for tarako?
Regards

Comment 52

[Salvador de la Puente González [:salva]]

Comment on attachment 8405367 [details] [review]
WIP patch for tarako

A simple comment on GitHub. Thank you Mai.

Comment 53

[Marina Rodríguez [:mai]]

Updated the PR with your comments, Salva.

Comment 54

[Marina Rodríguez [:mai]]

Hi Ryan,
I don't know what is the procedure to ask for the uplift to the tarako branch (v1.3t)Could you please help us with this?

Thanks!

Comment 55

[Ryan VanderMeulen [:RyanVM]]

You can uplift 1.3T+ bugs to that branch whenever you're ready :)
https://wiki.mozilla.org/Release_Management/B2G_Landing#Landing_Procedure_4

Comment 56

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Based on what Marina stated in comment 48, I sign off on it.

As stated previously, we would have to land this and back out of the other patch to reenable the widget.

Comment 57

[Joe Cheng [:jcheng] (please needinfo)]

yes let's re-enable this feature then. thanks

Comment 58

[Marina Rodríguez [:mai]]

Attachment: patch for v1.4

Hi Salva,
would you mind review the patch for 1.4?
Regards

Comment 59

[Noemí Freire (:noemi)]

Hi,

Tarako patch is ready to be uplifted to v1.3T branch from 4/16, QA also agreed on it(please see comment 56). Since we need Bug 994493 to be backed out at the same time, could someone from release mgmt team help us with the uplift and back out processes?. Thanks!

Comment 60

[Salvador de la Puente González [:salva]]

Comment on attachment 8410069 [details] [review]
patch for v1.4

Ok. Very similar to the patch for Tarako. Working fine on v1.4
Thank you very much.

Comment 61

[Marina Rodríguez [:mai]]

Comment on attachment 8410069 [details] [review]
patch for v1.4

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

Before the bug 858017 was landed, the widget was loaded on the system startup. Currently, the widget is loaded when the user slides down the utility tray for reducing memory consumption, therefore it's necessary improving the start-up time for the widget.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 858017
[User impact] if declined: The widget loads in slowly. It's a bad UX for the user.
[Testing completed]:Yes
[Risk to taking this patch] (and alternatives if risky): Low risk, because this patch is landed on master and it has not produced any regression till now
[String changes made]:No

Comment 62

[Jason Smith [:jsmith]]

Comment on attachment 8410069 [details] [review]
patch for v1.4

Not needed on 1.4 - the bug's severity only really applies to Tarako. On other devices, the severity of this bug is far lower impact.

Comment 63

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #62)
> Comment on attachment 8410069 [details] [review]
> patch for v1.4
> 
> Not needed on 1.4 - the bug's severity only really applies to Tarako. On
> other devices, the severity of this bug is far lower impact.

Mainly because the performance on other devices is fast enough that the issue only appears to be a minor glitch. On Tarako, this was a different story because the performance of the widget is far slower.

Comment 64

[Salvador de la Puente González [:salva]]

(In reply to Jason Smith [:jsmith] from comment #63)
> (In reply to Jason Smith [:jsmith] from comment #62)
> > Comment on attachment 8410069 [details] [review]
> > patch for v1.4
> > 
> > Not needed on 1.4 - the bug's severity only really applies to Tarako. On
> > other devices, the severity of this bug is far lower impact.
> 
> Mainly because the performance on other devices is fast enough that the
> issue only appears to be a minor glitch. On Tarako, this was a different
> story because the performance of the widget is far slower.

Agree but from a code point of view, the improvement is the result of a very convenient refactor that sorts part of the start-up process of the widget. Imagine we have to fix a specific problem in 1.4. It's very probable it will depend on this so why not merge and avoid future dependencies?

Comment 65

[ying.xu]

based on Comment 56

merged into v1.3t

https://github.com/mozilla-b2g/gaia/commit/71b326380bc521b658c1587c79368df667a5d1d4

Comment 66

[Noemí Freire (:noemi)]

(In reply to ying.xu from comment #65)
> based on Comment 56
> 
> merged into v1.3t
> 
> https://github.com/mozilla-b2g/gaia/commit/
> 71b326380bc521b658c1587c79368df667a5d1d4

mmm, we would need Bug 994493 to be backed out at the same time and it appears still as RESOLVED FIXED, has it been already backed out?. Thanks!

Comment 67

[ying.xu]

(In reply to Noemí Freire (:noemi) from comment #66)

> mmm, we would need Bug 994493 to be backed out at the same time and it
> appears still as RESOLVED FIXED, has it been already backed out?. Thanks!

I don't know how to back out a commit.
Is that reverting and pushing?

Comment 68

[Noemí Freire (:noemi)]

(In reply to ying.xu from comment #67)
> (In reply to Noemí Freire (:noemi) from comment #66)
> 
> > mmm, we would need Bug 994493 to be backed out at the same time and it
> > appears still as RESOLVED FIXED, has it been already backed out?. Thanks!
> 
> I don't know how to back out a commit.
> Is that reverting and pushing?

Yes, anyway I've just asked Fred to help us with (https://bugzilla.mozilla.org/show_bug.cgi?id=994493#c9)

Comment 69

[Jason Smith [:jsmith]]

(In reply to Salvador de la Puente González [:salva] from comment #64)
> (In reply to Jason Smith [:jsmith] from comment #63)
> > (In reply to Jason Smith [:jsmith] from comment #62)
> > > Comment on attachment 8410069 [details] [review]
> > > patch for v1.4
> > > 
> > > Not needed on 1.4 - the bug's severity only really applies to Tarako. On
> > > other devices, the severity of this bug is far lower impact.
> > 
> > Mainly because the performance on other devices is fast enough that the
> > issue only appears to be a minor glitch. On Tarako, this was a different
> > story because the performance of the widget is far slower.
> 
> Agree but from a code point of view, the improvement is the result of a very
> convenient refactor that sorts part of the start-up process of the widget.
> Imagine we have to fix a specific problem in 1.4. It's very probable it will
> depend on this so why not merge and avoid future dependencies?

Because on 1.4 devices the impact of this bug is minor & we're not taking gaia approvals generally anymore unless they are on an exception list (camera, l10n).

Comment 70

[Natalya Kot [:nkot]]

So the usage widget in the notification tray is back!

Tarako
BuildID: 20140425014003
Gaia: 293b056683b506ec1b4787d0fbf6033cc30fa953
Gecko: d91121fbca90
Version: 28.1
sp6821a_gonk4.0_user.pac

Comment 71

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

In an attempt to verify that this issue has bee fixed I did some stopwatch testing.  The load time for the data usage widget was consistently between 1.95 and 2.25 seconds, much longer than the above stated 100ms.  Also the widget does not load in all at once, but instead the bar loads in about a second before the text does.

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140429014002
Gaia: b5adc5a943d3abbd6ab070a47c847f2c24891cc5
Gecko: e9890f5d4709
Version: 28.1
Firmware Version: sp6821

Comment 72

[Salvador de la Puente González [:salva]]

(In reply to Mike Lee [:mlee] from comment #27)
> Dragging to open the Notifications pull-down corresponds to "Hand-eye
> Coordination" which should happen within 100ms of your finger's movement.
> How quickly items in the Notifications area should be displayed may be
> debatable. "Perception of Progress" seems to be the reasonable guideline
> there which would require rendering the widget within 1s.

For this comment, it should be within 1s, not 100ms. Anyway, this is not possible as one of the widget requirements is to be an isolated application. Thus, the first time the widget is loaded, it will take more than subsequent times when it should appear almost immediately unless the OOM killer has wipe the application out.

Comment 73

[bhavana bajaj [:bajaj]]

(In reply to Noemí Freire (:noemi) from comment #59)
> Hi,
> 
> Tarako patch is ready to be uplifted to v1.3T branch from 4/16, QA also
> agreed on it(please see comment 56). Since we need Bug 994493 to be backed
> out at the same time, could someone from release mgmt team help us with the
> uplift and back out processes?. Thanks!

This looks like it has has been fixed on 1.3T branch, clearing the ni here. What's the plan here for 1.4 ?

Comment 74

[bhavana bajaj [:bajaj]]

(In reply to bhavana bajaj [:bajaj] from comment #73)
> (In reply to Noemí Freire (:noemi) from comment #59)
> > Hi,
> > 
> > Tarako patch is ready to be uplifted to v1.3T branch from 4/16, QA also
> > agreed on it(please see comment 56). Since we need Bug 994493 to be backed
> > out at the same time, could someone from release mgmt team help us with the
> > uplift and back out processes?. Thanks!
> 
> This looks like it has has been fixed on 1.3T branch, clearing the ni here.
> What's the plan here for 1.4 ?

Its going to be a wontfix per comment #69, marking appropriately