[DRAFT] AVM2: Fixes for SimpleButton
#7015
Conversation
…heir constructors.
…ssible places: 1. If the button was placed at the start of the parent clip's timeline, immediately after all children run their frames. 2. Otherwise, during the next frame *destruction* event (after `exitFrame`, *not* before `frameConstructed`).
…utton construction and other factors.
…tons that are missing various states
… if it was placed on frame 1 and has at least one `Up` child.
…ation if there's an up state. We are also hacking around the delay code again. I spent like a whole day trying to figure out how Flash Player determines if `SimpleButton` gets constructed early or late and nothing made sense.
…remaining event ordering issues.
… in line with frame advance.
|
Is this PR still relevant after #7570 ? |
|
I forgot about this PR, and started working on something similar on my own branch (adding a new test as well): https://github.com/Aaron1011/ruffle/tree/button-constr-order I think I found the cause of a lot of the weirdness - all of the non-active button states should be treated as orphans, and have their frames/framescripts run by the orphan-handling code. This explains why the relative order of button state framescripts is sometimes different - the relative order of orphan framescripts seems to depend on some internal hash table iteration in Flash Player. |
|
In that case if @Aaron1011 's PR goes through this probably should be abandoned. Most of this PR was based off the old version of the frame ordering PR that was then rewritten a few times anyway. Does the orphan logic intersect with #10862 in any way? |
This consists of all the
SimpleButton-specific things that I'm about to pull out of #5876.Note that as a result of factoring out the
SimpleButtonstuff, I had to ignore one of theSimpleButtontests in that PR, because the fix for that is now exclusively in this one.This has a lot of guess-work about exactly when buttons run script initializers, and I still haven't figured out how it is supposed to work.