Prior to this change, there were two versions of the code meant to load
extensions from URL query parameters:
- One version reliably waited for the editor to be ready, but looked for
"ext=" and "proj=" query parameters. This was an old version of the
JS-Flash interface that was never documented; the docs say to use
"url=" for both projects and extensions.
- The other version correctly looked for "url=" but did not reliably
wait for the editor to be ready. This seems to be the most likely
culprit for reports that extensions sometimes fail to load.
This change unifies those two paths into one which looks for "url=" and
waits for the editor to be ready.
Port LLK/scratchr2#4168 for ScratchX.
Original description from that change:
> This fixes#4112 by creating the swf regardless of OS and browser.
> Calling `embedSWF` would first check for the existence of the plugin
> before creating, causing browsers that don’t allow the flash plugin by
> default to not be able to show their “allow” message. This tries to
> create the swf no matter what, allowing browsers to detect flash
> themselves.
>
> Logic is as follows:
> 1. check if `userAgent` returns a mobile/tablet OS. Display error
> message if so
> 2. check if on windows and using ie – check for an express install if
> so (like in `embedSWF`)
> 3. load the swf in all other cases, let browsers handle it.
>
> Test Cases:
> - Test how project pages load in Android and iOS devices, on tablets
> and on phones, and on multiple desktop OS's for correct loading
> behavior.
This resolvesLLK/scratchx#103
Fixes#11, and some unfiled issues:
Loading extensions from the home page now pop up the warning modal
Clicking the "back to home" button from the warning modal returns you to home.
Each time a modal is created, the number of event handlers no longer doubles :|
