877081 - [Homescreen] Logo stays forever after the quick access bar crashed

Status: VERIFIED FIXED

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

Description

[Walter Chen[:ypwalter][:wachen]]

Attachment: screenshot

Ikura(Open) v101 only - MOVISTAR 20130529
I am not able to reproduce it in master/v101/v110 of Unagi

STR:
  1. Try to move in icons from homescreen to quick access bar till full.
  2. Try to move out icons from quick access bar to homescreen
  3. Repeat this for few times

Expected result:
  Work as usually, you can move the icon around

Actual result:
  The quick access bar crashed and whenever you move the icon, icon would be everywhere.

Comment 1

[Walter Chen[:ypwalter][:wachen]]

Attachment: screenshot

Comment 2

[Walter Chen[:ypwalter][:wachen]]

Sorry, it now reproduced in Unagi V101. However, it is a little bit harder to trigger this.

Comment 3

[Cristian Rodriguez (:crdlc)]

Do you have logs? Could you record a video? Thanks

Comment 4

[Walter Chen[:ypwalter][:wachen]]

We will try to get you one video later.
Just a note, the only way to recover from the crashed homescreen is to reboot.

Comment 5

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

video here:
https://docs.google.com/a/mozilla.com/file/d/0B-FHjXny08MteXdOVU9jaEtQOWs/edit

Comment 6

[Cristian Rodriguez (:crdlc)]

perfect!! It is easy to reproduce! Working on it

Comment 7

[William Hsu [:whsu]]

Hi, all,

I can reproduce it on v1.0.1 and v1.1.0 (unagi).

* Reproduction build:v1.1.0 (Mozilla-b2g18-unagi-eng/20130527070208)
  + Mercurial-Information
    - Gecko revision="9cac5a5c4efb"
    - Gaia revision=""
  + Git-information
    - Gecko revision="39c9d5a5c09dfb942bb31d055ee04351c5416ad8"
    - Gaia revision="4d10e1297b859cacc174c0a54af61a7678d7c32d"

Thanks!

Comment 8

[William Hsu [:whsu]]

Attachment: HomeScreen

Comment 9

[Cristian Rodriguez (:crdlc)]

If I add a patch here right now, could you test it?

Comment 10

[Al Tsai [:atsai]]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #9)
> If I add a patch here right now, could you test it?

I believe in so. Or, I can test the patch. Thanks.

Comment 11

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1 (v1.0.1)

Comment 12

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 755268 [details]
Patch v1 (v1.0.1)

Simple patch, tried on the v1.0.1 and working as expected.

Thanks Cristian for the quick fix.

Comment 13

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1 (v1-train)

Comment 14

[Cristian Rodriguez (:crdlc)]

v1.0.1

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

Comment 15

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 755279 [details]
Patch v1 (v1-train)

r+

Comment 16

[Cristian Rodriguez (:crdlc)]

v1-train:

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

Comment 17

[Walter Chen[:ypwalter][:wachen]]

I still see it reproduce in MOVISTAR build :P

Comment 18

[Cristian Rodriguez (:crdlc)]

