1089528 - Notification bar icons will not scroll up with the background when clicking settings

Status: VERIFIED FIXED

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

Description

[Shing Lyu [:shinglyu]]

Attachment: Screenshot

*** Build Information
Gaia-Rev        1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/09fb60a37850
Build-ID        20141023001201
Version         34.0
Device-Name     flame
Base image: ***Please update this field to say if you're running the v180 or the v188 base image***


*** Description
As title.

*** Steps to Reproduce
1. Swipe from the top edge to open the notifications.
2. Tap the settings in the bottom-right corner

*** Expected Results
The icons and text should disappear when the background scrolls up.

*** Actual Results
The icons and the text does not disappear until the background is totally gone, which creates a bad user experience. (See the attachment)

*** Other Notes


*** Reproduction Frequency: 
Always

Comment 1

[Tony Chung [:tchung]]

[Blocking Requested - why for this release]:

qawanted on branch checks, and regression window .   blocking nom for bad user experience

Comment 2

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Issue DOES reproduce on 2.1 KK Flame.

Acutal Results: The text and icons of the notifcation pane do not go away until the whole pane is completely gone.

Environmental Variables(Shallow Flash):
Device: Flame 2.1
BuildID: 20141028131310
Gaia: 6926165a173549f2f76f26266cb5121d0411e703
Gecko: dd48bef1b27e
Version: 34.0 (2.1) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Issue does NOT reproduce on 2.2 KK Flame or 2.0 KK Flame.

Actual Results: The text and icons go away as soon as the notification pane is no longer on screen.

Environmental Variables(Shallow Flash):
Device: Flame 2.2
BuildID: 20141028132307
Gaia: b48f66220dff75f767eddf28a1d58192fc811410
Gecko: 53d84829b2b8
Version: 36.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Environmental Variables(Shallow Flash):
Device: Flame 2.0
BuildID: 20141028133309
Gaia: 9f5b6f025e528fabfcc068782cb9b492cb51a7f9
Gecko: de8cfd54bf93
Gonk: Could not pull gonk.  Did you shallow Flash?
Version: 32.0 (2.0) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 3

[Dietrich Ayala (:dietrich)]

Broken primary UI, blocking+.

Comment 4

[Joshua Mitchell (Inactive)]

QA-Wanted: Let's find out what fixed this on 2.2 with a 'fixed' window

Comment 5

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 1061969 seems to have fixed this issue in 2.2.

B2g-inbound reverse Regression Window

Last Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141013082253
Gaia: 83779ff088c794606c00f98851ada88402cb55dd
Gecko: 3f844c63335f
Version: 35.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141013092306
Gaia: ba6667c83c5d0fb1e333349dfeaf5f6ca8043e63
Gecko: 276e5f3aecbc
Version: 35.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Last Broken gaia / First Working gecko - Issue DOES occur
Gaia: 83779ff088c794606c00f98851ada88402cb55dd
Gecko: 276e5f3aecbc

First Working gaia / Last Broken gekko - Issue does NOT occur
Gaia: ba6667c83c5d0fb1e333349dfeaf5f6ca8043e63
Gecko: 3f844c63335f

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/2a536e4df82410178d8440cc710d8f838a95a0b9...4f86c631e0465c0e56ccebeb1324fd28be9ea32f

Comment 6

[Joshua Mitchell (Inactive)]

possibly broken by Bug 1061969 - can you take a look Vivien?

Comment 7

[Ken Chang[:kenkai]]

Wesley, can you check with Vivien about this bug? And can he take this bug?

Comment 8

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #6)
> possibly broken by Bug 1061969 - can you take a look Vivien?

This wasn't broken by bug 1061969, this was fixed in master by this bug. However, that was deemed too risky to uplift to 2.1 as it caused several regressions. If this bug is indeed a blocker though, perhaps we can revisit that decision.

Comment 9

[Kevin Grandon :kgrandon]

I will investigate a fix for v2.1.

Comment 10

[Kevin Grandon :kgrandon]

Attachment: Patch for v2.1 - Wait for utility tray to close before launcing the app

This is a patch which waits for the utility tray to hide before launching the settings app. I don't know what's going on, but this seems to at least mask the issue if we wait for it to fully collapse first. Chris or Etienne - could one of you guys review this? Thanks!

