1036642 - [B2G][Homescreen] User cannot access rocketbar when returning to homescreen from active call

Status: VERIFIED FIXED

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

Description

[Brogan Zumwalt [Inactive]]

Attachment: Logcat

Description:
When user is in an active call, returning to homescreen and tapping on rocketbar search bar brings up the dialer. Rocketbar opens normally from homescreen when no active call exists.


Repro Steps:
1) Update a Flame to 20140707000200
2) Launch dialer and make phone call
3) Return to homescreen
4) Tap Rocketbar


Actual:
When user taps rocketbar during active call the dialer opens.


Expected:
Rocketbar opens when user taps rocketbar.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140708000322
Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546
Gecko: 3f9d7a3a0b7b
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 3/3, 100%
See attached: Youtube video clip & logcat
Youtube video link: http://youtu.be/JXt5NUl3qgg

Comment 1

[Brogan Zumwalt [Inactive]]

Issue DOES occur in 2.1 Flame and 2.1 Buri

Environmental Variables:
Device: Flame Master
BuildID: 20140709040203
Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f
Gecko: 196d05832e12
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Environmental Variables:
Device: Buri Master
Build ID: 20140709073020
Gaia: c394b7b4205b6f1a6ca44915fc08650f3ad127ec
Gecko: 2d88803a0b9c
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Actual Results: When user taps rocketbar during active call the dialer opens.


Issue does NOT occur on 1.4 Flame and 1.4 Buri due to lack of Rocketbar

Environmental Variables:
Device: Flame 1.4
Build ID: 20140709003002
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: acf704e54e19
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Environmental Variables:
Device: Buri 1.4
Build ID: 20140709003002
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: acf704e54e19
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual Results: Homescreen has old e.me search bar. Rocketbar not present.

Comment 2

[Brogan Zumwalt [Inactive]]

Issue occurs on 2.0 Flame devices with both 512mb and 273mb memory.

Though 1.4 does not have rocketbar, the e.me search bar is present on homescreen and can be used normally when user has an active call.

Comment 3

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

Please update the 2.1 tracking flag.

Comment 4

[Jason Smith [:jsmith]]

Wrong behavior. We probably should get this fixed.

Comment 5

[Gregor Wagner [:gwagner]]

Dale, can you take a look?

Comment 6

[Dale Harvey (:daleharvey)]

can do

Comment 7

[Dale Harvey (:daleharvey)]

This behaviour is on expected, the explanation is @

https://github.com/mozilla-b2g/gaia/commit/92913fa6c4ea913d0fad92695aade9b0d9d8ca1b#diff-073a78df881c9ceed761f46277668e92R205

The behaviour will change in 2.0 with a refactored attention screen and rocketbar layout, but currently with the 2 overlapping this behaviour is desired

Comment 8

[Jason Smith [:jsmith]]

I don't agree. This is wrong behavior on an obvious user flow, so does actually need to be fixed.

Comment 9

[Dale Harvey (:daleharvey)]

The user should be able to access the rocketbar with a call in progress, but both the layout and architecture make this functionality problematic.

Accessing the rocketbar to open applications wasnt considered critical as the user can still access the browser and applications view the homescreen.

Any changes to the attention screen z-index which would be required to change this behaviour are considered extremely risky at this point and gregor / peter indicated that viviens solution is adequate at this point.

Removing blocking and renominating so this can be triaged accordingly

Comment 10

[Jason Smith [:jsmith]]

