1090662 - [Midori 2.0][New feature][Home screen]The screen appears flash in vertical mode after draging up and down a app.

Status: RESOLVED WONTFIX

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

Description

[sync-1]

version: FFOS 2.0 
 BuildID: 20140916000205
 
 DEFECT DESCRIPTION:
 The screen appears flash in vertical mode after dragging up and down an app.
 
  REPRODUCING PROCEDURES:
 1.Launch settings and tap homescreen to select vertical;
 2.Long press an app icon, and then drag up and down in bottom right corner, and the screen appears flash --> KO1;
 3.The screen appears some lines which split screen in bottom --> KO2;
 
  EXPECTED BEHAVIOUR:
 KO1:The screen should display normally in vertical mode after dragging up and down an app.
 KO2:The screen should appear one line which split screen in bottom.
 
 
  USER IMPACT:Medium
 
  REPRODUCING RATE:5/5

Comment 1

[sync-1]

Attachment: pic

Comment 2

[sync-1]

Attachment: log

Comment 3

[sync-1]

Attachment: video

Comment 4

[xiupinglong]

[Blocking Requested - why for this release]:

Comment 5

[Wesly Huang (EPM)]

hi Xiuping:

I can't repro. this in my Flame with latest v188 base image, and doubt it's device specific issue, would you have your display/driver people to check first? BTW for video would you use .zip format? Tks.

Per picture indeed UX impact but doubt device specific, so could be candidate for de-nom in coming triage.

Comment 6

[Wesly Huang (EPM)]

btw Xiuping: would you help clarify more about your 1st step of STR? "1.Launch settings and tap homescreen to select vertical" mean you press some item in "settings"? I assume this step is simply want to make sure that phone display is in vertical orientation?

Comment 7

[xiupinglong]

Attachment: VID_20141027_150404.3gp

Comment 8

[xiupinglong]

The issue is happened on the 9th seconds and the 15th seconds in the video "VID_20141027_150404.3gp".

Comment 9

[xiupinglong]

(In reply to Wesly Huang from comment #6)
> btw Xiuping: would you help clarify more about your 1st step of STR?
> "1.Launch settings and tap homescreen to select vertical" mean you press
> some item in "settings"? I assume this step is simply want to make sure that
> phone display is in vertical orientation?

Hi Wesly,

Yes, that's mean the device display verticalhome(2.0 new added) instead of homescreen(before 2.0 is default homescreen).

Comment 10

[Wesly Huang (EPM)]

Thanks Xiuping, I assume once you press home again then those separation-lines will reduced to only 1, right? (that's what I saw in my Flame 2.0).

Comment 11

[xiupinglong]

(In reply to Wesly Huang from comment #10)
> Thanks Xiuping, I assume once you press home again then those
> separation-lines will reduced to only 1, right? (that's what I saw in my
> Flame 2.0).

Hi Wesly,

Yes, once user exit from edit mode by press home key, the separation-lines will reduced to only 1.

Comment 12

[Wesly Huang (EPM)]

Thanks Xiuping! Then I would say this is quite low user impact compared with other issues that we plan to tag for fix, will treat it as a candidate for de-nom in coming Triage.

Comment 13

[Wesly Huang (EPM)]

[Triage] de-nom as low user impact, more like polish.

Comment 14

[Jack Liu]

[Blocking Requested - why for this release]:
Dear Wesly,

I insist to block on because it's too easy to reproduce and the UE is no better than a demo program but we need product level performance.

reproduce on moz BuildID 20141019000201

Comment 15

[Wayne Chang [:wchang]]

We don't see this as blocking given the stage 2.0 release is at. It does not match the blocking criteria listed here: https://wiki.mozilla.org/B2G/Triage#Issues_that_Should_Block
We also do not see this problem on 2.1.

Comment 16

[Jack Liu]

[Blocking Requested - why for this release]:

Hi Wesly,

I think below rules are suitable for this issue,  do you think carrier and user will accept a phone with significant defects(flash, mess) on launcher/home screen?

Major issue in new feature - especially those in which a large number of users will be impacted, or a smaller number of users will be significantly impacted
Major identifiable regressions (perf or otherwise)
Issues getting a lot of support calls with partners or on SUMO
Issues that block device launches(ex, IOT, CS blockers) and agreed with partners.

Please check it on Midori and assess again, please let me know if it's device dependent.

Thanks.

Comment 17

[Shine(Leave from Mozilla)]

According to issue steps, we can't reproduce on Flame v2.1 and v2.2.
Flame 2.1 versions:
Gaia-Rev        154da5e17029a51002d5d9b7df39563d509edde6
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3b0c3580a58d
Build-ID        20141105001204
Version         34.0

Flame 2.2 versions:
Gaia-Rev        7918024c737c4570cacd784f267e28737ae05dea
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2114ef80f6ae
1
Build-ID        20141105160209
Version         36.0a1

Reproduction Frequency: 0/15

Please add “this is reproducible in 1.3 SW or not” information for this issue.

Comment 18

[xiupinglong]

Because FFOS 1.3 SW has not verticalhome, so can not compare with it.

reproduce on
version: FFOS 2.0 
BuildID: 20140916000205

Thanks!

Comment 19

[Wesly Huang (EPM)]

Per comment#17 it's device specific thus a candidate for de-tag in coming Triage.

Comment 20

[xiupinglong]

(In reply to Wesly Huang from comment #19)
> Per comment#17 it's device specific thus a candidate for de-tag in coming
> Triage.

Dear Wesly,
But commnet#17 using Flame v2.1 and v2.2 other than v2.0.

Comment 21

[Rachelle Yang [:ryang][[e-mail]]]

can't reproduce on Flame 2.0. Denominate for now.

Comment 22

[xiupinglong]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #21)
> can't reproduce on Flame 2.0. Denominate for now.

Dear Rachelle,

But, I can reproduce it on Flame 2.0 in our hand, could you tell me which version did you test on Flame 2.0?

Or someone who can tell us the patch for this issue.

Thanks!

Comment 23

[Wesly Huang (EPM)]

It's v188 base image used for test, and the fact is even can repro. it in 2.0 by some way this issue still can't be tag for 2.0 considering the timing, as mentioned in comment#15.

Comment 24

[xiupinglong]

(In reply to Wesly Huang from comment #23)
> It's v188 base image used for test, and the fact is even can repro. it in
> 2.0 by some way this issue still can't be tag for 2.0 considering the
> timing, as mentioned in comment#15.

Dear Wesly,

Flame 2.0 v188 still can reproduce this issue. It is a really serious problem, please help to solve this issue. Thank you for your support!

Flame 2.0 v188 reproduce steps video:
https://mega.co.nz/#!LkRwQBZA!NfS7AP5KPsHJVylauS3Gc4bO6R4c9hiBdN8s1wPZ-j0

Comment 25

[xiupinglong]

In video 

https://mega.co.nz/#!LkRwQBZA!NfS7AP5KPsHJVylauS3Gc4bO6R4c9hiBdN8s1wPZ-j0

issue happens on the 4th seconds and 9th seconds.

Comment 26

[Jack Liu]

Hi Wesly,

This issue becomes a blocker on carrier side now, we do need strong support from mozilla.

Thanks.

Comment 27

[Jack Liu]

Hi Wesly,

We found this issue is related to the settings of Developer->Async Pan/Zoom, it occurs after disable the option. But enable the option also arouse other problems, so we disabled it per https://bugzilla.mozilla.org/show_bug.cgi?id=980041#c20.

We need mozilla help to check why it can't work normally with Developer->Async Pan/Zoom disabled, it's just a developer option.

Thanks.

Comment 28

[Wesly Huang (EPM)]

Hi Keven:

I remember we've ever mentioned about Async Pan/Zoom in some meeting but forget the detail, would you help have corresponding member to explain some detail here? since per comment#27 this issue can be fix by enable it. Maybe that's some clue for fixing this issue?

@Jack: what's the "other problems" when you enable it? Maybe those "other issue" will be easier to fix so we should go that way?

Comment 29

[Keven Kuo [:kkuo]]

Hi! Peter,

Need your help to provide more accurate explanation. Thanks

--
Keven

Comment 30

[Jack Liu]

(In reply to Wesly Huang from comment #28)
> Hi Keven:
> 
> I remember we've ever mentioned about Async Pan/Zoom in some meeting but
> forget the detail, would you help have corresponding member to explain some
> detail here? since per comment#27 this issue can be fix by enable it. Maybe
> that's some clue for fixing this issue?
> 
> @Jack: what's the "other problems" when you enable it? Maybe those "other
> issue" will be easier to fix so we should go that way?

Hi Wesly,

As I know apz caused some serious issues as but not limited to following, it's too late to perform another round  full function test:

1. it affects hash change, when move internally by href=#hashval in a page,  some times window.location.hash not change instantly.

2. stick on button/bar/other controls then slide out its valid area, the appearance(status) of that control does not change.

Thanks.

Comment 31

[Jack Liu]

[Blocking Requested - why for this release]:Carrier insist to block on it.

Comment 32

[Peter Chang[:pchang]]

(In reply to Jack Liu from comment #30)
> (In reply to Wesly Huang from comment #28)
> > Hi Keven:
> > 
> > I remember we've ever mentioned about Async Pan/Zoom in some meeting but
> > forget the detail, would you help have corresponding member to explain some
> > detail here? since per comment#27 this issue can be fix by enable it. Maybe
> > that's some clue for fixing this issue?
> > 
> > @Jack: what's the "other problems" when you enable it? Maybe those "other
> > issue" will be easier to fix so we should go that way?
> 
> Hi Wesly,
> 
> As I know apz caused some serious issues as but not limited to following,
> it's too late to perform another round  full function test:
> 
> 1. it affects hash change, when move internally by href=#hashval in a page, 
> some times window.location.hash not change instantly.
> 
> 2. stick on button/bar/other controls then slide out its valid area, the
> appearance(status) of that control does not change.
> 
> Thanks.
Jack, apz is used to provide better user experience during the scrolling. You can imagine that gecko will cache the content area which is bigger than the screen. During scrolling, we just change the viewport but not require app to render the new area. Therefore, it provides better performance and power saving.

So above two issues are happened if you enable APZ. Am I right? Could you have detail STR and let our QA to check it happens on our reference phone or not. But I would suggest to create another bug for issues with apz is on.

Comment 33

[Jack Liu]

Hi Peter,

Thanks for your explanation of apz.

With apz enabled, I got issue on Flame 2.0 BuildID 20141008000202 as STR:
1. launch settings app.
2. Touch any menu item on the page and move slowly (keep touching) out of valid area of the menu item. -- You will find the blue background doesn't vanish and the page doesn't scroll with your finger.

With apz disabled, the behavior is contrasting to above:
1. switch to home screen.
2. touch on an app icon to enter editing mode.
3. try to move the icon to other position, the screen is scrolling with your finger and hard to move icon to the position wanted.

I think both behaviors above are wrong, please check.

Thanks.

Comment 34

[Wesly Huang (EPM)]

Hi Jack:

I've talked and get Peter's (graphic team) support to take a look of this issue, and will try to put his finding/suggestion here today.

Comment 35

[Peter Chang[:pchang]]

(In reply to Jack Liu from comment #33)
> Hi Peter,
> 
> Thanks for your explanation of apz.
> 
> With apz enabled, I got issue on Flame 2.0 BuildID 20141008000202 as STR:
> 1. launch settings app.
> 2. Touch any menu item on the page and move slowly (keep touching) out of
> valid area of the menu item. -- You will find the blue background doesn't
> vanish and the page doesn't scroll with your finger.
> 
> With apz disabled, the behavior is contrasting to above:
> 1. switch to home screen.
> 2. touch on an app icon to enter editing mode.
> 3. try to move the icon to other position, the screen is scrolling with your
> finger and hard to move icon to the position wanted.
> 
> I think both behaviors above are wrong, please check.
> 
> Thanks.

I think it is related to the touch event routing issue. If you keep touching screen with scrolling, it works fine. But if you touch at some point and then move your finger, the content is not scroll. 

I would suggest to use gdb to attach at [1] to find the difference routing path between above two use cases. I will also help to check it in my side but may response slowly.

[1]http://dxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#7258

Comment 36

[Jack Liu]

Dear Wesly,

We have enabled apz to be consistent with mozilla original configuration following your suggestion.

Please mozilla engineers focus on issues described in comment#33 under this condition.

Thanks a lot.

Comment 37

[Wesly Huang (EPM)]

Thank Jack, good to know the result here. We'll take your suggestion in comment#36 into overall consideration. Thank you.

[Triage] De-nom given 2.0 timing and not repro. in 2.1/2.2.

Comment 38

[Kevin Grandon :kgrandon]

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.