+++ This bug was initially created as a clone of Bug #649482 +++ Created an attachment (id=705918) pic DEFECT DESCRIPTION: Interface will black about 2s when you select a drop down box REPRODUCING PROCEDURES: 1.Into the settings->Sound->Ringer; 2.Enter the drop down box, then back; 3.Again enter the drop down box,this interface will black 2s-KO. NOTE: Beelte_lite_FF 1.1 is OK. EXPECTED BEHAVIOUR: The drop down box interface don't back ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: Medium REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior: ++++++++++ end of initial bug #649482 description ++++++++++ DEFECT DESCRIPTION: REPRODUCING PROCEDURES: EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:

I believe ringtone selection is performed in a separate app which means we're launching a process. The enter ringtone selection, then leave, then enter selection again is probably too quick to allow the pre-allocated process to launch in the background. This means the second time you enter ringtone selection you are launching a brand new process which adds about half a second at least.

Dear Ben, Our Val think that the poor user experience, could you have some idea to fix it?

The video of this issue, as you can see, the blank screen sometime can last about 2 seconds https://www.youtube.com/watch?v=jEiJcNhBhyk&feature=youtu.be

So I think there are a couple issues here: 1) We can't launch apps (like the ringtone selection process) instantly. 2) The transition animation is poorly chosen given (1). We slide up a black screen as we are loading the app. I don't think we will ever be able to solve (1). In particular, if you long ringtone selection twice very quickly you will not get the preallocated process optimization. We won't be able to fix this in the short term, but it might be addressed eventually if we can fork NUWA directly. I think maybe we should adjust the transition animation to minimize the impact instead. Eli, Gordon, can you suggest a better way to make this transition given that the selection app may take an extended period to load?

UE is really not good, please help to fix it in 1.3, thanks.

As Ben mentioned in Comment#6, there is no way to fix this issue in short term, also although it is bad user experience, you need to re-launch the ringtone selector really quick to reproduce this. So i don't think user will encounter this issue much. Hence de-nom

As far as UX is concerned, I don't believe that using a sliding animation to show something that isn't loaded is a good experience. It would be better to use a fade transition to show a loading screen like we do for other apps, but maybe something more appropriate for the ringer selection process. With a fade transition, we can control the duration of the fade to account for longer loading times while still trying to hit a goal of 1 second for acceptable perception of progress.

Sounds like a UX Frameworks question. Needsinfo Harly.

I think that if we use a back button on the header, we should do a slide-in from right to left, rather than bottom to top. Tiffanie is working on a new design for ringtone picker, maybe she has some insights on this.

[Blocking Requested - why for this release]:It is still bad UE in 2.0, do need to improve. It is easy to reproduce when leave and re-enter the 'select sound' page within 2s, so I guess it may caused by conflict of resource release and application.

Hi Harly: Just a quick question, I saw in comment#11 you said there was some work on-going that time (in May), is that done already now? In FFOS 2.0 or later version? Not sure the problem partner see in 2.0 is still something on-going, or already done. I want to clarify this as an input for our coming Triage for this issue. Sorry I know Tiffanie might be the most suitable person to ask but just don't know her full name, so come to you. Thank you.

Hi Wesly, I have checked on my Flame, and it seems that they use fade in and fade out animation when selecting an ringtone. I still think that it would be good if we can modify it to slide left/right to fit our navigation pattern. Needinfo Katie as she might be able provide some info on this.

I agree with Harly's comment above about using the slide left/right pattern to fit the Settings navigation pattern. NI'ing Jim - he's been working on some of the updates in Ringtones, and may be able to chime in on this.

Sure, the system app folks could do something to define how transitions work for activities, but this is something I'd consider extremely low priority.

Thanks for your comments! Harly, Katie, and Jim!, the I tend to put it as de-nom candidate in coming 2.0 Triage (maybe nom. to 2.2 for future planning consideration?) Welcome to share your though if any.

[Traige] de-nom. as current design limitation, can consider to do in future release per comment#14, comment#15, and comment#16. ni Howei: would you consider to implement in future release, ex: 2.2?

This seems already improved in 2.2. qawanted to check master if the issue still exists, thanks. Removing blocking nom since this does not block.

Yes this bug still exists in Flame 2.2 KK. If I back out of ringtones and go back in, the screen can remain black for up to 2-3 seconds. Tested with Shallow Flash on 319mb using Engineering builds This bug repro's on Flame KK builds: Flame 2.2 KK Actual Results: Long black screen seen when backing out of and then reentering ring tones selection drop down. Repro Rate: 4/4 Environmental Variables: Device: Flame 2.2 KK BuildID: 20141103040034 Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec Gecko: 5999e92e89ff Version: 36.0a1 (2.2) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

*Correction* 1-2 seconds not 2-3 seconds.

re-nom per comment#20.

Triage: This seems belongs to gaia system.

I've taken a look at this but I'm not clear on what the desired solution is. The delay is caused by the fact that the ringtone picker is an inline activity of the Ringtone app launched by the Settings app. There will always be circumstances under which there is a delay launching this type of web activity as creating a new system process and a new window has overheads. Any change to the opening transition will affect all inline activities across the whole system, not just this one. Some options: 1. Reduce the startup time of the Ringtones picker panel (It's possible we're blocking on I/O somewhere, but given the first startup is fast and subsequent startup is slow suggests it's more of an issue with the platform being able to create a new preallocated process fast enough). 2. Change the transition for inline web activities to try to mask the problem (I'm not convinced there's much that can be done here. Eric, what do you think? Is there a way to give the perception of responsiveness, like showing something during load, or a different transition?) * Change the architecture to use a value selector or a panel in the settings app which reads and writes to a data store shared with the ringtones app, instead of an inline activity in the Ringtones app. (I'm not sure why the ringtones app is a separate app, but I'm sure there's a reason for it. Jim?). * Try to tweak our process allocation system to make the problem less likely to occur (I have no idea how much there is to tweak. Gabriele, Alive do you have any ideas?) * Don't do anything. The bug only seems to reproduce when the user closes the picker and then quickly opens it again, which is an edge case.

The ringtones app is a separate app for a few reasons: 1) It allows other apps to respond to a "pick" activity for ringtones. We need this for ForwardLocked content, and it also allows third parties to create more interesting ringtone pickers (e.g. one that lets you create a ringtone with a musical keyboard - although we could conceivably allow this via the ringtone manager). 2) It allows other apps to pick ringtones easily. This will matter more once we have per-contact ringtones. 3) A value selector wouldn't have all the nice things that our ringtones app currently has, like previewing the ringtones (which I think is broken right now, to be fair). 4) We also need to consider managing the ringtones list, which is a separate activity. 5) The ringtones app predates the datastore API. We'll probably add support for the datastore API at some point, but the design we use will be dependent on what the contacts and clock apps need for fetching custom ringtones. I haven't seen any updates from either team, though. As far as I've been able to tell, there's nothing blocking the main thread in the ringtones app. Pretty much all IO is async. More generally, if Firefox OS really can't guarantee that activities are launched quickly, then we have much more serious architectural problems than the ringtones app occasionally being slow to open. That said, I agree that this bug is an edge case, and seems like the sort of bug that would affect QA folks a lot more than actual users. I'm not entirely sure of the rationale for marking this a blocker.

(In reply to Ben Francis [:benfrancis] PTO until 5th Jan from comment #24) > 2. Change the transition for inline web activities to try to mask the > problem (I'm not convinced there's much that can be done here. Eric, what do > you think? Is there a way to give the perception of responsiveness, like > showing something during load, or a different transition?) It is possible to show the activity's icon during load (but this cause some reflow as well). I do think we need platform guys to take a look - does killing the old process and launch it at the same time will block the new one to load? I will co-work with Cervantes here. Also, IMO this one is an edge case to block. If we wait for a while and trigger the activity again then this issue will not happen. Why is this blocking?

The black out is the result of launching the activity from b2g. When you launch the ringtone activity the 1st time, there is a preallocated process available, but when you go back to settings and select ringtone again, the preallocated process is not ready. In this case we will launch the activity by fork()+exec() the plugin-container executable. This is pretty slow compared to launching from a preallocated process. This should be fixed by bug 1053634.

Thanks guys, that sounds promising.

After discussion with Gregor, renominating this to have blocking status re-considered. This is quite an edge case but there's an underlying platform issue which is itself nominated for 2.2+

Not blocking since its an edge case.

link all Fire C (codename: Sora) bugs to a meta one.

Firefox OS is not being worked on