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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.2 S4 (23jan)
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- verified
b2g-master --- verified

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
Attached 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)
Attached 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+
Status: NEW → RESOLVED
Closed: 10 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.

Attachment

General

Creator:
Created:
Updated:
Size: