991906 - [B2G][Homescreen] Long pressing an App that opened in Landscape mode will cause the Dock apps to shift

Status: RESOLVED FIXED

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

Description

[Josh Schmitt [Joshs]]

Attachment: DockApp.mpeg

Description:
Apps on the Dock app move to the right making the Browser off screen.

Repro Steps:
1) Updated Buro to BuildID: 20140403040201
2) Proceed to the Marketplace
3) Download and install Cut the Rope
4) Launch Cut the Rope
5) Press the Home button
6) Long press on Cut the Rope

Actual:
The apps on the Dock app shift to the right and the browser app is off screen.

Expected:
The apps on the Dock app do not change.

Environmental Variables:
Device: Buri 1.5 MOZ
BuildID: 20140403040201
Gaia: 0e974ff33ba47f3d1e59df1e0ad534f1bbe3ef8a
Gecko: 91be2828f17e
Version: 31.0a1
Firmware Version: V1.2-device.cfg 

Notes:
Repro frequency: 100%
See attached: Video

Comment 1

[Jason Smith [:jsmith]]

Let's confirm this doesn't happen on 1.5.

Comment 2

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #1)
> Let's confirm this doesn't happen on 1.5.

1.4 I mean - confirm this doesn't reproduce there.

Comment 3

[Cristian Rodriguez (:crdlc)]

Maybe it is the problem recently landed

https://github.com/mozilla-b2g/gaia/commit/49852969756c290c96b7b03af1d214470e57c540

When the homecreen is in foreground, when it receives the event "visibilitychange" the innerWidth could be landscape instead of portrait

George, could you take a look? thx

Comment 4

[Harvey]

This issue does NOT reproduce on the latest 1.4

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140404000202
Gaia: b4f3b84ec68233a99fd5865c15cfe28aebe26531
Gecko: 3186bbc50050
Version: 30.0a2
Firmware Version: v1.2-device.cfg
(This issue is easily reproduce able on 1.5)

Comment 5

[Harvey]

B2G Inbound Regression Window:

Last Working

Device: Buri 1.5 MOZ
BuildID: 20140402130133
Gaia: 208d70961b6e3f615b9195d9558157bf7b1fdd28
Gecko: ba30e8f5d6b4
Version: 31.0a1
Firmware Version: v1.2-device.cfg

First Broken

Device: Buri 1.5 MOZ
BuildID: 20140402135236
Gaia: ef6fdfd09bbd0003db2e085efd6e0fe49d42aa18
Gecko: 686ba9b80f25
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Last Working Gecko First Broken Gaia: Issue DOES reproduce
Gaia: ef6fdfd09bbd0003db2e085efd6e0fe49d42aa18
Gecko: ba30e8f5d6b4

First Broken Gecko Last Working Gaia: Issue does NOT reproduce
Gaia: 208d70961b6e3f615b9195d9558157bf7b1fdd28
Gecko: 686ba9b80f25

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/208d70961b6e3f615b9195d9558157bf7b1fdd28...ef6fdfd09bbd0003db2e085efd6e0fe49d42aa18

Comment 6

[Jason Smith [:jsmith]]

bug 990435 caused this regression.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #6)
> bug 990435 caused this regression.

Which apparently is present on 1.3T as well.

Comment 8

[(Inactive after June) George Duan [:gduan] [:喬智]]

In reply to https://bugzilla.mozilla.org/show_bug.cgi?id=990435#c28 ,
if homescreen is launched in the background and the foreground app is landscape, then we still get incorrect width.

To solve this bug and bug 990435, I suggest to cache width and height in each function instead of in the beginning.
What do you think?

Comment 9

[Cristian Rodriguez (:crdlc)]

I think that the root cause is not in the homescreen app. This is only rendered as portrait so when it receives the "visibilitychange" event and it is visible the correct width and height should be the values according to its orientation. It is not working in this way because the width received is in landscape (latest app in foreground). What do you think Vivien?

Comment 10

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

