1184772 - [Dialer] The search bar will overlap the call screen if the user opens the call screen while typing in the search bar

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Status bar, Utility tray, Notification, defect, P1)

Description

[Adam Alldredge [:AdamA][Inactive]]

Attachment: logcat

Description:
When the user is in a call and presses the home button they will go to the homescreen with a call banner at the top of the screen that will go away after a moment. if the user is typing in the search bar at the top of the home screen and taps on the call banner at the top of the screen they will see the search bar overlap the screen while the call screen is opening.

Repro Steps:
1) Update a Aries to 20150716033647
2) Receive a call from another device and answer
3) Press the home button
4) On the homescreen press on the search bar to enter text
5) Press the call banner at the top of the screen
6) Observe search bar overlapping the call screen

Actual:
The text entry search field overlaps the call screen

Expected:
It is expected that search bar doesnt overlap the call screen

Environmental Variables:
Device: Aries 2.5 [Full Flash]
BuildID: 20150716033647
Gaia: 981c61cdeb527fac8f8383c110df0e749eff67ea
Gecko: 72835344333f
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Repro frequency: 10/10
See attached: Video(https://youtu.be/hF0am3Qwsw8), logcat

Comment 1

[Adam Alldredge [:AdamA][Inactive]]

This issue DOES occur on Flame 2.5.

Environmental Variables:
Device: Flame 2.5 [Full Flash]
Build ID: 20150715160204
Gaia: b9968cdc4a1dee49848fed6159a59c378cea062d
Gecko: 49683d4e9ebd
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Result:
The text entry search field overlaps the call screen
--------------------------------------------
This issue DOES NOT occur on Flame 2.2.

Environmental Variables:
Device: Flame 2.2 [Full Flash]
BuildID: 20150715002506
Gaia: 84d0c76370dcd3d25813b00de55194730884355b
Gecko: a5db6d9850f6
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Result:
Search field is behind call screen

Comment 2

[Johan Lorenzo [:jlorenzo]]

[Blocking Requested - why for this release]: Visible regression.

I'm not sure the problem in on the Gaia side. Kevin, do you confirm this issue needs to be moved to Graphics?

Comment 3

[Kevin Grandon :kgrandon]

I can't really say whether or not it's a graphics issue without doing a deep investigation, and not sure if I have cycles for that right now. There may be some gaia workaround we can implement though.

Comment 4

[Peter Bylenga [:PBylenga]]

Requesting a window to assist here.

Comment 5

[Pi Wei Cheng [:piwei] (inactive)]

On 2.2 when transitioning it still shows some sort of residue of search bar for a split second; it's not a clear transition either. If I take this behavior as a reproduction then this is not a regression (occurs on v2.1 as well, and v2.0 doesn't have call banner implemented). For now I'm treating 2.2 as working and see where it takes me.

Comment 6

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20150709105424
Gaia: 73ece50d39e5949a5eaa942820300cd23a4c3f7c
Gecko: 6eb389866758
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken
Device: Flame
BuildID: 20150709115322
Gaia: 31eed4c0ab1a32f1a5bf8acac723595b61902027
Gecko: 81af3a741875
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Last Working Gaia First Broken Gecko - no repro
Gaia: 73ece50d39e5949a5eaa942820300cd23a4c3f7c
Gecko: 81af3a741875

Last Working Gecko First Broken Gaia - repro
Gaia: 31eed4c0ab1a32f1a5bf8acac723595b61902027
Gecko: 6eb389866758

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/73ece50d39e5949a5eaa942820300cd23a4c3f7c...31eed4c0ab1a32f1a5bf8acac723595b61902027

Caused by changes made in Bug 1177477.

Comment 7

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

Alberto, can you take a look at this please? This might have been caused by the landing for bug 1177477.

Comment 8

[Alberto Pastor [:albertopq]]

I'll take a look when possible, but given the issue, I think is more a polish bug than a blocker.