Bad news :( Francisco and me didn't see after applying patch. I want to be sure, please, tell me, are you sure that the patch has been applied? What do you mean Movistar build? Thanks

Comment 19

[Cristian Rodriguez (:crdlc)]

and please attach us 'adb logcat | grep GeckoConsole' when it fails, thanks

Comment 20

[Walter Chen[:ypwalter][:wachen]]

woops...
Ok, I will retry it in v1train build :P
Don't worry, MOVISTAR build is just for record.
There is a release build specificly for some company. :P

I will verify it and let you know maybe tmr pvt build.

If it do happen, I will attach the logcat. Thanks so much.

Comment 21

[Cody Roesch [:croesch]]

Inari Build: 20130530070213
Version: 18.0
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/11b55d3ada71
Gaia   ac293ce59acc3bede083fad1b973794fa8bf0253


Leo Build: 20130529070208
Version: 18.0
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/09ac1fd2959c
Gaia   1cca9324d4444ad28c6fa99875e17abf7e8230be


I am unable to reproduce the bug Inari device. However on the Leo Device V1 train I CAN get the bug to occur and cause a bit of a lock up with the app dragging from the App bar to the grid.

Comment 22

[Walter Chen[:ypwalter][:wachen]]

reopened. the fix supposed to be in V1train, but now V1train still doesn't work.

Comment 23

[Walter Chen[:ypwalter][:wachen]]

Still can reproduce it in Ikura partner 0531 build

Comment 24

[Cristian Rodriguez (:crdlc)]

Device: Unagi
Gaia: v1-train e1c59baed29e4665d1da9392f86239272073f07a
Gecko-45b1437

I cannot reproduce it and I don't have Ikura, can you reproduce on Unagi? Do you have a new video? new logs? Thanks

Comment 25

[Cristian Rodriguez (:crdlc)]

Reading flags I am lost Comment 21, status-b2g18: fixed → verified

Comment 26

[Cristian Rodriguez (:crdlc)]

is it verified on v1.0.1 or v1-train?

Comment 27

[Walter Chen[:ypwalter][:wachen]]

There is nothing verified in v101 or v1train now

Comment 28

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

batch update on tef+ milestones. partner to make a final on 6/3 Asia time. TEF+ needs to be resolved by 6/3 to be in the final build. thanks

Comment 29

[Cristian Rodriguez (:crdlc)]

I need help in order to solve the problem

> Device: Unagi
> Gaia: v1-train e1c59baed29e4665d1da9392f86239272073f07a
> Gecko-45b1437

> I cannot reproduce it and I don't have Ikura, can you reproduce on Unagi? Do you have a new video? new logs? Thanks

Comment 30

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

QAWANTED per comment 29

Comment 31

[Jason Smith [:jsmith]]

Please do not reopen bugs. File new bugs as dependencies as followups if the original bug does not work.

Comment 32

[Mila Davydova]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #29)

I don't have Ikura device, but I was not able to reproduce this issue on latest v1.1 on both Unagi and Leo devices

Leo Build ID: 20130531070205
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/4f318822e72c
Gaia: e1c59baed29e4665d1da9392f86239272073f07a
Version 18.0

Issue does not repro with latest v1.0.1 builds on both Unagi and Inari devices as well.

User is able to move app icons from quick access bar to home screen with no problem.

Comment 33

[Walter Chen[:ypwalter][:wachen]]

Jason Smith, 
I suggest that you don't do so next time to close a reopened bug.

There is nothing fixed per say:
It was landed in v1train. Per comment 21, it is still reproduced in v1train.
If it is reproduced in v1train, what did this patch fix then?

I won't reopen this, but I hope you understand there is a reason that there is a "reopen" option. Preventing from doing "reopening" doesn't mean too much things. Just make this hard to track. I almost reopen the bug right after they thought it is fixed but someone found that it is NOT FIXED.

I still think this should be reopened. However, I will try to verify if it is fixed later.

Comment 34

[Jason Smith [:jsmith]]

(In reply to Walter Chen from comment #33)
> Jason Smith, 
> I suggest that you don't do so next time to close a reopened bug.

Reopening in Bugzilla is meant for when a patch is backed out if it's coming from a FIXED state. The main reason for avoiding reopening for "this is not fixed" is mainly due to the need to track a consistent landing and blocking flag. If we for example, reopened the bug for an edge case not working, but sunny day cases work, that might move the bug to a non-blocker. That's where confusion can happen - you'll have a bug switch states when it shouldn't.

> 
> There is nothing fixed per say:
> It was landed in v1train. Per comment 21, it is still reproduced in v1train.
> If it is reproduced in v1train, what did this patch fix then?

In some cases a patch can fix one issue involving the problem but not all of them. Other cases the patch might fix the underlying issue but reveal a different problem. Or it might reproduce the rate of occurrence.

> 
> I won't reopen this, but I hope you understand there is a reason that there
> is a "reopen" option. Preventing from doing "reopening" doesn't mean too
> much things. Just make this hard to track. I almost reopen the bug right
> after they thought it is fixed but someone found that it is NOT FIXED.

If you have a problem with how we do bugzilla workflows with the reopen status, take this to dev-platform. I thought I already sent an email earlier showing you the discussion that made this decision in history why this was the case to aim to file new bugs. 

Keep in mind tracking here is really important. We'll throw people off if a bug previously known as a blocker goes to non-blocker on a reopen. Or tracking flags won't be reset on a reopen. etc.

Comment 35

[Walter Chen[:ypwalter][:wachen]]

Verified fixed in 2013/06/16 V1train pvt build.
Gaia:     f2d6ed54a236e6e3b94f0abad9f0dacb8a1cc7b3
  B-D     2013-06-15 07:33:44
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/15d9885034a0
BuildID   20130616070209
Version   18.0

Comment 36

[Walter Chen[:ypwalter][:wachen]]

Hi, Croesch,
I think we actually need more than this to cover this.

Suggested that opening some test cases to move between borders of the screen and borders of the access bar.

Thanks a lot.

Comment 37

[Cody Roesch [:croesch]]

Hi Walter,
   I've now created 2 new cases that I hope will cover areas you were talking about.

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=9285

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=9288

If you are satisfied then you can removed the Needinfo. If you need something else please be very specific in how you want it described.

Thanks

Comment 38

[Walter Chen[:ypwalter][:wachen]]

Thanks for the helping. It's all cool now.