Saving workflow fails when using decimal comma (,) about orchardcore HOT 7 CLOSED

Where exactly do you provide this number as the input?

I suppose it's a culture thing, and the culture of the app is one that uses a different decimal separator.

from orchardcore.

Yes this is because of culture setting. I'm using Swedish regional settings where we have the decimal point as comma (,).

The value comes from the internal representation after adding or moving a task or event. I looked a little bit at the javascript to see if it could be changed to always treat it as int, but didn't find the source. But I think it's correct to use a decimal point as the storage format. The comma is only used for presentation.

from orchardcore.

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

from orchardcore.

Got it, thanks!

from orchardcore.

I encountered the same issue a couple weeks back, but the repro was quite exotic, so I didn't report it. The interesting thing about this feature is that the editor uses a 10 by 10 pixel grid to snap elements into such positions that the coordinates are always divisible by 10, thus they will always be integers.

The only way I could break this and produce the same error is by having the fingerprinting-client-rects-noise flag in Ungoogled Chromium enabled (chrome://flags/#fingerprinting-client-rects-noise), which does the following:

Scale the output values of Range::getClientRects() and Element::getBoundingClientRect() with a randomly selected factor in the range -0.0003% to 0.0003%, which are recomputed on every document initialization. ungoogled-chromium flag, Bromite feature.

That's one part of the error regarding integer conversion, but culture settings also play a role (decimal point vs. comma).

@microposmp are you using this flag?

from orchardcore.

No, I've not set any flags explicitly. Running the latest version of Edge and can reproduce the issue 100% of the time when moving an element in the workflow editor. I think that the fractional numbers can be caused by my scale settings. Using 250% scale setting in Windows. 100% scale in the browser.

from orchardcore.

I didn't think about Windows scaling, although I would expect it to produce different numbers. The number shown in your screenshot is very similar (in terms of inaccuracy) to those I saw in my testing. Maybe Edge has fingerprinting deception features enabled by default, in which case this is less exotic than I thought. :)

from orchardcore.