[Flame][Homescreen]A partial facebook view overlaps on the top left corner of home screen.

VERIFIED FIXED in 2.2 S4 (23jan)

Status

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: wangxin, Assigned: gduan)

Tracking

unspecified
2.2 S4 (23jan)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v2.1 affected, b2g-v2.2 verified, b2g-master verified)

Details

Attachments

(3 attachments)

[1.Description]:
[Flame][v2.1&v2.2][Homescreen]When you back to homescreen from facebook page(in Contacts) in landscape mode, there is a partial facebook view overlaps on the top left corner of home screen.
Found Time:01:52
Bug log:"logcat_0152.txt".
Bug video:"0152.MP4".

[2.Testing Steps]: 
1. Launch "Contacts".
2. Press "gear" icon.
3. Enable "Sync firends" item.
4. Rotate device to landscape mode in "facebook" page.
5. Press Home button.

For Flame v2.1, after above steps,need to add the following steps:
6. Launch Gallery, and open a picture.
7. Rotate to landscape mode again.
8. Tap the "Camera" icon to invoke Camera.
9. Press Home button.

[3.Expected Result]: 
4.The Home page should display completely.

[4.Actual Result]: 
4. A partial facebook view will overlap on the left top corner of home screen.

[5.Reproduction build]: 
Flame 2.1:
Gaia-Rev        ed2e278753e8c9301ba322dcf2c3591f5928408d
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/127a0ead5f83
Build-ID        20150108001214
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150108.040209
FW-Date         Thu Jan  8 04:02:21 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build:
Gaia-Rev        d4dac29613076bdba3cb8adc217deadb08a2ac20
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/70de2960aa87
Build-ID        20150108010221
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150108.044406
FW-Date         Thu Jan  8 04:44:17 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]:
Free Test
Posted video Bug video: 0152.MP4
The problem is caused by sofware homwbutton, it won't have this problem if disable sofware homebutton.
Hi Mike,
Don't enable "sofware home button", this issue still exists
Flags: needinfo?(mlien)
Hi Alive, not sure if this is belong to system. Could you help to check with it, thanks.
Flags: needinfo?(mlien) → needinfo?(alive)
Bad :/

Could you help? A potential blocker.
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
Flags: needinfo?(alive) → needinfo?(gduan)
Assignee: nobody → gduan
Flags: needinfo?(gduan)
Posted file PR to master
The root cause is, when gaia gets orientationchange, it only resize the activeWindow instead of its childWindows. I think we should call resize as my commit.

waiting for test result.
Comment on attachment 8550128 [details] [review]
PR to master

Hi Alive,
my proposal is to change _resize to resize. what do you think?
Attachment #8550128 - Flags: review?(alive)
Comment on attachment 8550128 [details] [review]
PR to master

I believe the orientationchange handler needs to be done for every appWindow instead of only active Appwindow. By calling this.resize() you will be early returned by bottom.shouldResize() and fail to resize the background appWindow.

Anyway, Etienne should review this.
Attachment #8550128 - Flags: review?(alive) → review?(etienne)
Comment on attachment 8550128 [details] [review]
PR to master

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #8)
> I believe the orientationchange handler needs to be done for every appWindow
> instead of only active Appwindow. By calling this.resize() you will be early
> returned by bottom.shouldResize() and fail to resize the background
> appWindow.

Indeed.

I think the core issue here is that the orientationchange event only gets broadcasted to launched apps not inline activities.

One fix would be to broadcast the event to `this.frontWindow` in the appWindow has one. What do you guys think?
Attachment #8550128 - Flags: review?(etienne)
(In reply to Etienne Segonzac (:etienne) from comment #9)
> Comment on attachment 8550128 [details] [review]
> PR to master
> 
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #8)
> > I believe the orientationchange handler needs to be done for every appWindow
> > instead of only active Appwindow. By calling this.resize() you will be early
> > returned by bottom.shouldResize() and fail to resize the background
> > appWindow.
> 
> Indeed.
> 
> I think the core issue here is that the orientationchange event only gets
> broadcasted to launched apps not inline activities.
> 
> One fix would be to broadcast the event to `this.frontWindow` in the
> appWindow has one. What do you guys think?

+1!
Comment on attachment 8550128 [details] [review]
PR to master

Thanks for advice!
Now app would broadcast orientaitonchange to its frontWindow if app is active.
Attachment #8550128 - Flags: review?(alive)
Comment on attachment 8550128 [details] [review]
PR to master

Let's see if there is side effect or not.
Attachment #8550128 - Flags: review?(alive) → review+
Test pass, Thanks everyone.
master: https://github.com/mozilla-b2g/gaia/commit/05f8670c8d457f67c4202de4094e9ca9ea409bf4
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
This issue has been verified successfully on Flame master.

Flame master build:

Gaia-Rev        22230c9a340a0a2c3af73320cf47e1cb544517ad
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/600f44fd317c
Build-ID        20150226160308
Version         39.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150226.193049
FW-Date         Thu Feb 26 19:31:00 EST 2015
Bootloader      L1TC000118D0
QA Whiteboard: [MGSEI-Triage+]
Set 2.2?, we have PR, and to make ux more friendly, could we uplift this to 2.2?
blocking-b2g: --- → 2.2?
(In reply to Eric Chang [:ericcc] [:echang] from comment #15)
> Set 2.2?, we have PR, and to make ux more friendly, could we uplift this to
> 2.2?

Hmm, I don't want to block on this as this is not a recent regression and more of a polish. nevertheless I am happy to uplift this if George can request approval, that way if this has any fallouts we can immediately back this out without worrying about tracking the follow-ups. I'll make an exception to approve this non-blocking issue as the risk looks low and worth the polish.
blocking-b2g: 2.2? → ---
Flags: needinfo?(gduan)
Comment on attachment 8550128 [details] [review]
PR to master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): None.
[User impact] if declined: User might see unexpected facebook screen when doing steps of comment 0. (see attachment 8546514 [details] )
[Testing completed]: Yes. it has covered manual test and unit test.
[Risk to taking this patch] (and alternatives if risky): None.
[String changes made]:
Flags: needinfo?(gduan)
Attachment #8550128 - Flags: approval-gaia-v2.2?
Attachment #8550128 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This issue verified successfully on Flame 2.2
Flame 2.2:
Build ID               20150327162502
Gaia Revision          473cd63f53c855299b719285d9b95e3f2910782f
Gaia Date              2015-03-27 20:14:43
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b358619def45
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Reproduce rate  0/5
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.