(In reply to Dale Harvey (:daleharvey) from comment #9)
> The user should be able to access the rocketbar with a call in progress, but
> both the layout and architecture make this functionality problematic.

I don't think this affects a blocking decision. This means we've got a long road ahead of us to fixing this.

> 
> Accessing the rocketbar to open applications wasnt considered critical as
> the user can still access the browser and applications view the homescreen.

This destroys the entire point of what the rocketbar is supposed to do.

> 
> Any changes to the attention screen z-index which would be required to
> change this behaviour are considered extremely risky at this point and
> gregor / peter indicated that viviens solution is adequate at this point.
> 
> Removing blocking and renominating so this can be triaged accordingly

I do not think this will pass certification. We have requirements that require that basic phone operations must remain usable during a phone call. This bug breaks that rule in a basic use case, which means that this stays as a blocker.

Comment 11

[Gregor Wagner [:gwagner]]

This is according to spec.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #11)
> This is according to spec.

I already explained above that I don't agree with this. This would destroy the entire point of the rocketbar.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #12)
> (In reply to Gregor Wagner [:gwagner] from comment #11)
> > This is according to spec.
> 
> I already explained above that I don't agree with this. This would destroy
> the entire point of the rocketbar.

i.e. a user does not expect the fact that clicking a rocketbar would open the dialer app. That's clearly a bug to a user, so I think the spec is wrong.

Comment 14

[Jason Smith [:jsmith]]

I've pinged bbajaj offline to look into this problem to work on getting consensus across teams here while I'm on PTO.

Comment 15

[bhavana bajaj [:bajaj]]

After the reading the bug comments here, It just seems like rocketbar is non-functional while I am on the call which I think is not acceptable. Before resolving this invalid, let's hear from

a) Product. Peter can you help understand if the current workflow is acceptable ? I am pretty sure this must have been considered when spec'ing it out. What was the thought process then ? Clicking the search bar would launches a dialer app, does not help when a user may actually be trying to use the "rocketbar" for a valid search.
b) We should also take an opinion from Tef on the cert blocker issue that :jason raised once we have information from product.

Comment 16

[Peter Dolanjski [:pdol]]

I think it is acceptable that Rocketbar doesn't function, but it is not acceptable that it is in plain view and touching it invokes a different action.

Comment 17

[Jason Smith [:jsmith]]

(In reply to Peter Dolanjski [:pdol] from comment #16)
> I think it is acceptable that Rocketbar doesn't function, but it is not
> acceptable that it is in plain view and touching it invokes a different
> action.

I can see by this statement that there's agreement there's a bug here, but...

I'm not sure I agree with the view that it's acceptable that the rocketbar can't function in a call. Past releases allowed the user to use e.me search while in a phone call. Now, we're banning this in a later release, which is a huge feature loss to the user. If I was a vendor, this could cause me to question to consider even picking up 2.0 with this problem. Why? Cause I'm not getting the parity I need with the old homescreen implementation during a phone call. One of the biggest selling points you need to give to a vendor and users doing an upgrade path is that there's higher value in upgrading the device to a new version rather than not upgrading users. Why am I going to care about upgrading if I'm losing a significant amount of functionality in the process?

Comment 18

[Gregor Wagner [:gwagner]]

We will do a workaround here and just cover the rocketbar.

Comment 19

[Kevin Grandon :kgrandon]

I believe the code will happen in the system app, so moving into the right component. Thanks for taking this Etienne.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #18)
> We will do a workaround here and just cover the rocketbar.

I don't think there's agreement here yet on what we're doing here per comment 17. This would be a regression between releases anyways if we disabled e.me search while the dialer was active.

For the record, TEF indicated this isn't a cert blocker, but did indicate that this is a regression between releases that must be fixed in order to maintain parity between releases.

I would like an answer to comment 17.

Comment 21

[Etienne Segonzac (:etienne)]

Attachment: Gaia PR

This patch lets the user access the rocketbar (and everything.me) while on a call. With no z-index tweak (which would have been risky).

Vivien I'm asking you for review because IIRC you know the edge cases for this very well.

Comment 22

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/946c019bd52af3de71895e8a7c54c48e58ad6bf1

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing for v2.0 uplift.

Comment 24

[Etienne Segonzac (:etienne)]

Attachment: Gaia PR against 2.0

Waiting for the CI to run then I'll merge it.

Comment 25

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/ed998af8528c8b1bbd3aee6975ee9a1bdec1d429

Comment 27

[Shine(Leave from Mozilla)]

Attachment: video

This issue has been verified successfully on Flame 2.0 and 2.1
See attachment: Verify_1036642.MP4
Reproducing rate: 0/5
Flame 2.0 build:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141201000201
Version         32.0
Flame2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141201001201
Version         34.0