3.5 Media: "From URL" doesn't provide any feedback on error

[Viper007Bond]

If you paste an image URL into the "From URL" field and your browser fails to load the image, say due to network issues or the image being 404, then you are given no indication as to why the extra fields that would normally show up aren't showing up. This can confuse users.

A simple error message stating the image was not an image or that the image failed to load (misspelling for example) would assist the user in debugging and resolving the issue.

[nacin]

Good point.

I am trying to think of the easiest way to fix this. If it's not a 200, we can show "File not found." Otherwise, it isn't an image, we can maybe reveal the discovered mime type (or do nothing).

The way we detect images is with new Image in JS. I am assuming that won't allow us to do an HTTP status code check.

We can resort to the older, less intelligent UI, which asked "Image" versus "Audio, Video, or Other File" to avoid this kind of ambiguity from being clever but not clever enough.

[johnbillion]

3.4 shows a red X next to the URL input field if it doesn't get a 200 when it tries to fetch the image.

[Viper007Bond]

Replying to johnbillion:

3.4 shows a red X next to the URL input field if it doesn't get a 200 when it tries to fetch the image.

Bonus: no new strings.

[nacin]

Replying to Viper007Bond:

Replying to johnbillion:

3.4 shows a red X next to the URL input field if it doesn't get a 200 when it tries to fetch the image.

Bonus: no new strings.

Right, but we're using that same check to determine if it is an Image. We have no good way of determining if it is not an image (but is, and is failing), or if it is not an image (and really isn't an image).

Can you please test 22740.diff​? What it does is automatically assume that .jpg, .png, and .gif are images, so the fields may be shown, even if it can't load it.

If we wanted to top this off, we can probably also add back a red X if it thinks it is an image based on the extension (which will show the fields) but fetching it doesn't work (which will tell the user something is wrong).

[Viper007Bond]

This patch should certainly help with most cases. There's still a few edge cases but those are extra edgy because it also has to additionally fail to load.

Looks good to me.

[nacin]

I think 22740.diff​ is likely sufficient for 3.5.

[ryan]

In 23048:

When inserting an image From URL, show the fields only if it looks like we have a valid image.

Props koopersmith
fixes #22740

[ryan]

A couple of times I've seen the insert button remain inactive even though the image and the details show.

[koopersmith]

Replying to ryan:

A couple of times I've seen the insert button remain inactive even though the image and the details show.

Did you happen to record the URL in those cases?

[ryan]

​http://trunk/wp-content/uploads/2012/12/avast12.jpg

Most of the time it works. Sometimes not. Haven't been able conjure reliable steps to reproduce.

[ryan]

https links not working but could be my sandbox SSL setup.

Insert a link. Modal closes. Click Add Media to pop the modal back up. From URL still shows the image that was just inserted. Maybe this should lose its memory after a successful insertion.

[nacin]

Two issues:

• The button disabling check should simply be prop('disabled', '​http://' === text). It is designed to prevent insertion when the placeholder is there.
• The view should lose its memory.

Koopersmith working on both.

[ryan]

In 23065:

Clear the From URL view in the media modal after inserting an image. Improve button enable checks.

Props koopersmith
fixes #22740