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

VERIFIED FIXED in Firefox OS v2.0

Status

Firefox OS
Gaia::System::Window Mgmt
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: Brogan Zumwalt [Inactive], Assigned: etienne)

Tracking

({branch-patch-needed, regression})

unspecified
2.0 S6 (18july)
ARM
Gonk (Firefox OS)
branch-patch-needed, regression

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

Details

(Whiteboard: [273MB-Flame-Support],[2.0-exploratory][systemsfe], URL)

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 8453344 [details]
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
(Reporter)

Comment 1

4 years ago
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
(Reporter)

Comment 2

4 years ago
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.
Please update the 2.1 tracking flag.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(bzumwalt)
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.1: --- → affected
Flags: needinfo?(bzumwalt) → needinfo?(ktucker)
(Reporter)

Updated

4 years ago
status-b2g-v1.4: unaffected → ---
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Wrong behavior. We probably should get this fixed.
Blocks: 1015336
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+][VH-FL-blocking-][VH-FC-blocking+]
Whiteboard: [273MB-Flame-Support],[2.0-exploratory] → [273MB-Flame-Support],[2.0-exploratory][systemsfe]
blocking-b2g: 2.0? → 2.0+
Dale, can you take a look?
Flags: needinfo?(dale)
can do
Assignee: nobody → dale
Flags: needinfo?(dale)
Target Milestone: --- → 2.0 S6 (18july)
Whiteboard: [273MB-Flame-Support],[2.0-exploratory][systemsfe] → [273MB-Flame-Support],[2.0-exploratory][systemsfe][ETA=7/16]
Whiteboard: [273MB-Flame-Support],[2.0-exploratory][systemsfe][ETA=7/16] → [273MB-Flame-Support],[2.0-exploratory][systemsfe][ETA=7/17]
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
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
I don't agree. This is wrong behavior on an obvious user flow, so does actually need to be fixed.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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
blocking-b2g: 2.0+ → 2.0?
Assignee: dale → nobody
(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.
blocking-b2g: 2.0? → 2.0+
This is according to spec.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → INVALID
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(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.
I've pinged bbajaj offline to look into this problem to work on getting consensus across teams here while I'm on PTO.
Flags: needinfo?(bbajaj)
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.
Flags: needinfo?(bbajaj)

Updated

4 years ago
Flags: needinfo?(pdolanjski)
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.
Flags: needinfo?(pdolanjski)
(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?
Assignee: nobody → etienne
We will do a workaround here and just cover the rocketbar.
I believe the code will happen in the system app, so moving into the right component. Thanks for taking this Etienne.
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
(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.
Keywords: regression
(Assignee)

Comment 21

4 years ago
Created attachment 8458032 [details] [review]
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.
Attachment #8458032 - Flags: review?(21)
(Assignee)

Comment 22

4 years ago
https://github.com/mozilla-b2g/gaia/commit/946c019bd52af3de71895e8a7c54c48e58ad6bf1
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Needs rebasing for v2.0 uplift.
status-b2g-v2.1: affected → fixed
Flags: needinfo?(etienne)
Whiteboard: [273MB-Flame-Support],[2.0-exploratory][systemsfe][ETA=7/17] → [273MB-Flame-Support],[2.0-exploratory][systemsfe]
Keywords: branch-patch-needed
(Assignee)

Comment 24

4 years ago
Created attachment 8460782 [details] [review]
Gaia PR against 2.0

Waiting for the CI to run then I'll merge it.
Flags: needinfo?(etienne)
Duplicate of this bug: 969082
Created attachment 8531150 [details]
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
Status: RESOLVED → VERIFIED
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.