Closed Bug 1015453 Opened 6 years ago Closed 6 years ago

[B2G][Homescreen]Bookmark icon deletion on Vertical Homescreen demonstrates non-graceful transition between screens

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: mclemmons, Unassigned)

References

()

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

User saves bookmarked icon from Browser App. User long presses bookmarked icon to display red x in upper left of icon. When user selects, the vertical window slides in an upward manner to display a black screen for, at times, nearly a second. Then the Remove text page of the selected website displays with the Cancel and Remove buttons. When performing the same procedure with non-website apps (i.e. Stage), the transition to the Delete question page is graceful and appears seamless.

Prerequisites:

1. Tap Browser App with a data or wifi connection
2. Go to website (google.com) and bookmark the page to the homescreen

Repro Steps:
1) Update a Flame to BuildID: 20140523073020
2) Long press bookmarked icon on homescreen (google.com)
3) Tap red x in corner of the bookmarked icon 

Actual:
The vertical window slides in an upward manner to display a black screen for, at times, nearly a second. Then the Remove text page of the selected website displays with the Cancel and Remove buttons. When performing the same procedure with non-website apps (i.e. Stage), the transition to the Delete question page is graceful and blends rather than appear as a multi-step process.

Expected:
Transition to the Delete page is graceful

2.0 Environmental Variables:
Device: Flame 2.0 MOZ
BuildID: 20140523073020
Gaia: e83bd91c8f7c66f95d55cb741299e12bc8f7b429
Gecko: 681c5668d881
Version: 32.0a1
Firmware Version: v10G-2


Notes: See attached - video clip https://www.youtube.com/watch?v=CKun0lm1lmw, logcat

Repro frequency: 7/10 – 70%
This issue reproduces on Open C Engineering build following the STR from Comment 0. Repro rate is similarly 70 percent. 

2.0 Environmental Variables:
Device: Open_C 2.0
BuildID: 20140523073020
Gaia: e83bd91c8f7c66f95d55cb741299e12bc8f7b429
Gecko: 681c5668d881
Version: 32.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL
There are two different scenarios:

1) Deleting apps

-- The confirm dialog belongs to homescreen app

2) Deleting bookmarks

-- The confirm dialog is performed by an activity implemented by another app called "Bookmark"

For this reason transitions are a bit different and you can see a black screen for a while. This means that if it would be fixed, although I don't see easy fix here, it would be done in a different component than Homescreen. It is just a client which calls to an activity
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
Whiteboard: systemfe → [systemsfe]
No longer blocks: vertical-homescreen
Based on the description and reported repro frequency of 70% I'm going to assume that we are hitting this because we are trying to delete a bookmark, right after launching an application, or deleting another bookmark. This means that we do not yet have the pre-allocated process spun up, so load time takes longer. If we wait ~10 seconds per delete does the issue go away? 

I'm not really convinced that this is currently a common pattern for users, but it's something we're going to have to get better at for haida. 

I would like to close this for now, and take this as a datapoint of something that we need to get better at for haida performance. If you are absolutely convinced that this is a bug, then we would need to reopen and loop in UX for some transition work for activities. We may need to do something like app launch where we display an icon for a brief time.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You're right, I was able to reproduce once over 20 times by launching an app just before hitting the delete button.

I agree this is not a common pattern.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.