Closed Bug 991906 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v1.3T unaffected, b2g-v1.4 unaffected, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 2.0+
Tracking Status
b2g-v1.3T --- unaffected
b2g-v1.4 --- unaffected
b2g-v2.0 --- fixed

People

(Reporter: jschmitt, Assigned: crdlc)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(3 files)

Attached video 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
Let's confirm this doesn't happen on 1.5.
blocking-b2g: --- → 1.5?
Keywords: qawanted, regression
(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
Flags: needinfo?(gduan)
QA Contact: jharvey
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
Blocks: 990435
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.
blocking-b2g: 1.5? → 1.3T?
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?
Flags: needinfo?(gduan) → needinfo?(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?
Flags: needinfo?(crdlc) → needinfo?(21)
triage: 1.3T+ for regression.
blocking-b2g: 1.3T? → 1.3T+
(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.
Flags: needinfo?(21)
Vivien or Alive, wonder if any one of you will be able to take this bug and look further? thanks
Flags: needinfo?(alive)
Flags: needinfo?(21)
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.
Flags: needinfo?(alive)
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.
Keywords: qawanted
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.
Status: NEW → ASSIGNED
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
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
Assignee: nobody → 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?
Flags: needinfo?(crdlc)
Do you have a pr to see the code? 10x
Flags: needinfo?(crdlc)
Sounds like people are working on it. Removing the needinfo :)
Flags: needinfo?(21)
Back to be a Homescreen bug.
Component: Gaia::System::Window Mgmt → Gaia::Homescreen
George, any update?
Flags: needinfo?(gduan)
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
Flags: needinfo?(timdream)
Hi Jason,
it seems only reproducible on master, not 1.3t.
Flags: needinfo?(gduan) → needinfo?(jsmith)
(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.
Flags: needinfo?(timdream)
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?
Flags: needinfo?(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.
Flags: needinfo?(gduan)
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?
blocking-b2g: 1.3T+ → 2.0?
Flags: needinfo?(jsmith)
(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
Keywords: qawanted
Blocking for 2.0 as this is a regression given the STR in comment #33
blocking-b2g: 2.0? → 2.0+
No longer blocks: 995886
I gonna try to work on it today
Assignee: gduan → crdlc
Attached file Patch v1
Thanks in advance for the review
Attachment #8410123 - Flags: review?(21)
Comment on attachment 8410123 [details]
Patch v1

Please fix the nits on github before landing. Otherwise this sounds good.
Attachment #8410123 - Flags: review?(21) → review+
Merged in master:

https://github.com/mozilla-b2g/gaia/commit/6a2eb4b3664fb3e6f5c87db2af8485b7424f9ecb
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [systemsfe]
Target Milestone: --- → 2.0 S1 (9may)
(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!
Flags: needinfo?(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
Flags: needinfo?(crdlc)
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
Attachment #8410123 - Flags: approval-gaia-v1.4?
Attached file Patch for v1.4
Attachment #8445733 - Flags: approval-gaia-v1.4?
Attachment #8410123 - Flags: approval-gaia-v1.4?
nom for 1.4 because depending bug 995886 is 1.4+
blocking-b2g: 2.0+ → 1.4?
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
Attachment #8445733 - Flags: approval-gaia-v1.4?
(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 .
Flags: needinfo?(praghunath)
Moving back to 2.0+ since we aren't taking the regressing patch to 1.4.
blocking-b2g: 1.4? → 2.0+
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
Keywords: qawanted
(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.
Flags: needinfo?(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!
Flags: needinfo?(yang.zhao)
Needinfo "whsu" to see if whsu can reproduce it on Dolphin.
Flags: needinfo?(whsu)
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.
See Also: → 1004329
Thanks Peipei!
I also cannot reproduce it on Dolphin.

* Build information:
 - Gaia      621d152f89347c79619aa909ad62cc2ac9d3ab5b
 - Gecko     8d1beb4aa6f463361e08c94fb5763b37967f70c3
 - BuildID   20140721185338
 - Version   30.0
Flags: needinfo?(whsu)
Flags: needinfo?(praghunath)
You need to log in before you can comment on or make changes to this bug.