Thank you iionly - it works fine.

As a matter of fact, I have tried this solution previously, but it has not worked. Also, when I tried your suggestion at the fist time, it did not work. However, only after I cleaned my Chrome history it worked.

As far as I understand the browsers do not cache JS files from https sites. It it correct?

Had you also flushed the caches of your site in the admin area? That's necessary after you made the change as the js file is cached on server side with the Elgg caching options enabled. I don't know about browser caching js code. But I guess it might keep it at least for the session.

I work on a development site and all the caches are disabled, and as you see below there is no need to do it.

I made a detailed research with Chrome, FF, IE and Opera. All are the latest version.

I changed the image size in the JS file a few times, back and forth, from medium to large. Only in Opera I had to clear the history. All the rest responded immediately.

Regarding Opera, I also tried to flush the site caches, but still I had to clear the history to get the desired results.

P.S. I work on PC - so I could not check Safari.

If you override the view mod/file/views/default/resources/file/view.php with a modified version where you enclose the registered of the download title menu button with

if (elgg_is_logged_in()) {
    elgg_register_menu_item('title', array(
        'name' => 'download',
        'text' => elgg_echo('download'),
        'href' => elgg_get_download_url($file),
        'link_class' => 'elgg-button elgg-button-action',
    ));
}

only users who are logged-in to your site will see the download button whereas logged-out visitors will only see the file (as long as its access level is public) but don't see the download button.

Learn how to override views: http://learn.elgg.org/en/stable/guides/views.html#overriding-views. That's better than modifying the file plugin file in the long run.

Here is my feedback.

This is very good and necessary plugin. Usually it works OK (Chrome, FF, IE, Opera) on all the websites (Dailymotion.com, Vimeo.com, Youtube.com).

However:

1. Sometime the server does not respond, and I get error 500.

2. In Youtube I found a few videos that behave very strange - I receive many red notifications. For example, please check https://www.youtube.com/watch?v=h9CzJkxKKd0 and https://www.youtube.com/watch?v=rcybIgUdUa0

What is common to both sites is that their entire screen is a link to their website.

3. Regarding API Key of Youtube - It works when the API Key has no "Restrictions". It does not work when I restricted to IP or HTTP referrers - maybe I made some mistake here.

4. In the Video page - please consider to put all the list of option (Recently viewed videos, Recently commented videos, etc.) in a dropdown list.

5. Lastly - it would be great if we can embed videos in blogs, pages, comments, etc. I know that HTMLawed blocks this feature, but we might have a workaround. I'll describe the idea in other discussion.

One more comment:

When click on Video in Group you get the following notification

Sorry. We could not find the page that you requested.

Thanks for the feedback. I rather expected some remarks about the upgrade/migration process as this is something really new (as the html5 video support is newly added). Nevertheless, it never hurts to know about bugs or other shortcomings.

The group video page issue is probably new in version 2.3.4. I will have it fixed in the next release.

Embedding videos in other posts is probably a feature to be added rather on medium to long term than on short terms. I hadn't even thought about it yet. It might have been possible back in the pre Elgg 1.8 days even but due to changes in the embed plugin (and possibly mainly due to htmlawed becoming more restrictive) it became non-functional (I remember that I removed some code but I don't remember if I removed it because it never worked in the first place or stopped working at some point). This kind of embedding is also slightly different from the embedding option that is still available. This option is working the other way round: by providing some embed (html) code you would add a video entry on the site where the video is hosted elsewhere. And providing some arbitrary html code for embedding a video is a problem as the code could also contain bad stuff. Without lessening the htmlawed rules this is sure to fail and lessening the rules is calling for problems. So, in the long run I might even completely remove the current embedding option as it just makes not much sense anymore nowadays.

Youtube API key must be unrestricted. I might have to add some remarks about that in the readme. In the past there was a clear difference between a "server API key" and a "browser API key". The server API key always had no restrictions (as it's meant to never be shared with users anyway). Now they have unified the key creation for the different types but apparently haven't managed to update their docs accordingly. They seem to change their dev tools management pages a lot and it's an endless job trying to keep the docs up-to-date.

Sidebar menu entries: let's see when I have to to play with it. Maybe a single dropdown menu is better. I will have to try it out.

Is the 500 http error also occuring when trying to add a (off-server) video? Is it happening always for a specific video or is there no correlation between the video you want to add and the error occuring. The other issue with the red error messages showing up could be due to some videos being restricted (e.g. forbidden to be embedded on other sites). I never had the nerve to really look into this matter. Possibly, there are some errors submitted that might contain some useful info about what's going wrong and catching these errors would possibly prevent the confusing error messages to show up and show a single meaningful error message instead.

FormData is fully supported in 3.0, I made sure of that :)

In theory elgg/Ajax is just a wrapper around jQuery Ajax API. You can copy it into another AMD module and hack it to support FormData

@Ismayil -- that's great news about 3.0.  Thanks for confirming it supports FormData, and for your work on it!

I think I can live with my hacky iFrame approach in 2.3.x for now, knowing it can go away in the not-too-distant future.