triage: 1.3T+ for regression.

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Cristian Rodriguez (:crdlc) from comment #9)
> I think that the root cause is not in the homescreen app. This is only
> rendered as portrait so when it receives the "visibilitychange" event and it
> is visible the correct width and height should be the values according to
> its orientation. It is not working in this way because the width received is
> in landscape (latest app in foreground). What do you think Vivien?

I think there could be a bad condition in the system app that resize the homescreen app to the orientation of the app that is targetted to be opened. Sounds like a system app issue to me.

Comment 12

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

Vivien or Alive, wonder if any one of you will be able to take this bug and look further? thanks

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Looking but I wonder this is not a problem we should fix for v1.3
The problem might be the timing issue of visibilitychange & orientationchange.
We do set visibility & lock orientation on homescreen 'opening' process but it depends how fast we get resize event from gecko to resize the homescreen.

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

Cannot reproduce with latest 1.5, what's missing?

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

Hmm cannot reproduce with 1.3T though I am not using tarako. Device only issue?

Comment 16

[Jason Smith [:jsmith]]

Let me have someone re-check this on the latest 1.3T & 1.5 build.

Comment 17

[(Inactive after June) George Duan [:gduan] [:喬智]]

If pb remains, based on comment 13 and comment 8,
1. we can add timer to set windowWidth after receiving visibilitychange event as a workaround.
2. as comment 8, replace all windowWidth with window.innerWidth.
3. backout 990435, since original bug has no STR yet.

Comment 18

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

We might have have a proposed solution in cards_view.js. George will try out.

Comment 19

[(Inactive after June) George Duan [:gduan] [:喬智]]

I can reproduce comment 0 without entering card view, so it might not relate to card_views.js.

Comment 20

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

to George for now  per comment 18

Comment 21

[(Inactive after June) George Duan [:gduan] [:喬智]]

The quickest workaround is to get screen.width as windowWidth inside dock.js and it can prevent this bug 990435 and this one.

Hi Chris,
could you advise?

Comment 22

[Cristian Rodriguez (:crdlc)]

Do you have a pr to see the code? 10x

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Sounds like people are working on it. Removing the needinfo :)

Comment 24

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

Back to be a Homescreen bug.

Comment 25

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

George, any update?

Comment 26

[Cristian Rodriguez (:crdlc)]

Hi Tim, I don't understand why we have to do a workaround in homescreen per comment 11 when it seems a race condition in another part. If I am in portrait and the "visibilichange" event says to me, hey window, you are visible right now. And then immediately if I ask for the window width, it would be the correct one according to my orientation. And it fails. What is the rationale for adding new workarounds instead of fixing the root problem?

Comment 27

[Cristian Rodriguez (:crdlc)]

Forgot to add the ni

Comment 28

[(Inactive after June) George Duan [:gduan] [:喬智]]

Hi Jason,
it seems only reproducible on master, not 1.3t.

Comment 29

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Cristian Rodriguez (:crdlc) from comment #26)
> Hi Tim, I don't understand why we have to do a workaround in homescreen per
> comment 11 when it seems a race condition in another part. If I am in
> portrait and the "visibilichange" event says to me, hey window, you are
> visible right now. And then immediately if I ask for the window width, it
> would be the correct one according to my orientation. And it fails. What is
> the rationale for adding new workarounds instead of fixing the root problem?

What's killing us is the timing to do screen orientation lock.
If we lock the orientation just after the homescreen is opening and at the same time the app is closing, you will see the closing app is at wrong position. If they have perpendicular orientation settings.
If we lock the orientation just after the homescreen is opened and at the same time the app is closed, we will see the opened homescreen is at wrong position. If they have perpendicular orientation settings.

We won't have a good solution until we have better control over the orientation for the app but not for the whole screen. This needs gecko API change.

Comment 30

[Cristian Rodriguez (:crdlc)]

I would like to be pragmatic here so go ahead with a workaround but please fill a new bug to fix the root cause and after fixing that, this workaround should be removed from Gaia. Does it work for you?

Comment 31

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

