erp5_web_renderjs_ui: try to get a more precise float value on all platforms

Mathematically, 1/(x^y) is the same as x^-y, and despite float caculation the results is usually precise enough :
> Math.pow(10, -5)
0.00001
I tested this on few platforms : firefox 68.12, firefox 77.0, node v10.19.0

Unfortunately on (recent ?) chromes :
> Math.pow(10, -5)
0.000009999999999999999
Which is a horrible value to use as step (and it prevents the form submission as most floats the user will enter won't match the init value * x * the step.

For an unknown reason, I get a more consistent result using the formula "1 / Math.pow(10, 5)", which returns 0.00001 on all tested platforms.

If we find more issues in the future, we maybe should try building the step using strings. Using strings for manipulating floats is in reality widespread, and many languages do so to round floats (ie: https://github.com/python/cpython/blob/4a97b1517a6b5ff22e2984b677a680b07ff0ce11/Objects/floatobject.c#L925)

The precision of 5 is not random-picked, it is the minimum precision needed to manipulate prices for currencies with 2 digits, like euros.

bt5/erp5_web_renderjs_ui/PathTemplateItem/web_page_module/rjs_gadget_erp5_floatfield_js.js

@@ -56,7 +56,7 @@
         state_dict.append = "%";
       }
       if (!window.isNaN(state_dict.precision)) {
-        state_dict.step = Math.pow(10, -state_dict.precision);
+        state_dict.step = 1 / Math.pow(10, state_dict.precision);
         state_dict.value = state_dict.value.toFixed(state_dict.precision);
       }
       if (!window.isNaN(state_dict.value)) {

bt5/erp5_web_renderjs_ui/PathTemplateItem/web_page_module/rjs_gadget_erp5_floatfield_js.xml

@@ -220,7 +220,7 @@
                   </item>
                   <item>
                       <key> <string>actor</string> </key>
-                      <value> <string>zope</string> </value>
+                      <value> <string>nicolas</string> </value>
                   </item>
                   <item>
                       <key> <string>comment</string> </key>
@@ -234,7 +234,7 @@
                   </item>
                   <item>
                       <key> <string>serial</string> </key>
-                      <value> <string>982.42549.32458.46916</string> </value>
+                      <value> <string>983.35869.13162.60928</string> </value>
                   </item>
                   <item>
                       <key> <string>state</string> </key>
@@ -252,8 +252,8 @@
                           </tuple>
                           <state>
                             <tuple>
-                              <float>1584702324.85</float>
-                              <string>UTC</string>
+                              <float>1599097800.89</float>
+                              <string>GMT+2</string>
                             </tuple>
                           </state>
                         </object>

[Jérome Perrin]

is this a fix for https://erp5.nexedi.net/bug_module/20200708-1043D28 ?

[Jérome Perrin]

BTW I was considering removing all this client side validation. It does not bring much and cause issues when the client side validation and the server side validation are inconsistent. I don't know @romain opinion here.

[Nicolas Wavrant]

Yes ! This is exactly the issue I encountered. Should I resolve the bug, and link to this commit ?

[Jérome Perrin]

:)

[Nicolas Wavrant]

Just for the reference, as I know that you know, here the step has a more interesting use than validation : it allows the user to click arrows on the field to increment or decrement the value.

About validation, I personnaly like it, as in html5 the validation feature is very powerful (we can set regexps for text input for exemple). If the step attribute causes issues here, we can configure the field in formulator to use "any".

[Nicolas Wavrant]

I can't test this, as this is a chrome-only bug, and we don't run tests on this platform.

[Jérome Perrin]

To be clear, I'm not talking about disabling all client side validation, only this one for the float precision.

Just for the reference, as I know that you know, here the step has a more interesting use than validation : it allows the user to click arrows on the field to increment or decrement the value.

Maybe we can use only step but not validation ?

[Romain Courteaud]

I can't test this, as this is a chrome-only bug, and we don't run tests on this platform.

I run tests on chrome from my machine. We also run tests on IOS + other browsers via Selenium.

Please add a test.

[Jérome Perrin]

For the records this also happens with node, which is normal in my understanding because it uses same javascript engine as chrome.

$ nvm use lts/dubnium
Now using node v10.22.0 (npm v6.14.6)
$ node -e 'console.log(1/10**5 == 10**-5)'
true
$ nvm use lts/erbium
Now using node v12.18.3 (npm v6.14.6)
$ node -e 'console.log(1/10**5 == 10**-5)'
false

[Nicolas Wavrant]

Digging a bit more, I found toPrecsion . For exemple, in chrome :

$ Math.pow(10, -5).toPrecision(5)
"0.000010000"

It's interesting to note that it returns a string. I also suspect this method to be more multi-platform compatible.

[Nicolas Wavrant]

Also :

$ Math.pow(10, -5).toFixed(5)
"0.00001"

[Romain Courteaud]

https://stackoverflow.com/questions/11832914/round-to-at-most-2-decimal-places-only-if-necessary/11832950#11832950

[Nicolas Wavrant]

pfffffffffff. So no good solution. Bad to hear that the special methods for this don't work, but glad to hear that my solution is the recommended one and upped to +3651 on stackoverflow. At least I won't fixup this patch.

Test is coming.

[Jérome Perrin]

Also, there's a plan to run ERP5 tests with SlapOS's seleniumserver - then we could run test on chrome or firefox. This still needs some work, but one day we'll have our tests running on chrome and firefox (hopefully)