Could you describe the "weird behavior" so that we do not necessarily need to watch the video?

Removing "Regression" since this has been around since 64. I also doubt this is a P1.

Also, is the behavior specific to files captured from the camera app, or does it occur with other similarily sized files?

I watched the video but I still have no idea what "weird behavior" is referring to.

Repro steps:
(1)Sign in to user -> Go to camera App -> take a picture  and now save the picture to disk(Saved with .jpg extension in Files App)
(2)Go to chrome://settings/changePicture page -> Select 'Choose a file' option -> Now select captured picture from Files App
(3)Observe delay is seen after choosing picture
(Please refer Screenshot)

C#3>
Yes, Issue is seen with files captured from the camera app

C#4>
Delay is seen after after choosing picture and transparent 'Select a file to open' window is seen (Please refer Screenshot)

Deleted: Actual_Behavior.png 174 KB

	Actual_Behavior.png 174 KB View Download

re comment #5:
So the "weird behavior" is the dealy after selecting the file (from 0:28 until 0:30) where a translucent dialog image is still visible? Pease confirm.

re: re: comment #3:
The question was, does the issue *only* occur with files captured from the camera app, or does it occur with any file?

This sounds like an issue with the file select dialog and not the Settings UI. -> fukino@

It could also be a window manager issue, please reassign to oshima@ if that appears to be the case.

C#7>
1)Yes after selecting the file a translucent dialog image is still visible (from 0:28 until 0:30)

2)Yes Issue is seen with files captured from the camera app only.
I tried with downloaded images( .jpg extension )and with Screenshot files(.png extension) but unable to repro the issue

Thanks..!!

Ok, I understand what 'weird behavior' is referring to now. This is not really specific to the change picture page. It's a general issue where the main UI thread is blocked for some reason and can't produce the frames needed to run animations at the expected speed (fade out animation for dialog in this case). That can happen for a number of reasons.

In this case, it seems like the loading of images will sometimes result in processing on the main browser thread that takes a long time. Not sure what that processing is yet. However, you can see the main browser thread being busy in a trace. I haven't found a trace event that explains what this processing is yet but it shouldn't be hard to track down.

We should fix this by either eliminate the processing or moving it off the main thread.

Managed to capture a trace of the problem. See attached screenshot.

Problem is that UserImageRequest::OnImageDecoded is blocking the main browser thread. 350ms on my i7 pixelbook. That will likely be more than a second on a slower machine:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/users/avatar/user_image_loader.cc?l=146

As you can see in the trace, GetBitmapDataUrl is part of that cost:
https://cs.chromium.org/chromium/src/ui/base/webui/web_ui_util.cc?l=35

These expensive operations needs to be moved off the main thread.

Moving to M-67, please update if incorrect.

From #11 and #12, this is not files app.