All update processes should be within an iframe

[dd32]

Currently some of the update processes run within iframes, others don't.

We should standardise on all within an iframe.

Running inside the iframe has the advantage that the footer of the page is loaded, and therefor, the Toolbar will load, rather than the page appearing half-loaded for certain upgrade/install processes.

Currently, Processes which run inside iframes are Bulk updates, Singular updates load directly.

We should also investigate a iframe overlay that contains a "Working.. please wait" graphic that clears once the content of the iframe starts loading, This should help ease the pain of not being sure if the update process has started on servers that force gzip (and as a result, provide no user feedback until the process is complete) - See #18525 and #18239 for examlples of that see #19783

[DrewAPicture]

+1 for this. I've experienced the "updates hang" issue on many installs. I wasn't aware that some were iframed and others weren't.

[dd32]

iframe'd:

• Bulk Upgrade Theme/Plugins

non-iframe:

• Theme/Plugin upgrade - Singular, non-bulk upgrade (ie. "Update Automatically" was clicked)
• Theme/Plugin Install - from Web
• Theme/Plugin Install - from uploaded Zip

Quick attachment adds Iframe'ing to Singular plugin upgrades, and to singular Theme upgrades. Theme upgrades however have a problem as they include a Preview link (Which I personally think we should just remove). Thoughts on Themes?

[dd32]

A future iteration can remove the singular upgrade code and roll single updates through the bulk handler.

[chriscct7]

Related: #29820

[dd32]

This is mostly rendered invalid by Ajax "smooth updates" going forward.

[obenland]

Wontfix based on the new UI directions that we've taken with shiny updates v1 and v2 in [37714].