Yes, I told Alive to file a bug any maybe work on a proposal after 1.3T and anything else.

Comment 32

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

George, could you update the status of this bug? What's the definite STR we are looking at and what is reproducible only on master?

Comment 33

[(Inactive after June) George Duan [:gduan] [:喬智]]

I simplify the steps from comment 0 and find out it's not reproducible on 1.3t branch. Only on master.

Repro Steps:
1) Launch any landscape app
2) Press the Home button
3) Long press on any app

Actual:
The apps on the Dock app shift to the right and the browser app is off screen.

Expected:
The apps on the Dock app do not change.

Comment 34

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

OK, so it's this still a 1.3T bug? (qawanted)

Comment 35

[Jason Smith [:jsmith]]

(In reply to George Duan [:gduan] [:喬智] from comment #28)
> Hi Jason,
> it seems only reproducible on master, not 1.3t.

ok - I'll leave qawanted to confirm this does not reproduce on Tarako. I'll get this out of the triage bucket though and move it 2.0?

Comment 36

[Josh Schmitt [Joshs]]

(In reply to Jason Smith [:jsmith] from comment #35)
> (In reply to George Duan [:gduan] [:喬智] from comment #28)
> > Hi Jason,
> > it seems only reproducible on master, not 1.3t.
> 
> ok - I'll leave qawanted to confirm this does not reproduce on Tarako. I'll
> get this out of the triage bucket though and move it 2.0?

I was unable to repro on the latest 1.3T build following the simplified steps in comment 33.

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140410004001
Gaia: 022b03a57e4b8c697a6066961e7581d07eb99305
Gecko: b9dba13d50a9
Version: 28.1
Firmware Version: Sp6821a

Comment 37

[bhavana bajaj [:bajaj]]

Blocking for 2.0 as this is a regression given the STR in comment #33

Comment 38

[Cristian Rodriguez (:crdlc)]

I gonna try to work on it today

Comment 39

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Thanks in advance for the review

Comment 40

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 8410123 [details]
Patch v1

Please fix the nits on github before landing. Otherwise this sounds good.

Comment 41

[Cristian Rodriguez (:crdlc)]

Merged in master:

https://github.com/mozilla-b2g/gaia/commit/6a2eb4b3664fb3e6f5c87db2af8485b7424f9ecb

Comment 42

[yaoyao.wu]

(In reply to Cristian Rodriguez (:crdlc) from comment #41)
> Merged in master:
> 
> https://github.com/mozilla-b2g/gaia/commit/
> 6a2eb4b3664fb3e6f5c87db2af8485b7424f9ecb

Hi Cristian,
Could the patch be merged  in gaia v1.4t ? similar problems appears in v1.4t.
Thanks!

Comment 43

[Cristian Rodriguez (:crdlc)]

Yes, why not :), the merge won't be clean but feasible. Maybe an approval should be asked thought. If managers will decide that it can be uplifted and the cherry pick is not performed cleanly I could take a look. Thanks

Comment 44

[James Zhang (Spreadtrum)]

We meet Bug 990435 in v1.4, we'll land this bug patch on v1.4 to verify.

Comment 45

[Jason Smith [:jsmith]]

(In reply to James Zhang (Spreadtrum) from comment #44)
> We meet Bug 990435 in v1.4, we'll land this bug patch on v1.4 to verify.

I don't think this is the right bug to uplift. We already confirmed this isn't present on 1.4 & there are no plans to uplift bug 990435 to 1.4.

Comment 46

[yang.zhao]

(In reply to Jason Smith [:jsmith] from comment #45)
> (In reply to James Zhang (Spreadtrum) from comment #44)
> > We meet Bug 990435 in v1.4, we'll land this bug patch on v1.4 to verify.
> 
> I don't think this is the right bug to uplift. We already confirmed this
> isn't present on 1.4 & there are no plans to uplift bug 990435 to 1.4.
Hi,Jason
    The homescreen icon overlapped and the dock icon missing are all because of getting a wrong value of windowWidth.This patch modifies the way to get windowWidth value . Although the description of this bug doesn't happen on v1.4 ,but the way to get windowWidth value is helpfull.

Comment 47

[Jan Jongboom [:janjongboom] (inactive)]

Comment on attachment 8410123 [details]
Patch v1

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

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Originally bug 990435, but there is more to the eye.
[User impact] if declined: This shifts homescreen icons in dock on Dolphin in 1.4 as well, and blocks bug 995886 which we probably want in 1.4.
[Testing completed]: Yes on 1.3t and 2.0
[Risk to taking this patch] (and alternatives if risky): I think it's pretty low risk, the previous behavior was wrong. We can combine the content of this patch in bug 995886 but that would only mask this issue.
[String changes made]: None

Comment 48

[Jan Jongboom [:janjongboom] (inactive)]

Attachment: Patch for v1.4

Comment 49

[Jan Jongboom [:janjongboom] (inactive)]

nom for 1.4 because depending bug 995886 is 1.4+

Comment 50

[Preeti Raghunath(:Preeti)]

Comment on attachment 8445733 [details] [review]
Patch for v1.4

Based on comment 45 where this fix is not needed, not approving for 1.4

Comment 51

[yang.zhao]

(In reply to Preeti Raghunath(:Preeti) from comment #50)
> Comment on attachment 8445733 [details] [review]
> Patch for v1.4
> 
> Based on comment 45 where this fix is not needed, not approving for 1.4

Please see bug 995886 comment#77 and the STR in bug 1029306.
Without 991906's patch ,the icons on homescreen will be overlapped and also in a wrong size.
With 991906's patch, the icons on homescreen WON'T be overlapped,but still in a wrong size.

In a word ,attachment 8445733 [details] [review] which include this bug's patch could resolve both the 'overlapp' and 'wrong size' issue .

Comment 52

[Jason Smith [:jsmith]]

Moving back to 2.0+ since we aren't taking the regressing patch to 1.4.

Comment 53

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

This bug was not reproduced on 1.4 Buri from comment 4, but I think we should consider this affects Dolphin on 1.4 since the vendor has report back to us on this.

qawanted to re-confirm this on Dolphin.

Comment 54

[Joshua Mitchell (Inactive)]

qa-wanted team does not have Dolphin Devices

Comment 55

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #53)
> This bug was not reproduced on 1.4 Buri from comment 4, but I think we
> should consider this affects Dolphin on 1.4 since the vendor has report back
> to us on this.
> 
> qawanted to re-confirm this on Dolphin.

The bug as filed here originally targeted Buri, so I don't think we need to cross-check here on Dolphin.

Comment 56

[James Zhang (Spreadtrum)]

Yang, please reproduce it on 1.4.

Comment 57

[yang.zhao]

(In reply to James Zhang (Spreadtrum) from comment #56)
> Yang, please reproduce it on 1.4.
This bug doesn't reproduce on 1.4,BUT please see comment 51,the patch of this bug is really needed!

Comment 58

[William Hsu [:whsu]]

Needinfo "whsu" to see if whsu can reproduce it on Dolphin.

Comment 59

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

I followed comment 0 but could not reproduce this bug on Dolphin and Flame v1.4.

Test build
-------------------------------------------------------------------------------------------------
Gaia 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/83b7be7fb33f
BuildID 20140721000201
Version 30.0
ro.build.version.incremental=282
ro.build.date=Thu Jul 10 10:27:07 CST 2014

@yang, following the same steps does not reproduce this bug on dolphin, it means the homescreen icon overlap bug on dolphin may be caused by different reason. Although this patch may help, it might not be able to solve the problem completely.

So I think we'd better file another bug to track dolphin problem.

Comment 60

[William Hsu [:whsu]]

Thanks Peipei!
I also cannot reproduce it on Dolphin.

* Build information:
 - Gaia      621d152f89347c79619aa909ad62cc2ac9d3ab5b
 - Gecko     8d1beb4aa6f463361e08c94fb5763b37967f70c3
 - BuildID   20140721185338
 - Version   30.0