896873 - [B2G][Helix][Icon]After upgrade the OS, all of the icons are grey.

Status: VERIFIED FIXED

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

Description

[HanCheng]

Attachment: IconError.png

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; aff-kingsoft-ciba)

Steps to reproduce:

1. Flash the UPDATE.APP(production version).
2. Reboot the device manually.
3. After first boot to OS, the device reboot automatically.



Actual results:

1. All the icons are grey. Please refer to the attached file.


Expected results:

1. All the icons are normal.

[Questions]
After first boot, we need to auto reboot the device to enable nv items. But if we reboot too early, the icons will be destroyed. 
If we don't do this reboot after first boot to OS, the icons are normal.

So, is there any APIs that we can call to get the status of the icons? Then we can reboot after the icons have got ready.

Comment 1

[Swaroopa Vantipalli [:swaroopa]]

Might be dupe of this bug: 893932

Comment 3

[Wayne Chang [:wchang]]

keven, can you assign someone to follow this bug with partner?

Comment 4

[Keven Kuo [:kkuo]]

Hi! 

We got a system property "sys.boot_completed".
It was set when Firefox os boot complete.
As we discussed yesterday, you can refer to this property and decide when to reboot system in Factory image.

--
Keven

Comment 5

[Wayne Chang [:wchang]]

Hi HanCheng,
Can you follow Keven's suggesting in comment 4 here and test this out?
If it works please include it in next week's release.

Thank you.

Comment 6

[HanCheng]

Hi Wayne,
Thanks very much. We can access the "sys.boot_completed".

There is another question. Is there any API that can block the screen befor the OS call any apps? We need to reboot system in Production image befor the user run any apps.

Comment 7

[Wayne Chang [:wchang]]

Hi HanCheng, You can use Bugzilla's "needinfo" to get other people's attention, no need to re-assign the bug. :)

HanCheng, do you think this is required? it will happen during the first time boot up only right?
How long after the boot up will you reboot? maybe it is quicker than user can start using device.



needinfo Keven to help with question in comment 6.

Comment 8

[HanCheng]

Hi Wayne,

Thanks, I will use the "needinfo".

Yes, the auto reboot will happen during the first time boot up only.
The device reboot about 6 seconds after the "powered.png" is shown.

Comment 9

[lecky]

Hi All

     We have tried not restart the phone in the first boot, until the "sys.boot_completed" change to "1". But the Icons still possibly missing. Do you have any suggestion?

Detail:
     We have started a service named "rebootmgr" to decide whether the device should reboot. And now we add the refference to the property in this service, before it reboot the device.

BR.

Comment 10

[Keven Kuo [:kkuo]]

Hi! lecky,

Do you mean this issue still occurs even to reboot the system right after "sys.boot_completed" set?
How about to wait 3 more seconds after "sys.boot_completed"? Just for debugging.

BR,
Keven

Comment 11

[lecky]

Hi Keven

    I will check to wait 3 more seconds after "sys.boot_completed".

    I have checked that after the reset the device by "setting->more inforation->reset phone", the issue will happen probably if the device power loss in the first time boot up.
    For this senario, I have poll out the /data and the /cache from the device. The /cache are almost the same, while the /data are different. I will attatch the snapshot where questionable

    But the way, I have make a build to reboot during the first bootup, after the device after the device hard reseted. Could you help to repo in your device?

BR,
Loren

Comment 12

[lecky]

Attachment: IconGrey_or_IconLoss.zip

Comment 13

[lecky]

Hi Keven
     I have make a build to reboot the device 5 seconds after the "sys.boot_completed". the test result is that the issue still happen.
     1>. before the device reboot, I can see the lock screen for more than 2 seconds.
     2>. unlock the screen before the device reboot, I can see, at a glance, that the icon is ok. But the icon may turn grey and abnormal after reboot.

     To summarize, this issue may happened in the senarios:
     1>. happens in the end user senario that, power loss during the device's first bootup after purchase.
     2>. happens in the end user senario that, power loss during the device's first bootup after the software update or cold reset.
     3>. happens in the factory after the device flashed the production image.
     4>. happens in the factory after the device resore factory setting(cold reset) after all test finished.

Comment 14

[lecky]

