Closed Bug 1041432 Opened 6 years ago Closed 4 years ago

[dolphin][flame] dock bar position moves up when return to homescreen from E.ME

Categories

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

x86_64
Linux
defect
Not set

Tracking

(blocking-b2g:-, b2g-v1.4 affected)

RESOLVED WONTFIX
blocking-b2g -
Tracking Status
b2g-v1.4 --- affected

People

(Reporter: angelc04, Assigned: ben.song)

References

Details

Attachments

(5 files, 1 obsolete file)

Attached video STR video
Steps to reproduce
----------------------------------------------------------------------------
1. Start device
2. Tap on "I'm thinking of...", keyboard will appear
3. Tap on Home Button
   --> You will see the dock bar was moved up. 

Both Flame and dolphin have this problem. But V1.3 does not have this issue.

Attached is a STR video.

Test build
---------------------------------------------------------------------------
Gaia      621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/83b7be7fb33f
BuildID   20140720160206
Version   30.0
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
In this series of homescreen questions, there is shown that the four buttons of footer moved up a certain distance, through the analysis found, there is a reason for this: when the user opens the search page in homescreen, and open input method in it, then homescreen height would change and trigger resize event. However, due to the impact of lowmemorykiller, homescreen would be killed, and homescreen will be regenerated, but has four buttons below the screen to the center. Because the time during homescreen killed to reopened, its height haven't changed,so the position of the four button would be incorrect.
Modification method is that reset to the initial value of homescreen height when it reopened after suddenly killed.
Flags: needinfo?(yang.zhao)
Flags: needinfo?(tzhuang)
Flags: needinfo?(lchang)
[Blocking Requested - why for this release]:
blocking-b2g: --- → 1.4?
Ben, please attach your patch here.
This patch deals with two problems:
1.When IME shows but homescreen been killed and restarted,four footer buttons of homescreen move up.(I havn't deal with that when we switch IME on homescreen,the button moveup temporarily,if you need to deal with it,i can do it.)
2.when monkey test several hours,to switch homescreen and apps and slide the screen in the process,pages of homescreen happen to overlap.
Assignee: nobody → ben.song
Status: NEW → ASSIGNED
Attachment #8462336 - Flags: review?(tzhuang)
Attachment #8462336 - Flags: review?(kkuo)
Attachment #8462336 - Flags: review?(21)
(In reply to ben.song from comment #4)
> Created attachment 8462336 [details] [diff] [review]
> page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> 
> This patch deals with two problems:
> 1.When IME shows but homescreen been killed and restarted,four footer
> buttons of homescreen move up.(I havn't deal with that when we switch IME on
> homescreen,the button moveup temporarily,if you need to deal with it,i can
> do it.)
> 2.when monkey test several hours,to switch homescreen and apps and slide the
> screen in the process,pages of homescreen happen to overlap.

Ben, what do you mean by "button move up"? If it mean the dock bar move up, I think we should fix it. Because from user's perspective, we don't expect the dock bar to move up.
(In reply to pcheng from comment #5)
> (In reply to ben.song from comment #4)
> > Created attachment 8462336 [details] [diff] [review]
> > page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> > 
> > This patch deals with two problems:
> > 1.When IME shows but homescreen been killed and restarted,four footer
> > buttons of homescreen move up.(I havn't deal with that when we switch IME on
> > homescreen,the button moveup temporarily,if you need to deal with it,i can
> > do it.)
> > 2.when monkey test several hours,to switch homescreen and apps and slide the
> > screen in the process,pages of homescreen happen to overlap.
> 
> Ben, what do you mean by "button move up"? If it mean the dock bar move up,
> I think we should fix it. Because from user's perspective, we don't expect
> the dock bar to move up.

   Yes,I find the cause of the dock bar move up is that time differece of IME remove and screen height recover.I would fix it.
Flags: needinfo?(yang.zhao)
Flags: needinfo?(tzhuang)
Flags: needinfo?(lchang)
(In reply to pcheng from comment #5)
> (In reply to ben.song from comment #4)
> > Created attachment 8462336 [details] [diff] [review]
> > page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> > 
> > This patch deals with two problems:
> > 1.When IME shows but homescreen been killed and restarted,four footer
> > buttons of homescreen move up.(I havn't deal with that when we switch IME on
> > homescreen,the button moveup temporarily,if you need to deal with it,i can
> > do it.)
> > 2.when monkey test several hours,to switch homescreen and apps and slide the
> > screen in the process,pages of homescreen happen to overlap.
> 
> Ben, what do you mean by "button move up"? If it mean the dock bar move up,
> I think we should fix it. Because from user's perspective, we don't expect
> the dock bar to move up.

   But the patch is the problem happened in the monkey test,it is diferent from above.So please review it.Thanks.
Flags: needinfo?(wchang)
Flags: needinfo?(ryang)
Comment on attachment 8462336 [details] [diff] [review]
page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch

Hi Ben,

I don't see where the problem is. 
To me, it looks like the dock just has a little jitter when keyboard fadeout.

And since your patch had modified system, I think you should ask alive for review, not me.
Attachment #8462336 - Flags: review?(tzhuang) → review?(alive)
(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #8)
> Comment on attachment 8462336 [details] [diff] [review]
> page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> 
> Hi Ben,
> 
> I don't see where the problem is. 
> To me, it looks like the dock just has a little jitter when keyboard fadeout.
> 
> And since your patch had modified system, I think you should ask alive for
> review, not me.

Hi Tzn-Lin,

 Ok,thanks.The bug occurs in the monkey test,mainly homescreen overlap when slide during the switch between homescreen and apps,and dock bar move up when homescreen been suddenly killed.
Hi pcheng,

   This patch is for the bug you have described,when switch between IME and homescreen, the dock bar move up briefly,please review it.

   Thanks.
Attachment #8462975 - Flags: review?(tzhuang)
Attachment #8462975 - Flags: review?(pcheng)
Attachment #8462975 - Flags: review?(lchang)
Flags: needinfo?(pcheng)
Flags: needinfo?(wchang)
Comment on attachment 8462336 [details] [diff] [review]
page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch

Review of attachment 8462336 [details] [diff] [review]:
-----------------------------------------------------------------

r- for hack keyboard height in appWindow.
Attachment #8462336 - Flags: review?(alive) → review-
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #11)
> Comment on attachment 8462336 [details] [diff] [review]
> page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> 
> Review of attachment 8462336 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r- for hack keyboard height in appWindow.

And I don't understand why we need to hack keyboard in mozbrowserloadend event handler.
Flags: needinfo?(ryang)
Flags: needinfo?(pcheng)
Attachment #8462336 - Flags: review?(kkuo) → review-
Attachment #8462975 - Flags: review?(pcheng) → review-
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #12)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #11)
> > Comment on attachment 8462336 [details] [diff] [review]
> > page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> > 
> > Review of attachment 8462336 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > r- for hack keyboard height in appWindow.
> 
> And I don't understand why we need to hack keyboard in mozbrowserloadend
> event handler.

Hi Alive,

   The patch to hack keyboard in mozbrowserloadend is for the problem when you opened IME in search of homescreen,and homescreen be killed in this moment,this dock bar would appear in the center of homescreen.So we should check the height of keyboard and invoke resize function,let the height recover origin value in the moment of a new homescreen render.The reason why I hold it in mozbrowserloadend is the event be at last of a new homescreen render and it could bring good experience to users.
Hi pei,

   Why the attachment #8462975 [details] [diff] [review] is the state of review-?  thanks.
Flags: needinfo?(pcheng)
(In reply to ben.song from comment #14)
> Hi pei,
> 
>    Why the attachment #8462975 [details] [diff] [review] [diff] [review] is the state of
> review-?  thanks.

I'm not the right person to review your patch, thus review-
Flags: needinfo?(pcheng)
(In reply to Peipei Cheng from comment #15)
> (In reply to ben.song from comment #14)
> > Hi pei,
> > 
> >    Why the attachment #8462975 [details] [diff] [review] [diff] [review] [diff] [review] is the state of
> > review-?  thanks.
> 
> I'm not the right person to review your patch, thus review-

Hi pei,

  OK,thanks.
Attachment #8462975 - Flags: review?(alive)
Attachment #8462336 - Flags: review?(james.zhang)
Attachment #8462975 - Flags: review?(james.zhang)
Comment on attachment 8462975 [details] [diff] [review]
switch_between_IME_and_homescreen_dock_moveup_briefly.patch

Review of attachment 8462975 [details] [diff] [review]:
-----------------------------------------------------------------

No idea why this needs my review.
Attachment #8462975 - Flags: review?(alive)
ben.song, I think the patch for homescreen overlap issue should goes to Bug 1041423. For this one, we'd better only track the dock move up problem.
Flags: needinfo?(ben.song)
Hi Gregor,

Could you take a look this homescreen issue and see if you can find someone to help the review on the patch provided by our partner. Thank you.
Flags: needinfo?(anygregor)
(In reply to ben.song from comment #13)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #12)
> > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #11)
> > > Comment on attachment 8462336 [details] [diff] [review]
> > > page_of_homescreen_overlap_and_footerbutton_of homescreen_moveup.patch
> > > 
> > > Review of attachment 8462336 [details] [diff] [review]:
> > > -----------------------------------------------------------------
> > > 
> > > r- for hack keyboard height in appWindow.
> > 
> > And I don't understand why we need to hack keyboard in mozbrowserloadend
> > event handler.
> 
> Hi Alive,
> 
>    The patch to hack keyboard in mozbrowserloadend is for the problem when
> you opened IME in search of homescreen,and homescreen be killed in this
> moment,this dock bar would appear in the center of homescreen.So we should
> check the height of keyboard and invoke resize function,let the height
> recover origin value in the moment of a new homescreen render.The reason why
> I hold it in mozbrowserloadend is the event be at last of a new homescreen
> render and it could bring good experience to users.

The patch is problematic in several ways,

If there is an app loading at background you will kill the foreground keyboard.
If there is an app loading at background you will force resizing and then reflow.
AppWindow should not touch KeyboardManager for any reason.
(In reply to Peipei Cheng from comment #18)
> ben.song, I think the patch for homescreen overlap issue should goes to Bug
> 1041423. For this one, we'd better only track the dock move up problem.

OK,I would extract two patch from the attachment #8462336 [details] [diff] [review],and put them in their suited bug.
Flags: needinfo?(ben.song)
Comment on attachment 8462975 [details] [diff] [review]
switch_between_IME_and_homescreen_dock_moveup_briefly.patch

Since this patch is about everything.me, I think I'm not the right person to review it, either.
Attachment #8462975 - Flags: review?(lchang)
Attachment #8462336 - Attachment is obsolete: true
Attachment #8462336 - Flags: review?(james.zhang)
Attachment #8462336 - Flags: review?(21)
Attached file quick patch
I tried to make a quick patch for this bug.

Alive, would you mind giving me some feedback? Thanks.
Attachment #8463322 - Flags: feedback?(alive)
When keyboard opened in the search bar and at the moment homescreen be killed,dock bar would move up.The reason of it is when keyboard opened,the height of the page element of homescreen would reduce the height of keyboard,but when homescreen be killed,the height would not recover,so the dock bar would move up.For this,I add a checker in the process of restart of homescreen,in a event of mozbrowserloadend,and add a judge that the apps if or not be homescreen.if it is,I would recover the height of the homescreen.

Hi pei,

   Please add reviewers,thanks.
Attachment #8463336 - Flags: review?(james.zhang)
Flags: needinfo?(pcheng)
Ben, please wait mozilla review.
(In reply to James Zhang (Spreadtrum) from comment #25)
> Ben, please wait mozilla review.

Hi James,

   OK.
This seems a combination of app_window and Keyboard to me. Tim can you help with reviewers?
Not sure a homescreen reviewer is helpful but I can find one if needed. Cristian is out so it would be best to ping vingtetun.
Flags: needinfo?(anygregor) → needinfo?(timdream)
Flags: needinfo?(pcheng)
Comment on attachment 8462975 [details] [diff] [review]
switch_between_IME_and_homescreen_dock_moveup_briefly.patch

Hi Ben,

I am not review of either e.me or homescreen, so I cancel it.

However, I think Luke has gave a more proper solution for this bug on comment 23. I think we should elaborate more on that patch.
Attachment #8462975 - Flags: review?(tzhuang)
Comment on attachment 8463322 [details] [review]
quick patch

See github
Attachment #8463322 - Flags: feedback?(alive)
I actually think this should be addressed in the home screen app -- Homescreen should wait for keyboard hidden before working on resizing itself etc.

Homescreen reviewers should followup with Ben from patch comment 24.
Flags: needinfo?(timdream)
I meant to say the patch in comment 10.
Hi Wayne,

We need to know the priority of the bug. 
It is easy to reproduce on dolphin. 

I think it is no harm under normal circumstances but if homescreen is OOM killed at the moment it occurs, it would be like this https://bug1041432.bugzilla.mozilla.org/attachment.cgi?id=8459468
Flags: needinfo?(wchang)
Attachment #8462975 - Flags: review?(james.zhang) → review-
Attachment #8463336 - Flags: review?(james.zhang) → review-
Attachment #8463336 - Flags: review-
Attachment #8462975 - Flags: review-
Attachment #8462975 - Flags: review-
So far, I think there are two issue in this bug:

1. When hiding the keyboard from E.ME, you will see the dock move up to the middle of screen temporarily and soon move back to bottom shortly. (refer to comment 0)

2. The height of the homescreen window becomes incorrect if homescreen app is killed while using E.ME. (refer to comment 1)

Actually, these two issues are irrelevant. I can reproduce the second issue on unagi (v1.4) even though there isn't the fist issue on it. The first issue is just an UX issue and can be fixed through CSS.

I recommend separating this bug into two bugs to clarify these two issue.

Ben, how do you think?
Flags: needinfo?(ben.song)
(In reply to Luke Chang [:lchang] from comment #33)
> So far, I think there are two issue in this bug:
> 
> 1. When hiding the keyboard from E.ME, you will see the dock move up to the
> middle of screen temporarily and soon move back to bottom shortly. (refer to
> comment 0)
> 
> 2. The height of the homescreen window becomes incorrect if homescreen app
> is killed while using E.ME. (refer to comment 1)
> 
> Actually, these two issues are irrelevant. I can reproduce the second issue
> on unagi (v1.4) even though there isn't the fist issue on it. The first
> issue is just an UX issue and can be fixed through CSS.
> 
> I recommend separating this bug into two bugs to clarify these two issue.
> 
> Ben, how do you think?

1. isn't really a blocker since its only for a split second and have near zero user impact.

for 2. - as i've seen it demo'ed by Luke, the bar gets stuck half way on the screen and does look nasty when happens. I think we can take a low risk/effort fix on it. It can be recovered by launching an app and exiting it.

Luke, I am 1.4-'ing this bug here, if you have time for a fix on 2 (using this bug or a new bug), please nom and NI me to request for 1.4+.
blocking-b2g: 1.4? → -
Flags: needinfo?(wchang) → needinfo?(lchang)
(In reply to Luke Chang [:lchang] from comment #33)
> So far, I think there are two issue in this bug:
> 
> 1. When hiding the keyboard from E.ME, you will see the dock move up to the
> middle of screen temporarily and soon move back to bottom shortly. (refer to
> comment 0)
> 
> 2. The height of the homescreen window becomes incorrect if homescreen app
> is killed while using E.ME. (refer to comment 1)
> 
> Actually, these two issues are irrelevant. I can reproduce the second issue
> on unagi (v1.4) even though there isn't the fist issue on it. The first
> issue is just an UX issue and can be fixed through CSS.
> 
> I recommend separating this bug into two bugs to clarify these two issue.
> 
> Ben, how do you think?
Hi Luke,

   You are right,I would set up a new bug for 2.But 1 is also important for pcheng has emphasised.OK?
   Thanks.
Flags: needinfo?(ben.song)
Hi Wayne,

Thanks. According to comment 35, Ben will file another bug for the second issue so let's track there.


Hi Ben,

For the first issue, you may refer to https://github.com/luke-chang/gaia/commit/4f8ccce947081cc110c8ddb35b10db7282de1045#diff-0 ("homescreen.css" part) to fix it.
Flags: needinfo?(lchang)
(In reply to Wayne Chang [:wchang] from comment #34)
> (In reply to Luke Chang [:lchang] from comment #33)
> > So far, I think there are two issue in this bug:
> > 
> > 1. When hiding the keyboard from E.ME, you will see the dock move up to the
> > middle of screen temporarily and soon move back to bottom shortly. (refer to
> > comment 0)
> > 
> > 2. The height of the homescreen window becomes incorrect if homescreen app
> > is killed while using E.ME. (refer to comment 1)
> > 
> > Actually, these two issues are irrelevant. I can reproduce the second issue
> > on unagi (v1.4) even though there isn't the fist issue on it. The first
> > issue is just an UX issue and can be fixed through CSS.
> > 
> > I recommend separating this bug into two bugs to clarify these two issue.
> > 
> > Ben, how do you think?
> 
> 1. isn't really a blocker since its only for a split second and have near
> zero user impact.

Wayne, I think 1 is still a block, because:
1. This issue is not reproducible on V1.3 and V1.3t. So it's a regression.
2. I think E.Me is a frequently use feature. User will do such switch actions a lot. So they will see this problem a lot.
(In reply to Luke Chang [:lchang] from comment #23)
> Created attachment 8463322 [details] [review]
> quick patch
> 
> I tried to make a quick patch for this bug.
> 
> Alive, would you mind giving me some feedback? Thanks.

w/o the patch, we can reproduce this issue in monkey test.
Applying the patch, this issue is gone in 60hrs monkey test and there is no crash/hang/b2g kill.
Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Blocks: 1231115
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.