Comment 11

[Etienne Segonzac (:etienne)]

Comment on attachment 8517751 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

I think this is the correct fix, some comments on github but mainly I think we need some sanity unit tests (should be straightforward enough).

Comment 12

[Chris Lord [:cwiiis]]

Comment on attachment 8517751 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

So I don't think this will cause any harm and there's already a todo about using web activities here, so I assume the code is going to be changed out at some point in the near-ish future.

That said, I think Etienne's comments should be addressed and I'd quite like my comment addressed to. I don't think that needs to block landing if you want to get this out of the way though.

Comment 13

[Kevin Grandon :kgrandon]

Ok, so I think moving it to the transitionend in the init() made things quite clear. In addition I added one simple test for the event, so I think we are good to go here. 

Going to mark this as fixed and request uplift approval because it only has to go to v2.1.

Comment 14

[Kevin Grandon :kgrandon]

Comment on attachment 8517751 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): "Peakable" statusbar feature implementation/performance issue.
[User impact] if declined: Poor experience when tapping on the settings icon after viewing the utility tray.
[Testing completed]: Manual, and a tiny unit test.
[Risk to taking this patch] (and alternatives if risky): Fairly low risk as it's not really changing any existing behavior, just adding a bit of a wait.
[String changes made]: None.

Comment 15

[bhavana bajaj [:bajaj]]

Comment on attachment 8517751 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

QA, this is a branch specific patch for 2.1. Please verify the fix on 2.1 post landing.

Comment 16

[sarsenyev]

Attachment: 2014-11-07-15-28-29stillRepron2-1.png

The issue still repro on 2.1 Flame
Notification and "Settings" page opens in the same time, which cause of overlapping issues, see the new attached image.
The repro rate is about 60% 3/7

Device: Flame 2.1
BuildID: 20141107001205
Gaia: 6295f6acfe91c6ae659712747dd2b9c8f51d0339
Gecko: 8c23b4f2ba29
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 17

[sarsenyev]

leaving "Verifyme" due the failed-verification

Comment 18

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/3fc987680a19be2cbbb069c25e10f24cdda4d0c9

Comment 19

[KTucker [:KTucker][Inactive 3/4/2016]]

Sergey, the patch was just uplifted today. Can you recheck this on Monday?

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Either this or bug 1089010 broke Gip tests on b2g34:
https://treeherder.mozilla.org/ui/logviewer.html#?job_id=29414&repo=mozilla-b2g34_v2_1

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Backing this one out first:
v2.1: https://github.com/mozilla-b2g/gaia/commit/0ec1925fc37b7c71d129ae44e42516a0cfb013c4

Comment 22

[Kevin Grandon :kgrandon]

Attachment: Patch for v2.1 - Wait for utility tray to close before launcing the app

Here is a renewed patch for v2.1, this time with an update for the test. Sorry about that.

Comment 23

[Kevin Grandon :kgrandon]

Comment on attachment 8519365 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

Florin - could you review the small change I've made here to the gaia ui python test? Since this action now waits for the transition to complete, I've changed the assert to a waitFor. Let me know if this works for you. Thanks!

Comment 24

[Florin Strugariu [:Bebe]]

Comment on attachment 8519365 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

Python part looks OK 
Also tested this locally and it works

Comment 25

[Kevin Grandon :kgrandon]

Comment on attachment 8519365 [details] [review]
Patch for v2.1 - Wait for utility tray to close before launcing the app

Thanks for the review, also carrying the previous review from :Cwiiis here.

Comment 26

[Kevin Grandon :kgrandon]

Re-landed in v2.1: https://github.com/mozilla-b2g/gaia/commit/4e3996d6df510b5ec91741ba96161a2a27cc6dbb

Comment 27

[Brogan Zumwalt [Inactive]]

Issue verified fixed on Flame 2.1

Actual Results: Utility tray closes before Settings screen appears. While notifications tray scrolls up the icons go with it and are not visible in background.

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141110001201
Gaia: 4e3996d6df510b5ec91741ba96161a2a27cc6dbb
Gecko: 97487a2d1ee6
Gonk: 
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0