Closed
Bug 1119723
Opened 11 years ago
Closed 10 years ago
[Flame][Homescreen]A partial facebook view overlaps on the top left corner of home screen.
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(b2g-v2.1 affected, b2g-v2.2 verified, b2g-master verified)
VERIFIED
FIXED
2.2 S4 (23jan)
People
(Reporter: wangxin, Assigned: gduan)
Details
Attachments
(3 files)
[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
Comment 2•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
Hi Alive, not sure if this is belong to system. Could you help to check with it, thanks.
Flags: needinfo?(mlien) → needinfo?(alive)
Comment 5•10 years ago
|
||
Bad :/
Could you help? A potential blocker.
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
Flags: needinfo?(alive) → needinfo?(gduan)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → gduan
Flags: needinfo?(gduan)
Assignee | ||
Comment 6•10 years ago
|
||
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.
Assignee | ||
Comment 7•10 years ago
|
||
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 8•10 years ago
|
||
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 9•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
(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!
Assignee | ||
Comment 11•10 years ago
|
||
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 12•10 years ago
|
||
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+
Assignee | ||
Comment 13•10 years ago
|
||
Test pass, Thanks everyone.
master: https://github.com/mozilla-b2g/gaia/commit/05f8670c8d457f67c4202de4094e9ca9ea409bf4
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 14•10 years ago
|
||
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+]
status-b2g-master:
--- → verified
Comment 15•10 years ago
|
||
Set 2.2?, we have PR, and to make ux more friendly, could we uplift this to 2.2?
blocking-b2g: --- → 2.2?
Comment 16•10 years ago
|
||
(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)
Assignee | ||
Comment 17•10 years ago
|
||
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?
Updated•10 years ago
|
Attachment #8550128 -
Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Comment 18•10 years ago
|
||
Target Milestone: --- → 2.2 S4 (23jan)
Comment 19•10 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•