Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: graphical renderers don't consistently protect against non-numerical values #2361

Open
dqnykamp opened this issue Oct 5, 2023 · 1 comment

Comments

@dqnykamp
Copy link
Member

dqnykamp commented Oct 5, 2023

In DoenetML, <number>s can be either floating point numbers or complex numbers represented by the object created by math.js. However, jsxgraph constructions expect floating point numbers for coordinates. Hence either the renderers or the component itself need to protect against the possibility of a coordinate being a complex number, for example by changing the complex number object into NaN.

This protection has been done in many places, but it is not universal, leading to Javascript crashes with errors such as "TypeError: Cannot convert object to primitive value". To increase the robustness of the code, we need to find cases where this error happens, add the protect, and add regression tests.

One example is in the point renderer where the state variable numericalXs can have complex numbers, and those values are passed directly into a setCoordinates command of a point (often using the intermediate variable lastPositionFromCore). We should either make the renderer more robust or change the numericalXs state variable to always convert to floating point numbers.

@dqnykamp
Copy link
Member Author

dqnykamp commented Oct 5, 2023

Fixed the point numericalXs with #2362. However, we need a better test as the cypress test designed to test for regressions does not fail even if I remove the patch. (There is a Javascript error, but Doenet recovers and cypress doesn't catch that there was a Javascript error.)

We should also check to see if other components need the same protection as I did for point in #2362.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant