The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/71db1d97d86d4bfa89edb4d8b7bbebdecf701b47

commit 71db1d97d86d4bfa89edb4d8b7bbebdecf701b47
Author: gambard <gambard@chromium.org>
Date: Fri Jan 13 12:25:59 2017

Update the Share Extension View

This CL updates the ShareExtensionView, allowing the URL to be displayed on 3
lines and changes the animation of the screenshot view to have it expanding
from the right instead of sliding in from the left.

BUG= 680912 

Review-Url: https://codereview.chromium.org/2629853003
Cr-Commit-Position: refs/heads/master@{#443540}

[modify] https://crrev.com/71db1d97d86d4bfa89edb4d8b7bbebdecf701b47/ios/chrome/share_extension/share_extension_view.mm

The CL changes the animation from a sliding in from the left to an expand from the right.
Amy can you check if the new animation is better?
I could not remove the animation entirely, so if you think of a better animation, please let me know.

can we have it cross-fade in rather than move in directionally? 

One precision on this anumation:
It happens when the screenshot (produced by the host app) is ready, which can happen multiple seconds after the initial display.
It also reduce the size of tue URL/Title box, potentially relayouting them.

Is cross fading adapted?

Assigning to Amy: as you were not in cc, you could not respond...

I'm not able to reproduce the delay or title reconfiguration. Let's optimize for the intended primary case where the image loads immediately and the title doesn't change and keep the cross-fade.  

If that's problematic, my second preference would be to remove the animation entirely. 

The delay is dependent of the host application and cannot be predicted.
To reproduce, use safari and try to share a page you never visited before (there is a really small delay).

For the cross fade, I don't understand how it is done. The image covers the URL?
Can you give us a quick mock?

Mock attached :) 

The image wouldn't cover the URL. The URL placement and size would remain static and the image would fade in when available. 

Deleted: addtoreadinglist-animation-AR_v1.m4v 1.5 MB

addtoreadinglist-animation-AR_v1.m4v 1.5 MB Download

When there is no image, the text takes the whole width.
On this mock, text is ellipsed at 2 third of the widget.
Did that change?

In the case there is no image, should we left a blank zone on the right?

My understanding was that there were 3 possible scenarios rather than 2--

Scenario 1: Image loads immediately 
Scenario 2: Image loads slowly
Scenario 3: No image is available

if 1: image fades in immediately next to (possibly truncated) title & URL
if 2: image fades in when available next to (possibly truncated) title & URL
if 3: no image is fetched and the title & URL space expands to the whole width

Is this accurate or is it actually just 1&2? 

I think there is no 1. Immediately is just slowly, but before you notice it.

We cannot differentiate 2 and 3 before the image arrives. We just ask for the screenshot.
The application can answer, or not. But if it does not give the image, it may give it later.

So if we decide to make title and URL expands to the whole width, we must make room for the image in case it arrives at some point.

Ah I see. When we made the full width title decision, I thought it was for scenario 3 rather than 2. 

To avoid having the text shift around, let's leave the text in the truncated state and then the image can appear when/if available. 

OK.
But this means that for most cases (every application except safari at the moment), we will have a white space on the right.

Is that correct?

Question 1: I understand that there is no boolean response from the host app about whether it has an image to provide us or not. Do we, however, know when we have received an image?

Question 2: Is there any way for us to get a response to question 1 before, say, -layoutSubviews?

If the answer to both my questions is yes, I would like to:
- use the Title + URL + Image layout for scenarios where we have received an image
- use the Title + URL layout for scenarios where we have not received an image

If, however, the answer is no to either of these, I would like to propose we remove the image entirely and only ever do a Title + URL layout (regardless of what the host app gives us in the way of an image).

[chatted with pete offline about this issue, #15 reflects outcomes from that conversation] 

Answer to 1 is yes.
Answer to 2 is yes, and answer is 99.99% of the time no (we almost always receive the image after layoutSubviews).

So IIUC, the solution proposed here is to not show the image at all (except may be 0.01% of times, randomly).
I think this is lowering the user experience and is not better than the current behavior which has a barely noticeable animation issue.

The original scope of the bug was to fade the image in rather than sliding it. If we were to make no additional changes, would it be possible to change the animation? 

IMHO, the behaviour should be left as-is currently.