1154895 - [Status Bar] Icon overlaps with search bar

Status: VERIFIED FIXED

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

Description

[Yeojin Chung [:YeojinC]]

Attachment: Overlapping.png

Description:
When there are multiple icons on the status bar, an icon overlaps with the minimized search bar.

Repro Steps:
1) Update a Flame to 20150414072436.
2) Activate multiple functions to display several icons on the status bar. For example, enable and connect to a Wi-Fi network, enable Debugging via USB, set up an alarm, plug in a headphone and play a radio station.
3) Navigate to Clock app.
4) Observe the status bar.

Actual:
The icon overlaps with the minimized status bar.

Expected:
Not all active icons are shown, and no icons overlap with the minimized status bar. 

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150414072436
Gaia: c8cb0c0ebb8dd1f5c0c9037e38f8e4b237beb77b
Gecko: 388f5861dc7d
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: 5/5
See attached: screenshot

Comment 1

[Yeojin Chung [:YeojinC]]

This issue does NOT reproduce on Flame 2.2.

Result: No icons overlap with the minimized status bar. 

Environmental Variables:
Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150415002502
Gaia: 0b2e2f7c022554d57bf2afed36ba6788249197dd
Gecko: 2356b82e9a50
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[Brogan Zumwalt [Inactive]]

B2G-Inbound Regression window:

More reproduceable STR:
1) In settings enable ADB Developer tools, connect to Wifi hotspot, enable cell data, and enable blue tooth
2) Return to homescreen and launch FM radio
3) Plug in headphones to device
4) Drag down notification tray and press power button to turn off screen
5) Tap power button again and unlock device, observe status bar overlap

Last working B2G-Inbound build:
Device: Flame 3.0
Build ID: 20150322164122
Gaia: c64956619cd1af525a96a0ee4cd1b44baa0d5b53
Gecko: 8f4e7f3bdade
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

First broken B2G-Inbound build:
Device: Flame 3.0
Build ID: 20150322200523
Gaia: 8eac260ee81a8aca05770d18c5736536d44ee7a7
Gecko: 678b074e9e3e
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0


Working Gaia with Broken Gecko issue does NOT reproduce:
Gaia: c64956619cd1af525a96a0ee4cd1b44baa0d5b53
Gecko: 678b074e9e3e

Working Gecko with Broken Gaia issue DOES reproduce:
Gaia: 8eac260ee81a8aca05770d18c5736536d44ee7a7
Gecko: 8f4e7f3bdade


B2G-Inbound pushlog:
https://github.com/mozilla-b2g/gaia/compare/c64956619cd1af525a96a0ee4cd1b44baa0d5b53...8eac260ee81a8aca05770d18c5736536d44ee7a7


Issue appears to have been caused by changes made in 1144713

Comment 3

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

Alive, can you take a look at this please? This looks to have been caused by the landing for bug 1144713.

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

Sure

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

This is not my problem; the root cause is because the minimised width of statusbar is different after this rule 
.chrome-combined .chrome-title-container {
  width: calc(100% - 3.2rem);
}
So the <div.title> width is not SCREEN_WIDTH-8rem anymore.

Checked git blame, I wonder if Bug 1151925 is related. Sam could you take a look?

Comment 7