Hi Keven
     I have make a build to reboot the device 5 seconds after the "sys.boot_completed". the test result is that the issue still happen.
     1>. before the device reboot, I can see the lock screen for more than 2 seconds.
     2>. unlock the screen before the device reboot, I can see, at a glance, that the icon is ok. But the icon may turn grey and abnormal after reboot.

     To summarize, this issue may happened in the senarios:
     1>. happens in the end user senario that, power loss during the device's first bootup after purchase.
     2>. happens in the end user senario that, power loss during the device's first bootup after the software update or cold reset.
     3>. happens in the factory after the device flashed the production image.
     4>. happens in the factory after the device resore factory setting(cold reset) after all test finished.


BR,
Loren

Comment 15

[Wayne Chang [:wchang]]

lecky,

just to test, can you try not doing a reboot?
make sure you finish the first time guide (FYI, Mozilla refers to this as FTU or FTE) process, then reboot and see if any icon still missing.

Keven, any more insights?

Comment 16

[Loren]

Hi Wayne

    To wait enough time, the icon is OK after reboot.
 
    1.Do you have a doc that talk about the gaia/gecko processing during the first bootup? 
    2.Have you tried to reproduce this on helix?

BR.
Loren.

Comment 17

[Keven Kuo [:kkuo]]

Hi! Loren,

1. We don't have a doc about the first boot up.
2. So far, I tried 5 or 6 times but was not able to see this case.

--
Keven

Comment 18

[lecky]

Attachment: rebootafterREST.part1.rar

Comment 19

[lecky]

Attachment: rebootafterREST.part2.rar

Comment 20

[lecky]

Hi Keven

    I have attached the update.app(rebootafterREST) that will reboot the device during the first bootup, after the device been hard reseted. please download and make a test.

BR.
Loren

Comment 21

[Keven Kuo [:kkuo]]

Hi! lecky,

After updated the image release at 8/5, our device is not able to get into download mode.
It means I am not able to update your test image.

--
Keven

Comment 22

[lecky]

Hi Keven

    For the update problem, please refer the email I just sent to you.

    By the way, do you have any suggestion about where and how can we investigate this problem in our side?

BR.
Loren.

Comment 23

[Marco Chen [:mchen]]

