Currently it is not directly possible to configure lints for the
entire workspace via TOML, which forced us to repeat `#![allow]`
blocks in each crate.
embark pointed out this workaround to configure lints at the
workspace level via RUSTFLAGS:
https://github.com/EmbarkStudios/rust-ecosystem/issues/22#issuecomment-947011395
Remove the common `#![allow]` blocks and switch to this method for
global lint config.
Temporarily allow `needless_borrow` lint, buggy pending this fix:
https://github.com/rust-lang/rust-clippy/pull/8355
When the user clicks the "Open in a new tab" button, the extension's internal `player.html` page opens, with a URL parameter `?url=[the SWF URL]`. Right now, this URL parameter is not properly encoded. This causes a problem when we get to https://github.com/ruffle-rs/ruffle/blob/master/web/packages/extension/src/player.ts#L14:
> `const swfUrl = url.searchParams.get("url");`
Because the value "url" parameter was not properly encoded, any `&` character in the SWF URL would be interpreted as the start of a *new* parameter, instead of being part of the actual SWF URL. So anything after the first `&` symbol in the SWF URL would be chopped off.
On Itch.io Flash pages such as https://rarykos.itch.io/hug-me-im-cold, the SWF URL contains several important parameters - if they are not included, the server returns 403 Forbidden (it's a type of hotlinking protection). So when the user clicked the "Open in a new tab" button on Itch.io pages, the SWF would refuse to load in the player.
This PR fixes the problem - Itch.io SWFs load when opened in a new tab after my change is applied.
Move the `if` condition that tests for the Ruffle official repository
to the job-level, so all steps of that job are skipped, rather than
only the publish step itself. This should have a very little effect,
but I just randomly noticed it.
Previously we called `toString` when concatenating a string to an
Object. However, Flash actually has more complex behavior, usually
calling both `valueOf` and `toString`. This is loosely based on
ToPrimitive/DefaultValue with no type hint in the ECMAScript spec.
* Call `valueOf`.
* If the result isn't a primitive, call `toString`.
* If the result still isn't primitive, return `"[type Object]"`.
* For Date objects in SWFv6 and higher, call `toString`.
* If the result isn't a primitive, call `toString` (AVM1 bug?)
* If it still isn't primitive, return `"[type Object]"`.
A regression in naga caused a mistranslation of the gradient shader
on the vulkan backend. This caused radial gradients to be rendered
as linear gradients on the vulkan backend. dx12 seems unaffected.
This seems to be cased by a switch statement starting with a default
case Re-order the case statements to avoid this. Looks like it's been
fixed in naga master.
This also rearranges some things about how we construct events, because `MouseEvent` has different defaults from `Event`. When we finally support parameter metadata on methods we should remove that code.
We also remove the `value_of` code on `EventObject` as that was a mistake. Events don't do anything special in there and I misinterpreted the test results the first time around.
This requires adding another notion of mouse-release events to `ClipEvent`. We now have four:
* `MouseUp` - the mouse was released, any object on the render list can handle this event ("anycast" event)
* `MouseUpInside` - the mouse was released inside this display object, only the mouse-picked target of the event can handle it
* `Release` - the mouse was released inside the last clicked display object
* `ReleaseOutside` - the mouse was released outside the last clicked display object
For those keeping score at home, in AVM2, the valid progression of events is either...
* On the same object, `mouseDown`, `mouseUp`, and `click`
* On one object, `mouseDown`, then some mouse movement that takes the cursor out of the first object, then on another object `mouseUp`, and then finally the first object gets `releaseOutside`.
`MouseDown`/`MouseUp` are effectively broadcasts; they hit every movie clip that can accept them until one of them has a handler for it. AVM2 instead wants events that only apply to specific mouse-picked display objects, which means we need to use the Player-tracked events `Press`, `Release`, and `ReleaseOutside`. The only problem is that we also need to emit a `mouseUp` event on both `Release` and `ReleaseOutside`.
Mike Welsh