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

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

(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.

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

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)

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

bug 990435 caused this regression.

(In reply to Jason Smith [:jsmith] from comment #6) > bug 990435 caused this regression. Which apparently is present on 1.3T as well.

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?

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?

triage: 1.3T+ for regression.

(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.

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

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.

Cannot reproduce with latest 1.5, what's missing?

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

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

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.

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

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

to George for now per comment 18

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?

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

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

Back to be a Homescreen bug.

George, any update?

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?

Forgot to add the ni

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

(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.

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?

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

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?

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.

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

(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?

(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

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

I gonna try to work on it today

Thanks in advance for the review

Comment on attachment 8410123 [details] Patch v1 Please fix the nits on github before landing. Otherwise this sounds good.

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

(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!

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

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

(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.

(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 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

nom for 1.4 because depending bug 995886 is 1.4+

Comment on attachment 8445733 [details] Patch for v1.4 Based on comment 45 where this fix is not needed, not approving for 1.4

(In reply to Preeti Raghunath(:Preeti) from comment #50) > Comment on attachment 8445733 [details] > 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] which include this bug's patch could resolve both the 'overlapp' and 'wrong size' issue .

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

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.

qa-wanted team does not have Dolphin Devices

(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.

Yang, please reproduce it on 1.4.

(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!

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

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.

Thanks Peipei! I also cannot reproduce it on Dolphin. * Build information: - Gaia 621d152f89347c79619aa909ad62cc2ac9d3ab5b - Gecko 8d1beb4aa6f463361e08c94fb5763b37967f70c3 - BuildID 20140721185338 - Version 30.0