AVM2: Fix a plethora of hitTest issues

[CUB3D]

This fixes a number of issues related to hitTestObject, hitTestPoint and mouse_pick behavior.

Fixes:

• HitTests for depth=0 children, fixes bullet collisions in Upgrade Complete!, AVM2: HitTestPoint fails when child depth = 0 #8732
• Fixes for bounds calculations for AVM2 buttons, fixes upgrade and sell buttons in UGC ship builder, AVM2: HitTestObject with SimpleButton not working #8722
• MouseEnabled property shouldn't affect children, fixes HitBox: Cannot click Pause button #8694
• Selecting the child of an AVM2 button is considered a selection of the button itself, fixes BLOCnog in game menu
• hitTestPoint, when shape_flag=true, requires that the object is present on the stage. Fixes collision in Facuum
• MouseEvent.MOUSE_UP events don't fire due to AVM2 buttons not handing MouseUpInside events. Fixes Samsara Room: Unable to Enter Game. (AS3) #8278
• Don't transform coordinates if button hit_area has a parent, fixes the play button in fire boy and water girl light temple not working #8412
• Ignore mouse pick for static text. Fixes "NIGHTCORE" button in z0r-de_6516.swf (also big improvement to menus in Adventure Story )

Todos:

• Tests

[torokati44]

I was hoping that this would fix https://z0r.de/L/z0r-de_6516.swf as well.
The button on the bottom right can only be clicked next to its label.
Unfortunately I can't see any change in this with this PR... :/

[CUB3D]

I was hoping that this would fix z0r.de/L/z0r-de_6516.swf as well. The button on the bottom right can only be clicked next to its label. Unfortunately I can't see any change in this with this PR... :/

This should be fixed now

[adrian17]

How about make a custom impl Default that sets valid to true?
As an all-zero BoundingBox should be implicitly valid.

[CUB3D]

I tried doing this originally, however it causes some of our tests to fail. (Also this change isn't needed now that avm2 buttons overload bounds_with_transform)

[adrian17]

however it causes some of our tests to fail

Oh, that's even weirder I think. Recently I was thinking that valid is actually redundant and just equivalent to doing validity check manually each time.

[adrian17]

OK, I think I understand most parts of it, but the ones with SimpleButton using its child's transform sounds very weird - at least, if SimpleButton was implemented purely in AS, this couldn't have happened. It's possible that indeed FP is weird like that (not the first time), but this might also indicate that something in button's tree might be implemented wrong. Hence, pinging @kmeisthax just for a second opinion.
Same with the parent() logic.

[adrian17]

Oh, and one more thing, do you think you could write some AS-only tests for this? Maybe not the mouse pick, but the hit tests should be doable. If you need help, I can try write them for you.

[kmeisthax]

AS3 SimpleButton is such an odd collection of special cases and general weirdness that it using child transforms doesn't really seem all that bad.

Keep in mind that SimpleButton implements some of the capabilities of a DisplayObjectContainer (i.e. being able to host arbitrary children) without actually inheriting from that base class and thus not having all of its features (such as being able to display multiple children in a render list). The base implementation of bounds_with_transform already accounts for containers, but this is a non-container object host, so it needs to override that implementation.

I'm not entirely sure it's even possible to implement a "pure AS SimpleButton" - the only way to host child objects from AS3 is to be a DisplayObjectContainer, which SimpleButton is most certainly not.

We actually have test coverage for the AS3-side parent field in simplebutton_childprops and simplebutton_childshuffle. Buttons can never be in the parent field, because of typing (again, they're not containers, they just cosplay as one). However, Ruffle does set and unset the parent field on button states, since we aren't bound by those type restrictions. Specifically:

• When a state is created from a SWF tag, we always parent it to the button.
• When a state is set through AS3, we always parent it to the button.
• When the active state changes, we parent the new active state to the button and unparent everything else.

I don't quite remember the justification for that last behavior, though - it was actually written by @Herschel. I'm assuming it's to keep inactive states from seeing this.root.

[danielhjacobs]

It appears this unintentionally impacted AVM1 and caused #9274.