Our latest stable and beta channel of M51 will not have  "Merge tabs and apps"  option. Could you please check on M51 and let us know if the problem still exists?

Sorry, our internal KPIs are leaking -- ignore the "pre-condition" list and the targets.

Here's what the bug report should've been:

Performance: Chrome has no Starting Window

When Android starts an activity in a process that has died, it uses the app's theme to create a empty Starting Window. This window starts animating before the app has drawn anything, transitioning smoothly to the real app content once the first frame is drawn. This improves perceived response time (it is used to great effect as a splash screen in many Google apps).

However, some activity flags may mean that a smooth transition from Starting Window to app content cannot be guaranteed, and so Android chooses not to show a Starting Window. This happens to the Chrome browser when started from a "killed" state (for example, swipe it off of Recent Tasks), which makes the launch action feel slow to respond.

You can see the delay with a screen recording (don't forget to enable "show touches" or "pointer location" in developer options):

$ adb shell screenrecord --time-limit 5 --show-frame-time --bit-rate 10M /sdcard/tmp.mp4

It can also be seen easily in a systrace:

$ systrace.py gfx input view wm am res dalvik sched -t 5 -b 10000

I'd suggest checking the time from the last input before Home's activityPause until SurfaceFlinger consumes the first frame from Chrome or its starting window (named "Starting com.chrome...", if it exists). Compare with something like Settings, if needed.

The Main activity is not getting a starting window because it's marked as translucent, which causes us to return at https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r33/services/core/java/com/android/server/wm/WindowManagerService.java#4452

Then, ChromeTabbedActivity gets no starting window because it's being added to an existing task (the one "Main" is the root of).

So, the user gets no real response (the launcher icon pressed state doesn't count) until the Chrome process has started, bound to AM, started *two* activities (and paused one), and drawn its first frame. As such, this time can vary wildly with the device's performance, as well as current load.

(With the apparently now-deleted "merge tabs and apps" option enabled, the second Activity would get its own task, getting a starting window at that point. But before that point, there are still a lot of delays.)


And to answer your question: I installed Chrome Beta (51.0.2704.77) from the Play Store. It still shows the same behavior.

No feedback was received in the last 30 days from reporter "smcsas1@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The latest Chrome Dev on Google Play (53.0.2782.9) is noticably improved: it now starts ChromeTabbedActivity in a separate task from Main (a.k.a. ChromeLauncherActivity), so we get a starting window at that point.

However, the starting window will still be delayed by all the work up until then. For the best launch response time, it would be preferable to allow ActivityManager to create a starting window completely independently of Chrome's launch timing.

As per the comments from  Comment 2 by snild.do...@sonymobile.com, Jun 7, 2016
Issue still reproducible in Chrome Beta (51.0.2704.77) from the Play Store.

Response time is improved in latest Chrome Dev on Google Play (53.0.2782.9)

Please go through the comments from snild.do...@sonymobile.com for more information.

So please reopen the issue as the issue still not fixed. 

This regression has been open for half a year. It's not very actionable and the regression has been in all Chrome user's hands for months.