1045451 - [Dolphin]After monkey test of 0.5 hours, the main screen application icons are gone , only four icons of the dock bar show

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[yaoyao.wu]

Attachment: screenshot.png

Comment 1

[yaoyao.wu]

Attachment: app-manager.png

Comment 2

[yaoyao.wu]

Press four icons on the dock bar the phone can enter  corresponding application, press the home button the phone normally.

adb shell b2g-ps:
b2g              0 root      894   1     217516 104120 ffffffff b6e8a734 S /system/b2g/b2g
(Nuwa)           0 root      942   894   52188  20876 ffffffff b6e98734 S /system/b2g/plugin-container
Homescreen       2 u0_a961   961   942   86528  32628 ffffffff b6e98734 S /system/b2g/plugin-container
Usage            2 u0_a1016  1016  942   63564  22216 ffffffff b6e98734 S /system/b2g/plugin-container
Communications   2 u0_a1205  1205  942   76628  33432 ffffffff b6e98734 S /system/b2g/plugin-container
Messages         2 u0_a6734  6734  942   70464  28552 ffffffff b6e98734 S /system/b2g/plugin-container
(Preallocated a  2 u0_a6892  6892  942   58376  18292 ffffffff b6e98734 S /system/b2g/plugin-container


adb shell b2g-procrank
APPLICATION        PID       Vss      Rss      Pss      Uss  cmdline
b2g                894   247632K  111312K   97513K   92556K  /system/b2g/b2g
Communications    1205    76624K   33480K   19212K   16060K  /system/b2g/plugin-container
Homescreen         961    86524K   32684K   18998K   16024K  /system/b2g/plugin-container
Messages          6734    70460K   28552K   14872K   11852K  /system/b2g/plugin-container
Usage             1016    63560K   22216K    9271K    6712K  /system/b2g/plugin-container
(Nuwa)             942    52184K   20876K    8042K    3788K  /system/b2g/plugin-container
(Preallocated a   6892    58372K   18292K    7377K    5156K  /system/b2g/plugin-container

Comment 3

[yaoyao.wu]

From the app-manager of homescreen,we can see 
there is class ”evme-collection-visible“ in div(id="icongrid")
in Collection.css:
#icongrid.evme-collection-visible {
   display: none;
  }
I try to remove the “evme-collection-visible” class of the div in nightly,
and the phone return normal .

Comment 4

[yaoyao.wu]

nightly debugging found that only enters Social, Games, Music and Showbiz four applications,the div(id = "icongrid")appears "evme-collection-visible" class. If the current app is other app(except Social, Games, Music and Showbiz), I add class "evme-collection-visible" to the div(id = "icongrid") ,the issue will happen.
I guess the reason for this issue is : due to some reasons (such as the phone reacts slowly and so on), when enter one of the four apps, the app switch is not finished(one of the four apps hasn't been opened ,the current app is other app),but the  "evme-collection-visible" class is added ,so the problem happens. So I suggest the add the class after the app transitionend.

Comment 5

[yaoyao.wu]

Attachment: evme-colletion-visible.patch

According to the comment 4, I try to give a patch ,in this patch I try to add the "evme-collection-visible" class after 
elCollection.addEventListener('transitionend', function end() { elCollection.removeEventListener('transitionend', end);
document.dispatchEvent(new CustomEvent('collectionopened'));
 });

Hi Keven and Thomas,

Would you please help to find somebody to check the issue .
Thanks

Comment 6

[thomas tsai]

Hi William: can you help to run Monkey test again?

Comment 7

[William Hsu [:whsu]]

(In reply to thomas tsai from comment #6)
> Hi William: can you help to run Monkey test again?

Sure! I will keep you posted if I have any progress.

Comment 8

[William Hsu [:whsu]]

(In reply to yaoyao.wu from comment #5)
> Created attachment 8463809 [details] [diff] [review]
> evme-colletion-visible.patch
> 
> According to the comment 4, I try to give a patch ,in this patch I try to
> add the "evme-collection-visible" class after 
> elCollection.addEventListener('transitionend', function end() {
> elCollection.removeEventListener('transitionend', end);
> document.dispatchEvent(new CustomEvent('collectionopened'));
>  });
> 
> Hi Keven and Thomas,
> 
> Would you please help to find somebody to check the issue .
> Thanks

Hi,  Yaoyao,

Your patch (Comment 5) seems to intent to fix this bug, right?
I will merge this patch to my local branch to see if Monkey test still can reproduce this bug.
Also, I will do some manual test to see if I can reproduce it.

ETA: 7/31

Thanks.

Comment 9

[Brian Huang [:brianhuang][:brhuang]]

Keep monitoring Monkey test in TPE test environment

Comment 10

[William Hsu [:whsu]]

Hi, everyone,

Thanks to Yaoyao's information (Comment 4).
Now, I can manually reproduce this bug.
This might be a legacy bug.

* Reproduce steps
1. Repeatedly and quickly tap the third collection of e.me page and home button
2. Slow down the speed when UI response becomes slow.

Here is the demo video.
- http://www.youtube.com/watch?v=U2T8sf9Kjzc&feature=youtu.be

We need to assign a developer to solve this problem.
Thanks.

Comment 11

[James Zhang (Spreadtrum)]

We can reproduce this issue only 30 minutes.

Comment 12

[James Zhang (Spreadtrum)]

Rachelle, please pay more attention on this issue, it blocks our monkey test.

Comment 13

[Peipei Cheng (needinfo if you need my action)]

Attachment: Homescreen.png

I also see similar issue several times today, but still unable to figure out a STR.

Homescreen stays in E.Me search page. No Dock bar/keyboard/Smartcollections appear. But the right panel which displays normal. And when I swipe back to the first panel, it stays the same.

To recover, I need to restart Homescreen.

Comment 14

[William Hsu [:whsu]]

(In reply to Peipei Cheng from comment #13)
> Created attachment 8466016 [details]
> Homescreen.png
> 
> I also see similar issue several times today, but still unable to figure out
> a STR.
> 
> Homescreen stays in E.Me search page. No Dock bar/keyboard/Smartcollections
> appear. But the right panel which displays normal. And when I swipe back to
> the first panel, it stays the same.
> 
> To recover, I need to restart Homescreen.

Hi, Peipei,

Try the steps I mentioned (Comment 10) and refer to the video I listed.
You may easy to reproduce it in 5 minutes.
Thanks.

Comment 15

[Marvin Khoo [:Marvin_Khoo]]

Triage result, per comment 12, block Monkey test, 1.4+.


Hi Evelyn,
could you please assign someone check here.

Comment 16

[Rachelle Yang [:ryang][[e-mail]]]

Per comment 15, set to 1.4+.

Comment 17

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Take it.
It seems like a regression. I am bisecting it.

Comment 18

[Tzu-Lin Huang [:dwi2][:tzhuang]]

I found out that this could be reproduce even from fc7efb1f038e26b13d567c1b2f0a1758cf9c471c (landed on Mar. 15, 2014)
I didn't mean this is the regression commit but just to say the bisecting range could be too large. It could take too much time to find the regression patch. So I'll start to find root cause instead of to bisect it.

Comment 19

[William Hsu [:whsu]]

Hi, everyone,

After I applied "evme-colletion-visible.patch" to my local branch then verify it, I cannot manually reproduce this bug.
Please review this patch and decide whether we want to merge it to v1.4.
Thanks!

* Build information:
 - Gaia      attachment 8463809 [details] [diff] [review]
 - Gecko     e455946d31c20ec3ffcd786326d38156d9b4366d
 - BuildID   20140801152721
 - Version   30.0

Comment 20

[yang.zhao]

(In reply to Peipei Cheng from comment #13)
> Created attachment 8466016 [details]
> Homescreen.png
> 
> I also see similar issue several times today, but still unable to figure out
> a STR.
> 
> Homescreen stays in E.Me search page. No Dock bar/keyboard/Smartcollections
> appear. But the right panel which displays normal. And when I swipe back to
> the first panel, it stays the same.
What you see is a different issue, I have met this one before,but I couldn't find the STR either. It seems that the keyboard is missing which should shows up.
> To recover, I need to restart Homescreen.
To recover, maybe you could try to click the input to show the keyboard, or try to click the star which is in the right of the string "Everything". You could try it next time.

Comment 21

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Comment on attachment 8463809 [details] [diff] [review]
evme-colletion-visible.patch

per comment 19, let's ask for review for the patch.

However, I'll keep looking for root cause in the meanwhile because this patch looks a little bit workaround to me.

Comment 22

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Post my finding so far here: 
when user click collection icon on e.me and home button interchangeably fast enough, it could be possible that hide() function in Collection.js get invoked back to back

and it checks currentSettings available or not at the begining 
https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/modules/Collection/Collection.js#L360

So .evme-colletion-visible could not be removed if hide() in Collection.js get invoked twice in a row. I guess this is some sort of asynchronous racing problem which hardly reproduce manually but usually seen when running monkey test.

I'll keep on digging the problem deeper.

Comment 23

[Amir Nissim (:amirn)]

Comment on attachment 8463809 [details] [diff] [review]
evme-colletion-visible.patch

LGTM. Thanks.

Comment 24

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Hi all,

I think I found the root cause. This bug is introduced by async racing.

This is because from the time we fill value of currentSettings:
https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/modules/Collection/Collection.js#L345
to the time we actually hide collection icons (by applying evme-collection-visible class):
https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/js/Brain.js#L949
there are two asynchronous method calls (by window.setTimeout):
https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/modules/Collection/Collection.js#L390
https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/js/Brain.js#L947

If any call to Evme.Collection.hide() (https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/modules/Collection/Collection.js#L359) happens in between, we'll be unable to remove evme-collection-visible class anymore


I add some console log for debugging purpose, https://github.com/dwi2/gaia/commit/913a7b515c8812578194042d03cc2e439fc6a5e8

When user tap on collection icon and home button in a normal speed, the log would be:
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:344 in show: 1045451>>> show is called
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:347 in onGotFromStorage: 1045451>>> fill in currentSettings
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:398 in showUI: 1045451>>> trigger Collection::beforeShow
LOG at app://homescreen.gaiamobile.org/everything.me/js/Brain.js:949 in beforeShow/<: 1045451>>> ADD evme-collection-visible
LOG at app://homescreen.gaiamobile.org/everything.me/js/Core.js:65 in onHomeButtonPress: 1045451>>> might call Collection.hide() on home button press
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:363 in hide: 1045451>>> hide() is called
E/GeckoConsole(13853): Content JS LOG at app://homescreen.gaiamobile.org/everything.s:366 in hide: 1045451>>> currentSettings = [object Object], self.isRenaming = false
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:379 in hide: 1045451>>> clean up currentSettings
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:423 in hideUI: 1045451>>> trigger Collection::beforeHide
LOG at app://homescreen.gaiamobile.org/everything.me/js/Brain.js:966 in beforeHide: 1045451>>> beforeHide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/js/Brain.js:969 in beforeHide/<: 1045451>>> REMOVE evme-collection-visible
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:429 in end: 1045451>>> trigger Collection::hide

But when I follow STR and successfully reproduce the bug as comment 10, the log would be:
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:344 in show: 1045451>>> show is called
LOG at app://homescreen.gaiamobile.org/everything.me/js/Core.js:65 in onHomeButtonPress: 1045451>>> might call Collection.hide() on home button press
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:363 in hide: 1045451>>> hide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:366 in hide: 1045451>>> currentSettings = null, self.isRenaming = false
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:347 in onGotFromStorage: 1045451>>> fill in currentSettings
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:398 in showUI: 1045451>>> trigger Collection::beforeShow
LOG at app://homescreen.gaiamobile.org/everything.me/js/Core.js:65 in onHomeButtonPress: 1045451>>> might call Collection.hide() on home button press
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:363 in hide: 1045451>>> hide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:366 in hide: 1045451>>> currentSettings = [object Object], self.isRenaming = false
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:379 in hide: 1045451>>> clean up currentSettings
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:423 in hideUI: 1045451>>> trigger Collection::beforeHide
LOG at app://homescreen.gaiamobile.org/everything.me/js/Brain.js:966 in beforeHide: 1045451>>> beforeHide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/js/Core.js:65 in onHomeButtonPress: 1045451>>> might call Collection.hide() on home button press
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:363 in hide: 1045451>>> hide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:366 in hide: 1045451>>> currentSettings = null, self.isRenaming = false
LOG at app://homescreen.gaiamobile.org/everything.me/js/Brain.js:969 in beforeHide/<: 1045451>>> REMOVE evme-collection-visible
LOG at app://homescreen.gaiamobile.org/everything.me/js/Brain.js:949 in beforeShow/<: 1045451>>> ADD evme-collection-visible
LOG at app://homescreen.gaiamobile.org/everything.me/js/Core.js:65 in onHomeButtonPress: 1045451>>> might call Collection.hide() on home button press
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:363 in hide: 1045451>>> hide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:366 in hide: 1045451>>> currentSettings = null, self.isRenaming = false
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:429 in end: 1045451>>> trigger Collection::hide
LOG at app://homescreen.gaiamobile.org/everything.me/js/Core.js:65 in onHomeButtonPress: 1045451>>> might call Collection.hide() on home button press
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:363 in hide: 1045451>>> hide() is called
LOG at app://homescreen.gaiamobile.org/everything.me/modules/Collection/Collection.js:366 in hide: 1045451>>> currentSettings = null, self.isRenaming = false

Comment 25

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Comment on attachment 8463809 [details] [diff] [review]
evme-colletion-visible.patch

Hi all,

I still can reproduce the bug with this patch, and I think this patch is not the right solution to the bug.

Comment 26

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Attachment: PR to v1.4

based analysis on comment 24, I come up with the patch.

Hi Amir,
Could you help to review the patch? Thanks

Hi William,
Could you help to verify if this patch works? Thanks.

Comment 27

[William Hsu [:whsu]]

(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #26)
> Created attachment 8467701 [details] [review]
> PR to v1.4
> 
> based analysis on comment 24, I come up with the patch.
> 
> Hi Amir,
> Could you help to review the patch? Thanks
> 
> Hi William,
> Could you help to verify if this patch works? Thanks.

Is this a critical patch and it may break the v1.4 branch?
If so, please NI:whsu after someone review this patch.
It is inappropriate to request me to test a unreviewed patch.

As you mentioned, this seems to cause by race condition, right?
Why not to use JS marionette to test it? I think it can help you to get precise result than black-box testing.
As I did on comment 19, I have  missed something, right?

Thanks.

Comment 28

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Comment on attachment 8467701 [details] [review]
PR to v1.4

per comment 27, I'll write some JS marionette tests for the bug first.
(Change review flag to f? until I finish JS marionette tests)

Comment 29

[Amir Nissim (:amirn)]

Comment on attachment 8467701 [details] [review]
PR to v1.4

Not sure why setTimeout is used there.
I'm afraid removing it might cause a regression.

Please ask for review when the tests are ready and I will take a deeper look.

Thanks.

Comment 30

[yang.zhao]

Does this issue has any update? Could we land the patch attachment 8467701 [details] [review]?^_^

Comment 31

[ben.song]

I think PaginationBar has no conflict with collection in view,thank.

Comment 32

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Hi Yang,

I found that it is somewhat difficult to write a JS marionette test to reproduce this issue. And I cannot be 100% sure whether attachment 8467701 [details] [review] works or not. 
Would you mind to help testing the patch with monkey test at your site? Thanks

Comment 33

[yaoyao.wu]

(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #32)
> Hi Yang,
> 
> I found that it is somewhat difficult to write a JS marionette test to
> reproduce this issue. And I cannot be 100% sure whether attachment 8467701 [details] [review]
> [details] works or not. 
> Would you mind to help testing the patch with monkey test at your site?
> Thanks
Hi Tzu-lin and Yang,

  I'll land the patch and run monkey-test.I'll tell you the result after running monkey test.
Thanks

Comment 34

[yang.zhao]

(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #32)
> Hi Yang,
> 
> I found that it is somewhat difficult to write a JS marionette test to
> reproduce this issue. And I cannot be 100% sure whether attachment 8467701 [details] [review]
> [details] works or not. 
> Would you mind to help testing the patch with monkey test at your site?
> Thanks
Hi,Tzu-Lin
    With the patch,I didn't reproduce the issue when running monkey test.And James said, he saw the issue could appear when running monkey test,but it could be recovery after a while. So could we merge the patch into v1.3t? Thank you.

Comment 35

[James Zhang (Spreadtrum)]

Yang, 1.4 branch.

Comment 36

[William Hsu [:whsu]]

(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #32)
> Hi Yang,
> 
> I found that it is somewhat difficult to write a JS marionette test to
> reproduce this issue. And I cannot be 100% sure whether attachment 8467701 [details] [review]
> [details] works or not. 
> Would you mind to help testing the patch with monkey test at your site?
> Thanks

Hey, Tzu-Lin.

Sorry for the late reply.
OOPS!~ I saw your information on comment 28 and 32.
You seem to intend to write JS marionette test to test this patch by yourself, right?

So sorry. The information I mentioned (comment 27) just want to friendly remind/suggest you that you can test this patch via existed JS marionette test because this patch is not yet reviewed. 
(Note: QA doesn't like to test a unreviewed patch because we will spend double effort on patch verification)
But, now, JS marionette test seem not to have relate test cases, right?
If so, I can use Gaia UI test to assist this test
I will keep you posted.

Thanks. Sorry for any inconvenience.
NI:whsu

Comment 37

[Brogan Zumwalt [Inactive]]

New test case needs to be written to address bug.

Comment 38

[Tzu-Lin Huang [:dwi2][:tzhuang]]

(In reply to yang.zhao from comment #34)
> (In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #32)
> > Hi Yang,
> > 
> > I found that it is somewhat difficult to write a JS marionette test to
> > reproduce this issue. And I cannot be 100% sure whether attachment 8467701 [details] [review]
> > [details] works or not. 
> > Would you mind to help testing the patch with monkey test at your site?
> > Thanks
> Hi,Tzu-Lin
>     With the patch,I didn't reproduce the issue when running monkey test.And
> James said, he saw the issue could appear when running monkey test,but it
> could be recovery after a while. So could we merge the patch into v1.3t?
> Thank you.

Hi Yang,
If you are in hurry, I'll suggest you use local patch first before we could ever verify the effectiveness of the patch.

Thanks

Comment 39

[William Hsu [:whsu]]

Hi, everyone,

After I finished following tests, I still can reproduce this bug with this patch (attachment 8467701 [details] [review]).
Do it cause by other factors?
- 6 Hours monkey test.
  ~ Cannot reproduce.
- 100 times automation test via Gaia UI test. (Demo video: http://youtu.be/n7MGZqVY_OE )
  ~ Cannot reproduce.
- 5 Minutes manually test
  ~ Reproduced as attachment shown (WP_20140818_007.mp4)


* Build information:
 - Gaia      attachment 8467701 [details] [review]
 - Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/d4e14a98b165
 - BuildID   20140818000201
 - Version   30.0

Comment 40

[William Hsu [:whsu]]

Attachment: WP_20140818_007.mp4

Comment 41

[KTucker [:KTucker][Inactive 3/4/2016]]

This is an automated test. No test case added in moztrap.

Comment 42

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Comment on attachment 8467701 [details] [review]
PR to v1.4

this patch is not work based on comment 39

I'll dig it deeper.

Comment 43

[Evelyn Hung]

(In reply to William Hsu [:whsu] from comment #39)
> Hi, everyone,
> 
> After I finished following tests, I still can reproduce this bug with this
> patch (attachment 8467701 [details] [review]).
> Do it cause by other factors?
> - 6 Hours monkey test.
>   ~ Cannot reproduce.
> - 100 times automation test via Gaia UI test. (Demo video:
> http://youtu.be/n7MGZqVY_OE )
>   ~ Cannot reproduce.
> - 5 Minutes manually test
>   ~ Reproduced as attachment shown (WP_20140818_007.mp4)
> 

Hi William,
Your video doesn't show how you reproduce the issue, it starts from the issue has already occurred. It doesn't help on debugging. May I know how you manually reproduce it? Thanks.

Comment 44

[Evelyn Hung]

(In reply to Amir Nissim (:amirn) from comment #29)
> Comment on attachment 8467701 [details] [review]
> PR to v1.4
> 
> Not sure why setTimeout is used there.
> I'm afraid removing it might cause a regression.
> 

There is no comment left on the setTimeout code, and even module owner doesn't know what this is for? The magic setTimeout with 50 ms was introduced in bug 944068 by :ranbena, and r+ by you. I supposed one of you should be able to answer why we need this.

Comment 45

[Evelyn Hung]

(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #26)
> Created attachment 8467701 [details] [review]
> PR to v1.4
> 
> based analysis on comment 24, I come up with the patch.
> 
> Hi Amir,
> Could you help to review the patch? Thanks
> 
> Hi William,
> Could you help to verify if this patch works? Thanks.

@dwi2, it's better to explain what's your finding of the issue and why your patch should work when you ask someone's review.

Comment 46

[Tzu-Lin Huang [:dwi2][:tzhuang]]

My observation was:
If any call to Evme.Collection.hide() (https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/modules/Collection/Collection.js#L359) happens in between the two asynchronous method calls,

  1. https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/modules/Collection/Collection.js#L390
  2. https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/homescreen/everything.me/js/Brain.js#L947

we'll be unable to remove evme-collection-visible class anymore

So my assumption was: window.setTimeout could introduce async racing. But they are there for some reason. If we remove them all, we might have regression. I just tried to remove the setTimeout with non-zero value to see if it works, because I think setTimeout with non-zero latency has a lot more chance to introduce async racing than setTimeout with zero latency.

However, it could still be reproduced. I guess there are some more detail I didn't notice.

Comment 47

[Ran Ben Aharon [:ranbena] EverythingMe]

We used timeouts mostly in order to force re-layout, for animations to work properly.
I suggest trying to use the "clientLeft" trick instead. It's synchronous and low risk imo.

Comment 48

[William Hsu [:whsu]]

(In reply to Evelyn Hung [:evelyn] from comment #43)
> (In reply to William Hsu [:whsu] from comment #39)
> > Hi, everyone,
> > 
> > After I finished following tests, I still can reproduce this bug with this
> > patch (attachment 8467701 [details] [review]).
> > Do it cause by other factors?
> > - 6 Hours monkey test.
> >   ~ Cannot reproduce.
> > - 100 times automation test via Gaia UI test. (Demo video:
> > http://youtu.be/n7MGZqVY_OE )
> >   ~ Cannot reproduce.
> > - 5 Minutes manually test
> >   ~ Reproduced as attachment shown (WP_20140818_007.mp4)
> > 
> 
> Hi William,
> Your video doesn't show how you reproduce the issue, it starts from the
> issue has already occurred. It doesn't help on debugging. May I know how you
> manually reproduce it? Thanks.

Hey, Evelyn,

Thanks for the reminder.
I reproduce it via comment 10 reproduce steps.
But, the reproduce rate is low.(10%~20%)

Comment 49

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Hi Ran,

Did you mean that I can replace window.setTimeout with clientLeft trick like this:

     // original
     window.setTimeout(function() {
       var elAffectedByCollection = document.getElementById('icongrid');
       elAffectedByCollection.classList.add(CLASS_WHEN_COLLECTION_VISIBLE);
     }, 50);

     // with clientLeft trick
     var elAffectedByCollection = document.getElementById('icongrid');
     elAffectedByCollection.classList.add(CLASS_WHEN_COLLECTION_VISIBLE);
     elAffectedByCollection.clientLeft; // force reflow
  
Thanks

Comment 50

[Ran Ben Aharon [:ranbena] EverythingMe]

Exactly, but force reflow before class change

>    var elAffectedByCollection = document.getElementById('icongrid');
>    elAffectedByCollection.clientLeft; // force reflow
>    elAffectedByCollection.classList.add(CLASS_WHEN_COLLECTION_VISIBLE);

Comment 51

[Tzu-Lin Huang [:dwi2][:tzhuang]]

[Blocking Requested - why for this release]:

I'll have to ask if this still a blocker? Because:
 
1. It is first set blocker because it block partner's monkey test
2. The patch https://github.com/mozilla-b2g/gaia/pull/22518 did not work for STR in comment 39. However, we are unable to reproduce the problem using monkey test with the patch. (see comment 34 and comment 39).
3. Manual STR is somewhat awkward and beyond normal usage. (How many user would keep tapping music and home button interchangeably for 5 to 10 minutes?)

Comment 52

[Danny Liang [:dliang]]

Update the test result on monkey test, we could not reproduce this issue by running 60hr monkey test on 3 devices.

Comment 53

[Wayne Chang [:wchang]]

1.4- as low to zero occurrence rate.

If anyone sees this more frequently or proven critical please renom.

Comment 54

[Kevin Grandon :kgrandon]

Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.