857267 - Suspicious Painting Activity while email is visible but inactive.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[James Lal [:lightsofapollo]]

Attachment: Kill progress indicators in apps/email/index.html

I observed some suspicious CPU activity (around 30%) while doing absolutely nothing... Email is in the foreground and wifi is off.

I suspected there was some animation looping endlessly so I turned off all the progress elements...

Before: http://people.mozilla.com/~bgirard/cleopatra/#report=3473ae0a5337c580af5ba8aefd134d06b297860e

After: http://people.mozilla.com/~bgirard/cleopatra/#report=7d3fdd3eeeea7b44da8602599c1e81bf7d6221d2

-- 

Disclaimer: this may be completely random junk that is only reproducible for me but we should eliminate this as a possible issue.

Comment 1

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

Could this explain the unresponsiveness when long tapping on a contact to add to the contact database?  Or should I file a separate bug?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

That sounds like a very different bug.  Also, you don't need to long-hold on the contact, just click.  Apart from long-hold activating bulk edit mode, we aren't supposed to do anything that retires long-hold/contextmenu events anymore.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

(In reply to James Lal [:lightsofapollo] from comment #0)
> Disclaimer: this may be completely random junk that is only reproducible for
> me but we should eliminate this as a possible issue.

From my investigation, it looks like this is what I hypothesized on IRC today.  Namely that the 'candybar' progress activity indicator thing we turn on was not properly getting turned off when synchronization completed.

Specifically, I'm able to reproduce the problem if I sync an ActiveSync account pretty easily.  Because ActiveSync provides almost no progress updates, it's very easy for it to cause this to happen.  Then with the following patch, it seems to stop happening.  And it all logically makes sense too, since visibility: hidden does require the layout engine to still do all the legwork; we just don't paint it.

Note that the way the FPS indicator feature on the phone is implemented, when the FPS actually goes to zero, it won't paint that it has gone to zero on its own!  It will usually go there after a few seconds, but that's because something eventually triggers a one-off frame painting and the averaging logic subtracts 1 off the number of frames in its averaging interval, so 0 fps is possible if there's only 1 frame ever 250+ ms.

diff --git a/apps/email/js/message-cards.js b/apps/email/js/message-cards.js
index ecd38d1..96651ab 100755
--- a/apps/email/js/message-cards.js
+++ b/apps/email/js/message-cards.js
@@ -460,6 +460,7 @@ MessageListCard.prototype = {
         // Fall through...
       case 'synced':
         this.syncingNode.classList.add('collapsed');
+        this.progressNode.classList.remove('pack-activity');
         this.progressNode.classList.add('hidden');
         if (this.progressCandybarTimer) {
           window.clearTimeout(this.progressCandybarTimer);

Comment 4

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

Thanks for the info!  I'll retest and report if necessary.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

The fix provided above has been landed as part of bug 814257.  :lightsofapollo confirmed that this seemed to fix the problem for him too, so we're pretty confident about this.