CT: SVG image dimensions not available on sim startup

[matthew-blackman]

This error is only happening on CT, not on our local machines.

When setting the cannon graphics, we want to scale the SVG image to fit the dimensions of the cannon. CT is running into an error caused by an image width of zero for the pattern on the launcher. @samreid and I hard-coded the image width for a temporary fix, but it would be good to figure out why this is happening and if we can fix this in a more general way.

projectile-data-lab : multitouch-fuzz : unbuilt
http://127.0.0.1/continuous-testing/ct-snapshots/1708495704095/projectile-data-lab/projectile-data-lab_en.html?continuousTest=%7B%22test%22%3A%5B%22projectile-data-lab%22%2C%22multitouch-fuzz%22%2C%22unbuilt%22%5D%2C%22snapshotName%22%3A%22snapshot-1708495704095%22%2C%22timestamp%22%3A1708506320567%7D&brand=phet&ea&fuzz&fuzzPointers=2&supportsPanAndZoom=false
Query: brand=phet&ea&fuzz&fuzzPointers=2&supportsPanAndZoom=false
Error: Assertion failed: scales should be finite
window.assertions.assertFunction<@http://127.0.0.1/continuous-testing/ct-snapshots/1708495704095/assert/js/assert.js:28:13
at window.assertions.assertFunction< (http://127.0.0.1/continuous-testing/ct-snapshots/1708495704095/assert/js/assert.js:28:13)
at assert (Node.ts:2440:16)
at scale (LauncherNode.ts:269:19)
at launcherBarrelGraphicsForType (LauncherNode.ts:191:48)
at updateMysteryLauncher (LauncherNode.ts:124:11)
at (ReadOnlyProperty.ts:430:14)
at link (LauncherNode.ts:123:20)
at (MysteryLauncherIcon.ts:19:32)
at (MysteryLauncherRadioButtonGroupWrapper.ts:31:31)
at createNode (GroupItemOptions.ts:33:16)
at map (GroupItemOptions.ts:28:15)
at items (RectangularRadioButtonGroup.ts:176:37)
at (PDLRectangularRadioButtonGroup.ts:38:4)
at (MysteryLauncherRadioButtonGroupWrapper.ts:93:44)
at (SectionMysteryLauncher.ts:25:67)
at (VariabilityLaunchPanel.ts:31:35)
at (VariabilityScreenView.ts:37:24)
at (VariabilityScreen.ts:34:15)
at createView (Screen.ts:307:22)
at initializeView (Sim.ts:874:15)
at (Sim.ts:882:25)
at (Sim.ts:880:16)
at i (Sim.ts:896:21)
at (Sim.ts:880:16)
at i (Sim.ts:896:21)
at (Sim.ts:880:16)
at i (Sim.ts:896:21)
at (Sim.ts:880:16)
at (Sim.ts:973:13)
at start (projectile-data-lab-main.ts:55:6)
at callback (simLauncher.ts:67:8)
at launchSimulation (simLauncher.ts:88:26)
at listener (asyncLoader.ts:56:42)
at forEach (asyncLoader.ts:56:21)
at proceedIfReady (asyncLoader.ts:69:11)
at image (logoOnWhite_png.ts:6:0)

[jonathanolson]

Immediate reproducible failure in Firefox. launcherPattern1 (at least) has 0 width/height in detectable patterns on startup. Data URI modulified however loads fine in Firefox.

[samreid]

With this patch, I see that Firefox reports a size of 0 in my local unbuilt. Chrome reports 300.

```diff Subject: [PATCH] Adjust bullhorn stroke, see https://github.com/phetsims/projectile-data-lab/issues/163 --- Index: js/common/view/LauncherNode.ts IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/js/common/view/LauncherNode.ts b/js/common/view/LauncherNode.ts --- a/js/common/view/LauncherNode.ts (revision 8fcf6055a0a4499a015c9b5814c2db4e7d4647ab) +++ b/js/common/view/LauncherNode.ts (date 1708536668347) @@ -267,6 +267,7 @@ // TODO: The image width is hard-coded in case the SVG dimensions are not available on startup, see https://github.com/phetsims/projectile-data-lab/issues/168 const PATTERN_IMAGE_WIDTH = 300; + console.log( patternImage.width ); const imageScale = ( BARREL_LENGTH_BEFORE_ORIGIN + BARREL_LENGTH_AFTER_ORIGIN ) / PATTERN_IMAGE_WIDTH; patternImage.scale( imageScale ); ```

Do you think there is something different in the image loading lifecycle on firefox?

[jonathanolson]

Observations:

• SVG optimizer doesn't seem to contribute (still buggy with initial path)
• Manually verified bounds of objects. DOES go slightly out of viewbox (will test path tweaks soon)
• The HTMLImageElement loaded with SVG -stays- at 0x0, it isn't an initialization thing

[samreid]

@jonathanolson determined that the "width"= and "height"= attributes solve this problem. So @matthew-blackman regenerated the images and they look good on firefox. We removed the workaround. Closing.

[jonathanolson]

Added detection for this on the above commit.