Closed Bug 1090662 Opened 5 years ago Closed 4 years ago

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

Categories

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

defect

Tracking

(b2g-v2.1 unaffected, b2g-v2.2 unaffected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- unaffected

People

(Reporter: sync-1, Unassigned)

References

Details

Attachments

(4 files)

897.59 KB, image/x-png
Details
log
177.24 KB, application/octet-stream
Details
6.18 MB, application/octet-stream
Details
6.18 MB, video/3gpp
Details
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
Attached image pic
Attached file log
Attached file video
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Flags: needinfo?(wehuang)
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.
Flags: needinfo?(wehuang) → needinfo?(longxiuping)
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?
Attached video VID_20141027_150404.3gp
Flags: needinfo?(longxiuping)
The issue is happened on the 9th seconds and the 15th seconds in the video "VID_20141027_150404.3gp".
(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).
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).
(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.
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.
[Triage] de-nom as low user impact, more like polish.
blocking-b2g: 2.0? → -
[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
blocking-b2g: - → 2.0?
Flags: needinfo?(wehuang)
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.
blocking-b2g: 2.0? → -
Flags: needinfo?(wehuang)
[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.
blocking-b2g: - → 2.0?
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.
Flags: needinfo?(sync-1)
Because FFOS 1.3 SW has not verticalhome, so can not compare with it.

reproduce on
version: FFOS 2.0 
BuildID: 20140916000205

Thanks!
Flags: needinfo?(sync-1)
Flags: needinfo?(wehuang)
Per comment#17 it's device specific thus a candidate for de-tag in coming Triage.
Flags: needinfo?(wehuang)
(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.
can't reproduce on Flame 2.0. Denominate for now.
blocking-b2g: 2.0? → ---
(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] 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!
Flags: needinfo?(ryang)
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.
Flags: needinfo?(ryang)
(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
In video 

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

issue happens on the 4th seconds and 9th seconds.
Hi Wesly,

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

Thanks.
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.
Flags: needinfo?(wehuang)
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?
Flags: needinfo?(wehuang)
Flags: needinfo?(liuyongming)
Flags: needinfo?(kkuo)
Hi! Peter,

Need your help to provide more accurate explanation. Thanks

--
Keven
Flags: needinfo?(kkuo) → needinfo?(pchang)
(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.
Flags: needinfo?(liuyongming)
Flags: needinfo?(wehuang)
[Blocking Requested - why for this release]:Carrier insist to block on it.
blocking-b2g: --- → 2.0?
(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.
Flags: needinfo?(pchang)
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.
Flags: needinfo?(pchang)
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.
Flags: needinfo?(wehuang)
(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
Flags: needinfo?(pchang)
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.
Flags: needinfo?(wehuang)
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.
blocking-b2g: 2.0? → ---
Flags: needinfo?(wehuang)
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: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.