This PR implements the `Loader.load` method, as well as
the associated `LoaderInfo` properties and events.
We can now load in an external AVM2 SWf: it will be added
as a child of `Loader` object, and will render properly
to the screen.
Limitations:
* The only supported `URLRequest` property is `url`
* `LoaderContext` is not supported at all - we always use the default
behavior
* Only `Loader.load` is implemented - we do not yet support unloading.
* We fire a plain 'Event' for the 'progress' event, instead of using
the (not yet implemented) 'ProgressEvent' class
The main changes in this PR are:
* The AVM2 `Loader` class now has an associated display object,
`LoaderDisplay`. This is basically a stub, and just renders
its single child (if it exists).
* `LoaderStream::Stage` is renamed to `LoaderStream::NotYetLoaded`.
This is used for both the `Stage` and an 'uninitialized'
`Loader.contentLoaderInfo`. In both cases, certain properties throw
errors, while others return actual values.
* The rust `Loader` manager now handles both AVM1 and AVM2 movie loads.
Previously, we would create a fresh `LoaderInfo` object each
time the `loaderInfo` property was accessed. However, users can
add event handlers to a `LoaderInfo`, so we need to create and
store exactly one `LoaderInfo` object per movie (and stage).
To verify that we're correctly handling the storage of `LoaderInfo`,
I've implemented firing the "init" event. This required a new
`on_frame_exit` hook, so that we can properly fire the "init"
event after the "exitFrame" for the initial frame but before
the "enterFrame" of the next frame.
This PR implements the `URLLoader` class, allowing AVM2 scripts
to load data from a URL. This requires several other related
classes (`URLLoaderDataFormat`, `URLRequest`, `IOError`) to be
implemented as well.
Currently implemented:
* Fetching from URLs using the 'navigator' backend
* The `text` and `binary` data formats (which store data
in a `String` or `ByteArray` respectively)
* The `open`, `complete`, and `ioError` events
* The `bytesLoaded`, `bytesTotal`, and `data` properties
Not yet implemented:
* The HTTP and security events
* All of the properties of `IOError`
* The properties on `URLRequest` (besides `url`)
* The "variables" data format
This should be enough to get some basic uses of `URLLoader` working
(e.g. simple GET requests to a particular website).
Note that in Flash's `playerglobal`, the `URLLoader` class is just
a think wrapper around the more general `URLStream`. However,
implementing `URLStream` will require changes to `Navigator``
to support notifications when data arrives in the stream. When
that happens, we should be able to re-use a large amount of the
code in this PR.
Internal function calls such as `toString` and event handlers
always used the base clip from the function itself, so add an
`ExecutionReason::InternalCall` to signify this and pass it along
to `call_method`.
Remove the `swf_version` parameter from `Activation` constructors,
because this was incorrectly using the global or root SWF version
most times.
Instead, grab the SWF version for the activation directly from the
base clip.
The resolved URL only used by `NavigatorBackend::fetch`. So simply
inline `NavigatorBackend::resolve_relative_url` into `NavigatorBackend::fetch`,
per implementation.
Remove the preload step that would pre-create the shapes for each
morph shape ratio on SWF load. Instead, lazily crate the shapes
when they are needed.
Loading unknown data is not considered an error on Flash; Both
`onLoadProgress` and `onLoadComplete` events are dispatched. But,
`onLoadProgress` reports 0 bytes loaded.
These are *not* methods, because we cannot borrow both the update context and the loader at the same time. At least not without making loaders free-standing objects (`GcCell`s), which I don't want to do yet.
This also slightly changes behavior: Previously `SwfMovie::from_data`
errors were propagated as `FetchError` and `display_root_movie_download_failed_message`
was called, offering the user to sidestep CORS by opening the SWF
in a new tab. But that wouldn't help, obviously, because no network
error is involved. Now, these errors are propagated as `InvalidSwf`,
and `display_root_movie_download_failed_message` is not called.
Handle strings, numbers and DisplayObject targets (not just MovieClips).
To support non-MovieClip targets, turn `clip.as_movie_clip().unwrap()`
to `if let Some(mc) = clip.as_movie_clip()` in `Loader`.
`onLoadInit` is queued after all `DoAction`s of the loaded clips.
That is, if clip1, clip2, clip3 are loaded in the same frame
(in this order), then actions will be executed as follows:
* `DoAction` of clip3
* `DoAction` of clip2
* `DoAction` of clip1
* `onLoadInit` of clip3
* `onLoadInit` of clip2
* `onLoadInit` of clip1
Previously, those were incorrectly executed as follows:
* `DoAction` of clip3
* `onLoadInit` of clip3
* `DoAction` of clip2
* `onLoadInit` of clip2
* `DoAction` of clip1
* `onLoadInit` of clip1
The first argument of all events is the target MovieClip. It was
incorrect.
Also, `onLoadComplete` accepts an additional `httpStatus` argument.
Stub it to 0.
Remove unnecessary calls to `introduce_loader_handle`, which are
dominated by `add_loader` that already calls it. As a result, `add_loader`
remained the only function to call `introduce_loader_handle`, so inline
it there.
Since they are identical (they both load the URL as a string, then
fire the `onHTTPStatus` and `onData` events). In fact, AVM1's
`XML.prototype.load` and `LoadVars.prototype.load` functions are
both defined as `ASnative(301, 0)`, so they invoke the same native
code under the hood.
This also incurred a large number of ancillary changes, as it turns out nearly every native object is currently pulling a prototype and sticking it into an object. Right now, I have it instead pulling the constructor out of the prototype, but a future PR will also remove `system_prototypes` as well.
Other ancillary changes include:
* `Domain` now supports partial initialization to avoid an order-of-events issue. Accessing domain memory on a partially-initialized `Domain` will panic.
* `Domain` construction requires a full `activation` now, except for `global_scope` which needs to be initialized later with valid domain memory before user code runs.
* Pretty much every native object constructor now takes a proto/constr pair
* Trait lookup was rewritten to handle this. It's still buggy - seven tests don't work
* `TObject.construct` now actually does the full object construction dance. This allows `ClassObject` to implement the ES4 object construction pathway directly while `FunctionObject` maintains ES3 compatibility.
This is a tentative commit; there are still seven failing tests that I need to fix.
When reading an SWF, search for FileAttributes and
SetBackgroundColor and return this along with the header data
because it's useful (in particular, the AS3 flag).
Move `MovieClip::is_swf` flag to `DisplayObject::is_root`, and use
this flag to handle the behavior of `DisplayObject.root` crawling
upwards until it hits a top-most loaded SWF/Bitmap.
Simplify `root` and `stage` so that they don't have to consider
buttons. Instead, do some trickery to ensure the button's states
see the proper values of `parent`, `root`, and `stage` during
construction.