(In reply to Wayne Chang [:wchang] from comment #15)
> lecky,
> 
> just to test, can you try not doing a reboot?
> make sure you finish the first time guide (FYI, Mozilla refers to this as
> FTU or FTE) process, then reboot and see if any icon still missing.

Hi Lecky,

Q1: Could you reset the phone after finishing the FTU but not before FTU?

  It seems that if you reset the phone before FTU then user can not see FTU at next boot also.
  And if you can reset the phone after finishing the FTU, we can find a way to do this.

Thanks.

Comment 24

[William Hsu [:whsu]]

I cannot reproduce this bug on the following build. The assets display correctly.
* Test build:(Mozilla-b2g18_v1_1_0_hd-helix/2013-08-12-04-22-03)
  + Mercurial-Information
    - Gecko revision="afd50da34b9f"
  + Git-information
    - Gaia revision="134356dc21d0627455f8bc536b140a18f39e20e9"

Comment 25

[William Hsu [:whsu]]

Sorry! Skip my result. Update the wrong case.

Comment 26

[lecky]

Hi Marco

    Could you give us a demo to gracefully reboot the device after FTU? Which means to give a notice to the user and execute reboot.

    To be honestly, I don't think it is a good way to promote a reboot after FTU. But if you can give a demo, we can evaluate it internally . 
   
    thanks.

BR.
Loren.

Comment 27

[Marco Chen [:mchen]]

(In reply to lecky from comment #26)
> Hi Marco

Hi Lecky, the problem of reboot before FTU is that user will not see FTU if you directly reboot the device on first power on. This will be a problem.

Or you can add description into FTU page for notifying user about the reboot and I think this will be more friendly to user. Or as a User I don't know why device will be rebooted at first power on.

This is not a standard request on general product line, so could you customize it on your side? Thanks.

Comment 28

[lecky]

Hi Marco

   I have made a test as under your suggestion. Add a reboot by calling navigate.mozPower.reboot() in function fl_close() of ftu_launcher.js, the icon gray or icon missing problem do not reproduce. We are evaluating this solution internally these days based on this test result. But there are some questions block us:
   1>. As you said if we reboot before FTU during the first boot up, the user will not see the FTU on the second time. But actually the FTU will be called on the second boot up.
   2>. This solution cannot solve the problem in the case that the probably power loss in the first boot up before the FTU.
   3>. Could you give us a explain why this problem happens?
   4>. Could you make more stable way, such as to set a flag when all data are ready and check this flag in every boot.

BR. 
Loren.

Comment 29

[Wayne Chang [:wchang]]

Hi Lecky,
You can get your questions noticed more if you use the need more information flag?

Comment 30

[Marco Chen [:mchen]]

(In reply to lecky from comment #28)
>    1>. As you said if we reboot before FTU during the first boot up, the
> user will not see the FTU on the second time. But actually the FTU will be
> called on the second boot up.

A: Ok. Thanks. Then please ignore this concern. Sorry for misleading this.

>    2>. This solution cannot solve the problem in the case that the probably
> power loss in the first boot up before the FTU.

A: This will be a generic issue and we can fire another bug to discuss this.

>    3>. Could you give us a explain why this problem happens?

A: I didn't know this actually, and we can discuss with others on the new bug opening for your question 2.

>    4>. Could you make more stable way, such as to set a flag when all data
> are ready and check this flag in every boot.

A: Same comment as question 2 and 3.
> 
> BR. 
> Loren.

By the way, is put the first reboot into the end of FTU with specific message the possible solution here?

Thanks.

Comment 31

[lecky]

Hi Marco

   By adding the reboot into the end of FTU, the problem do not exist. 
   But after our internal evaluation, especialy complying with our product manager's opinion, we can not accept to reboot device after FTU. Because this will lead to a bad user experience. 
   We consider that this is a defect of b2g system, and it should be solved. Because we have added reboot at a same time same way to the same purpose in millions of our Android devices, there is no such problem. So we want to find a way to solve this under your help.
   1>.Could you give us some suggestions about how to investigate this problem?
   2>.Can we block the system in the third logo when booting up, we want to check to do the reboot here and make an evaluation again.
   

BR.
Loren

Comment 32

[Marco Chen [:mchen]]

Hi Loren,

I will try to dig it out and reply to you.

But it is still strange to me that you think it is a bad UX by prompting user about "there is a reboot" after FTU. And "Not notice user anything then reboot" is a good UX.

As a user, it is more strange that device reboots without any reason.

Comment 33

[Marco Chen [:mchen]]

Hi Tim,

May I know your suggestion on the case as below?

  1. To flash the images into device.
  2. Boot up the device first time.
  3. During the device boot into first splash draw by Gaia, the battery is ran out and device is shutdown.
  4. After reboot again with good battery, all of the icons are grey in homescreen.

Thanks.

Comment 34

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Marco Chen [:mchen] from comment #33)
>   4. After reboot again with good battery, all of the icons are grey in
> homescreen.

Again, could you attach a screenshot? By "gray", you mean the default icons or the icons turned monotone (we do have this feature)? 

(please needinfo me again)

Comment 35

[Marco Chen [:mchen]]

Hi Tim

Is first attached picture not what you need?
Or please let me know what detail you want to know.

Thanks.

Comment 36

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am not familiar with that part of code but comment 23 sounds like a database state issue, where Homescreen app (particularly, HomeState in state.js) failed.

crdlc, could you be able to point out what's wrong?

Comment 37

[Cristian Rodriguez (:crdlc)]

Hi all,

   Maybe the device was rebooted when all icons were rendered by default and the database saved those blobs. There was not enough time to generate the correct icons and the database hasn't the correct ones. After rebooting the device, the homescreen gets the info from database and paints icons by default.

   Maybe at this point [1] we could check if the blob saved is the default icon. In this case, we could fetch the correct one (this code is performed when we receive the info from mozApps)

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/page.js#L400

if (descriptor.updateTime == oldDescriptor.updateTime &&
    descriptor.icon == oldDescriptor.icon &&
    oldDescriptor.renderedIcon !== GridManager.getBlobByDefault(app)) {

instead of

if (descriptor.updateTime == oldDescriptor.updateTime &&
        descriptor.icon == oldDescriptor.icon) {

What do you think Julien?

Thanks a lot

Comment 38

[Julien Wajsberg [:julienw]]

The problem is that we call "loadCachedIcon" very early so that we display an icon while the real icon is downloaded. And "loadCachedIcon" calls "loadDefaultIcon" because we don't have a cached icon yet, and "loadDefaultIcon" calls "renderBlob" which saves this default icon in the DB.

Cristian, I think that what you propose won't work because the new blob for the template icons won't be the same one as the one that was stored before.

And I think we should not _store_ the renderedIcon in the IndexedDB at all if we rendered a default icon. 

Then at the start of "loadDefaultIcon" we could set a boolean on the icon "isDefault: true", or maybe even on the descriptor if we want to persist it (but I doubt it's useful).

Then either (1) we store the default icon in renderedIcon as we do now, but we should implement a getIconDescriptor in Icon (that would get called by getIconDescriptors in Page) that would remove renderedIcon and oldRenderedIcon from the descriptor if isDefault is true. (BTW: shouldn't we always remove oldRenderedIcon when saving ?).

Either (2) we don't store the default icon in renderedIcon, but when "update" is called, if isDefault is true, then we call fetchImageData even if updateTime and icon have not changed.

Whichever solution we choose, at the next reboot, if we have no rendered icon in DB, the existing code should try to fetch it again.


I prefer the solution (1) because it's more "object" and (2) feels more hacky, but both solutions should work for me.

What do you think Cristian ?

Comment 39

[Cristian Rodriguez (:crdlc)]

I really think so, I prefer your option one too

Comment 40

[Julien Wajsberg [:julienw]]

So, Cristian, do you think you can do this, or should we find someone to handle it ?
I don't think I'll be able to do it before next monday.

This affects both hd and non-hd device, should we ask leo+ instead of hd+, or is this really only for hd ?

Comment 41

[Cristian Rodriguez (:crdlc)]

I will try to do this during this week, maybe Wednesday or Thursday

Comment 42

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Comment 43

[Julien Wajsberg [:julienw]]

Comment on attachment 796511 [details]
Patch v1

comments on github.

I love the simplicity of this.

Comment 44

[Cristian Rodriguez (:crdlc)]

addressed comments, please take a look, thanks

Comment 45

[Julien Wajsberg [:julienw]]

HanCheng, Lecky, could you please try the current patch and tell us if this fixes your problem ?

Comment 46

[Julien Wajsberg [:julienw]]

Comment on attachment 796511 [details]
Patch v1

r=me with the small nit

land this ! 

thanks Cristian, let's see if this works for our partners :)

Comment 47

[lecky]

Hi all

    We have made a self test based on your changes, and it works well now. Our test team will make a full test on it later. Will reply you soon.

    Thank you all!

Br.
Loren

Comment 48

[Cristian Rodriguez (:crdlc)]

Done, waiting for Travis build, thanks for all

Comment 49

[Cristian Rodriguez (:crdlc)]

Merged into master:

https://github.com/mozilla-b2g/gaia/commit/e217f6e01d424be2d5b31bd5fcf53bc7915a40a2

Comment 50

[William Hsu [:whsu]]

Could you please uplift patch to "V1.1.0" and "V1.1.0 hd"?
Thank you!

Comment 51

[Julien Wajsberg [:julienw]]

The patch is hd+, it means it will be merged to v1.1.0 hd only.

If you want it in v1.1.0 you have to ask leo? on it.

John, could you please do the uplift to v1.1-hd ?
Thanks

Comment 52

[John Ford [:jhford] CET/CEST Berlin Time]

There is a merge conflict when trying to uplift to hd in the following files:

	both modified:      apps/homescreen/js/page.js
	both modified:      apps/homescreen/test/unit/page_test.js

Comment 53

[Julien Wajsberg [:julienw]]

Cristian, will you do the uplift to the v1.1.0hd branch ?

Comment 54

[Cristian Rodriguez (:crdlc)]

I cannot do it today, if we can wait, I could do it on Monday, is it ok? Thanks

Comment 55

[Julien Wajsberg [:julienw]]

uplifted to v1.1.0hd: ea6be07f3ed146bbcd472ba23ed5ab1f541aedd0

Comment 56

[Al Tsai [:atsai]]

[2013/10/21 Helix Testing]
Gaia:     c829a2042594b6c3a4899ee27979799a0f301534
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/f7c657f6d019
BuildID   20131015042201
Version   18.0