Papers can have a position that is NaN and therefore cannot be moved

[phet-steele]

The particular case where I've seen this is on the second screen, but it may be possible on other screens depending on how this issue is caused. It's hard to tell in this video since it does not show the location of my mouse, but the beginning has me unsuccessfully trying to move both paper pieces around. When trying to tear pieces off, they jump to the top left of the screen and cannot be moved.

So far, this issue has been incredibly elusive and unreproducible (hence no steps to reproduce). The QA team has probably spent a combined 8 hours on this bug. Because of this, it should not block publication and will be marked as deferred until reproduction occurs. There are no associated errors in the console; this issue was seen in an rc version (with no assertions) and has not been reproduced in an un-built environment. @jonathanolson could only confirm with dev tools that all paper positions were NaN.

Clues and probable causes we have so far:

• Seen on Firefox 51.0.1 (probably not exclusive)
• Seen on macOS 10.12.3 (probably not exclusive)
• Occurred after returning to FF after some time. The browser was in the background with the sim running for 5(?) minutes.
• Every other screen/button was fine. Even the edit and reset all buttons on the second screen still worked fine. Paper was easily draggable on the 1st and 3rd screens.
• Papers were in the default "submitted" position (seen in the above video).
• I do remember taking a screenshot of the second screen via the PhET Menu. I don't know how this would be related though.

---

• Did I somehow submit 4 numbers to the keypad?
• Did FF at some point have an invalid screen size (like a screen size of 0)?
  - Did my graphics card reset at some point?
  - How does FF behave when it is in the background for extended periods of time?
  - Did FF resize at an..."inopportune" time? (I don't remember manually resizing the window)
• @jonathanolson anything else I forgot or you want to add?

This occurred in http://www.colorado.edu/physics/phet/dev/html/make-a-ten/1.0.0-rc.2/make-a-ten_en.html. Testing done for phetsims/tasks/issues/788.

Version: 1.0.0-rc.2 2017-02-21 21:14:03 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Language: en-US
Window: 1920x1001
Pixel Ratio: 2/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 32 uniform: 1024
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 80)
Max viewport: 16384x16384
OES_texture_float: true
Dependencies JSON: {"assert":{"sha":"a707328c","branch":"HEAD"},"axon":{"sha":"1cf10281","branch":"HEAD"},"babel":{"sha":"13588121","branch":"master"},"brand":{"sha":"0be722ee","branch":"HEAD"},"chipper":{"sha":"f4cd39bf","branch":"HEAD"},"dot":{"sha":"75380061","branch":"HEAD"},"joist":{"sha":"d0bca742","branch":"HEAD"},"kite":{"sha":"6059ebb0","branch":"HEAD"},"make-a-ten":{"sha":"107f2912","branch":"HEAD"},"phet-core":{"sha":"84747dff","branch":"HEAD"},"phetcommon":{"sha":"1cb33196","branch":"HEAD"},"query-string-machine":{"sha":"d8a4ff18","branch":"HEAD"},"scenery":{"sha":"fbf816a5","branch":"HEAD"},"scenery-phet":{"sha":"b04d8086","branch":"HEAD"},"sherpa":{"sha":"785a536c","branch":"HEAD"},"sun":{"sha":"c98a7f0b","branch":"HEAD"},"tandem":{"sha":"d9c124e5","branch":"HEAD"},"twixt":{"sha":"cbe4c1aa","branch":"HEAD"},"vegas":{"sha":"8aa08377","branch":"HEAD"},"vibe":{"sha":"d4b79cf6","branch":"HEAD"}}

[jonathanolson]

All paper number positions and destinations were NaN on that screen.

Most likely cause is if a zero-width/height window size was sent and the "bounds constraint" application NaN'ed the destinations. Possibly other causes, but the "bounds constraint" is the most likely.

To debug this, I would need a reproduction (ideally with the dev tools open) that identifies when the NaN appeared. Assertions are all over the place to detect this type of behavior, so running in require.js should be done if there are further attempts.

I appreciate the efforts to reproduce!

[phet-steele]

Error reproduced in master, no procedure yet:

Error: Assertion failed: Should be a finite Vector2  assert.js:21:13
	window.assertions.assertFunction< http://phettest.colorado.edu/assert/js/assert.js:21:13
	.setTranslation http://phettest.colorado.edu/scenery/js/nodes/Node.js:2034:19
	set translation http://phettest.colorado.edu/scenery/js/nodes/Node.js:2043:32
	PaperNumberNode/this.translationListener http://phettest.colorado.edu/make-a-ten/js/make-a-ten/common/view/PaperNumberNode.js:139:7
	.emit2 http://phettest.colorado.edu/axon/js/Emitter.js:147:9
	._notifyObservers http://phettest.colorado.edu/axon/js/Property.js:176:9
	._setAndNotifyObservers http://phettest.colorado.edu/axon/js/Property.js:165:9
	.set http://phettest.colorado.edu/axon/js/Property.js:133:11
	set value http://phettest.colorado.edu/axon/js/Property.js:205:31
	.step http://phettest.colorado.edu/make-a-ten/js/make-a-ten/common/model/PaperNumber.js:85:41
	.step http://phettest.colorado.edu/make-a-ten/js/make-a-ten/common/model/MakeATenCommonModel.js:41:9
	.stepSimulation http://phettest.colorado.edu/joist/js/Sim.js:762:13
	.runAnimationLoop http://phettest.colorado.edu/joist/js/Sim.js:696:7

[phet-steele]

@jonathanolson and I figured it out, it's a joist issue. The sim was given a negative dt (somehow?). This, as you can imagine, broke a lot of things. FF, for some reason, had in my case a dt of -0.868, so less than a second. You can manually reproduce by setting your system clock back in time. Doing this manual reproduction does make the problem replicable across browsers, not just FF.

@jonathanolson made a joist issue: phetsims/joist/issues/409

Keeping this issue open as a reminder that this sim is adversely affected. Other sims should be tested to see how prevalent this issue is.

[jonathanolson]

Fix applied in master and in the maintenance-release branch (joist's make-a-ten-1.0 branch).

@ariel-phet, once #275 is confirmed fixed also, should I create 1.0.1-rc.1 for testing both (moving towards 1.0.1 maintenance release)?

[jonathanolson]

Note to self: phetsims/tasks#791 is a similar RC testing task.

[ariel-phet]

@jonathanolson yes, would be good to test.

[jonathanolson]

Ok, I'll make an RC and make a similar testing task when #275 is confirmed to be as desired.

[jonathanolson]

RC issue at phetsims/tasks#796 for 1.0.1-rc.1.

[phet-steele]

@jonathanolson looks good on macOS 10.12.3 & Win 10 Chrome. The overnight test in FF also had no problems.