[Sam Foster [:sfoster] (he/him)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #5)
> This is not my problem; the root cause is because the minimised width of
> statusbar is different after this rule 
> .chrome-combined .chrome-title-container {
>   width: calc(100% - 3.2rem);
> }
> So the <div.title> width is not SCREEN_WIDTH-8rem anymore.
> 
> Checked git blame, I wonder if Bug 1151925 is related. Sam could you take a
> look?

Seems plausible. Where do we expect it to be SCREEN_WIDTH-8rem though? The actual dimensions haven't changed here, I just added this container element to wrap the .title

Comment 8

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

(In reply to Sam Foster [:sfoster] from comment #7)
> Seems plausible. Where do we expect it to be SCREEN_WIDTH-8rem though? The
> actual dimensions haven't changed here, I just added this container element
> to wrap the .title

Kevin, do you know the answer here? I think there are two different collapsed rocketbar widths, but I'm not sure of the difference.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Michael Henretty [:mhenretty] from comment #8)
> (In reply to Sam Foster [:sfoster] from comment #7)
> > Seems plausible. Where do we expect it to be SCREEN_WIDTH-8rem though? The
> > actual dimensions haven't changed here, I just added this container element
> > to wrap the .title
> 
> Kevin, do you know the answer here? I think there are two different
> collapsed rocketbar widths, but I'm not sure of the difference.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/style/chrome/chrome.css#L545
The wrapper you add give more width to the ".url .title" but this breaks the finetune of current minimized width calculation.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/statusbar.js#L429

I am going to finetune it again.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Before adding the wrapper, the minimized width is 126; after that the minimized width is 163.
See
http://imgur.com/WLZKIBv,nv9yapm

I am not sure why this is caused by my bug, but the best solution I have is to modify the minimized width calculation.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #10)
> Before adding the wrapper, the minimized width is 126; after that the
> minimized width is 163.
Sorry, should be 163(before), 126(after). The wrapper decrease the space.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Going to de-assign myself; Michael, could you track this bug in your team?

Comment 13

[Kevin Grandon :kgrandon]

(In reply to Michael Henretty [:mhenretty] from comment #8)
> (In reply to Sam Foster [:sfoster] from comment #7)
> > Seems plausible. Where do we expect it to be SCREEN_WIDTH-8rem though? The
> > actual dimensions haven't changed here, I just added this container element
> > to wrap the .title
> 
> Kevin, do you know the answer here? I think there are two different
> collapsed rocketbar widths, but I'm not sure of the difference.

Not sure I follow, should only be one canonical width that we use in the collapsed state. Maybe we're not calculating the correct width after bug 1151925 landed?

Comment 14

[Sam Foster [:sfoster] (he/him)]

I'm curious how this didn't reproduce on 2.2, as bug 1151925 got uplifted...

Comment 15

[Sam Foster [:sfoster] (he/him)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #11)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #10)
> > Before adding the wrapper, the minimized width is 126; after that the
> > minimized width is 163.
> Sorry, should be 163(before), 126(after). The wrapper decrease the space.

Ok if that's the case, that's the problem, it was not intended to change any dimensions. Did I miss some CSS rule, or is something still measuring .title instead of .chrome-title-container? I have got quite a few blockers on my plate, but I can look into this next week if no-one can pick it up before than.

Comment 16

[Kevin Grandon :kgrandon]

(In reply to Sam Foster [:sfoster] from comment #15)
> Ok if that's the case, that's the problem, it was not intended to change any
> dimensions. Did I miss some CSS rule, or is something still measuring .title
> instead of .chrome-title-container?

That's probably right.

> I have got quite a few blockers on my
> plate, but I can look into this next week if no-one can pick it up before
> than.

Should be an easy fix, I'll take a look.

Comment 17

[GitHub Autolander Bot]

Attachment: [gaia] KevinGrandon:bug_1154895_statusbar_chrome_width > mozilla-b2g:master

Comment 18

[Kevin Grandon :kgrandon]

Comment on attachment 8596728 [details] [review]
[gaia] KevinGrandon:bug_1154895_statusbar_chrome_width > mozilla-b2g:master

Sam or Alive - this should fix it. Either of you able to throw a review on this? Thanks!

Comment 19

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8596728 [details] [review]
[gaia] KevinGrandon:bug_1154895_statusbar_chrome_width > mozilla-b2g:master

Yeah, this looks right and fixes the problem for me when following the STR with the patch applied.

I don't see anything in the tests to update here - maybe (in a followup) we could make these interdependencies explicit?

Comment 20

[Sam Foster [:sfoster] (he/him)]

Can we check/confirm that this bug isn't present on v2.2? It should be, and if it really isn't it would be good to understand why as it might be we need different STR on that branch or something.

Comment 21

[Brogan Zumwalt [Inactive]]

Issue DOES reproduce on latest Flame 2.2 following STR in comment 2

Play icon in status bar is overlapping with the search bar.

Device: Flame 2.2
Build ID: 20150423002502
Gaia: b838d0e7c163e66660dcb6e387d8339944a7a30e
Gecko: 8dce56574f28
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 22

[Sam Foster [:sfoster] (he/him)]

(In reply to Brogan Zumwalt [:BroganZ] from comment #21)
> Issue DOES reproduce on latest Flame 2.2 following STR in comment 2

Ah ha! Thank you. Flagging as potential v2.2 blocker

Comment 23

[Kevin Grandon :kgrandon]

(In reply to Sam Foster [:sfoster] from comment #19)
> I don't see anything in the tests to update here - maybe (in a followup) we
> could make these interdependencies explicit?

Yes, this definitely needs a test, but unfortunately I didn't see an existing one. I'll see what we can do about adding one.

Thanks for the reviews.

Comment 24

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/c4b651dc82eed1a9429ba22db62ba2ff928fb461

Comment 25

[Kevin Grandon :kgrandon]

Comment on attachment 8596728 [details] [review]
[gaia] KevinGrandon:bug_1154895_statusbar_chrome_width > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Caused by rocketbar RTL fixes.
[User impact] if declined: Poor UX with rocketbar when browsing occasionally.
[Testing completed]: Manual testing (working on a test, but that will be a follow-up)
[Risk to taking this patch] (and alternatives if risky): Low risk, simple one-liner.
[String changes made]: None.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/7bdec69704d10f850f114a52a0a292fb0d260c55

Comment 27

[Brogan Zumwalt [Inactive]]

Issue still reproduces on Flame 3.0

Play icon in status bar is overlapping into rocketbar following STR from comment 2. When user populates status bar with 7+ icons, enters FM radio, pulls down notification tray, powers device screen off, then back on before unlocking device, icons overlap search bar in status bar.

Device: Flame 3.0
Build ID: 20150427010202
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 37d60e3b8be6
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Issue verified fixed on Flame 2.2

Following STR in comment 2, no icons appear overlapping with search bar and are dynamically rearranged when new icons are added to status bar. No icons are missing from status bar when notification tray is pulled down.

Device: Flame 2.2
Build ID: 20150427002504
Gaia: 265ca0bc9408c21fc4b25a259fcee7fb642cd06b
Gecko: 1908685d798d
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 28

[Jamie Charlton (:Jamie_)]

This is verified fixed on 3.0
instead of it overlapping the search bar it now makes one or more of the icons hidden as to make it not overlap.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150508010203
Gaia: bc5bfa18f795919b56b952bbf3637c235d0e13dc
Gecko: 356e735fa908
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 40.0a1 (3.0)
Firmware Version: v18D_nightly_v2
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Comment 29

[Brogan Zumwalt [Inactive]]

Confirmed what Jamie is seeing on latest 3.0 nightly, removing qa whiteboard tag.

Device: Flame 3.0
BuildID: 20150513010202
Gaia: 0d6c04f13fd385bda045f4e539b2a67cb5d84b1d
Gecko: 62d9b117c688
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0