Comment 9

[Wilfred Mathanaraj [:WDM]]

[Blocking Requested - why for this release]:

i think there is a valid use case where the user can do two activites at the same time - it is a very common scenario where users will run into this issue. I would like this to be fixed as it has a visble regression from previous releases.

Comment 10

[Gregor Wagner [:gwagner]]

Not blocking but we want to fix it in time.

Comment 11

[Alberto Pastor [:albertopq]]

I'm not able to repro it, even enabling slow animations... Is this still happening?

Comment 12

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

This issue is still occurring on today's master on Aries. 

The search bar will overlap the call screen following the steps in Comment 0. 

Environmental Variables:
Device: Aries 2.5
Build ID: 20150728162417
Gaia: 302a448729ff2b336581cf94b66327ea836294c7
Gecko: cd9fa05c943e6784faeeaff7c027d1b561c070b0
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 13

[Alberto Pastor [:albertopq]]

I think this might be a dupe of bug 1187526. Adding qawanted to test if the patch in bug 1187526 helps.

Comment 14

[Pi Wei Cheng [:piwei] (inactive)]

This issue is still reproducing on latest b2g inbound build that contains fix for bug 1187526.

Alberto, if you can't repro the bug please look at the video https://youtu.be/hF0am3Qwsw8 . It should help you repro the bug.

Device: Aries 2.5
BuildID: 20150810172521
Gaia: 9a8880a95ee4a4aea7895d4e2bcab31bc49ea281
Gecko: 027b608d70df
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 15

[Alberto Pastor [:albertopq]]

I think this is a graphics issue with the z-index while the opacity of the search input is transitioning. Chris, what do you think?

Comment 16

[Chris Lord [:cwiiis]]

Possibly, but I don't know the details of how opacity/transitions affect stacking contexts, this may well not be a bug depending on how the DOM is organised.

It'd make sense to me to explore that avenue first, with someone on Gaia that knows this part of the UI code well and someone on layout who knows the details of how stacking contexts are determined well.

I'd have thought we could work around this with some fiddling, either way?

Comment 17

[GitHub Autolander Bot]

Attachment: [gaia] albertopq:1184772-search-overlap > mozilla-b2g:master

Comment 18

[Alberto Pastor [:albertopq]]

:piwei, could you please check if the attached patch helps? Thanks!

Comment 19

[Pi Wei Cheng [:piwei] (inactive)]

Adding QAwanted to test the patch (I'll be testing it).

Comment 20

[Pi Wei Cheng [:piwei] (inactive)]

The patch does seem to help, and with patch it looks very similar to the behavior I observed on 2.2 (please see comment 5). I'm providing a video of bug behavior after patch:

https://www.youtube.com/watch?v=cKjBs2hfm3c

Comment 21

[Alberto Pastor [:albertopq]]

Comment on attachment 8651720 [details] [review]
[gaia] albertopq:1184772-search-overlap > mozilla-b2g:master

Kevin, what do you think? Removing the transition in the input element doesn't seem to affect to the rest of animation. Should we remove it?

Comment 22

[Kevin Grandon :kgrandon]

Comment on attachment 8651720 [details] [review]
[gaia] albertopq:1184772-search-overlap > mozilla-b2g:master

If you go into the browser with this patch applied it causes the rocketbar to immediately appear, instead of smoothly fade in.

Shouldn't we either backout or rework bug 1177477?

Comment 23

[Alberto Pastor [:albertopq]]

I think this is more a graphics issue, and backing out bug 1177477 doesn't seem the right solution to me. I didn't see the animation being affected by my patch, so that's why I thought it was legacy code, but didn't think about the Browser.

I'll try to find another workaround.

Comment 24

[Alberto Pastor [:albertopq]]

Not working on it at the moment. Will come back to it as soon as I have time

Comment 25

[BMO Automation]

Firefox OS is not being worked on