LATENT VALUES IN SETTERS UPON REMOVE / RESET - VALUES ARE NOT CLEARED This may be epically-destructive to undo? Semi non-destructive elsewhere?
Could this semi-benign latent value bug described below be the primary culprit for randomness people are experiencing in the undo. Those variable values persist in most cases and can be invoked / acted upon. They are definitely not clearing unless a user behavior triggers them to. If that is the case that they persist, how can they not adversely affect and trash the undo sequence leaving a trail of hiccups here and there?
DESCRIPTION:
This bug appears any time a user elects to remove a style property associated with a class.
press the button toRemove this style
the result generates a latent value (the value captured is expressed as the runtime pixel equivalent, not the value type of the original, unless the runtime attribute in css is in px or hex for color, etc)
This latent value bug converts or captures numeric values to a runtime value type and leaves that conversion in the numeric field within the setter. So, the latent value translates/converts the value of VW, VH, EM, REM, and % to pixels rather than just displaying the default or the inherited value type that should be displayed upon removal (very confusing). The latency is benign if you select some other object as doing so will clear the field (no idea if this actually clears the var or if it persists). It appears that it gets flushed upon deselecting/selecting new object purging the latent value.
If you attempt to drag, nudge or keyboard nudge any of the setter values that still display the latent ghost pixel value, the value iterates from that latent runtime value rather than the null, reset default or inherited value that should be the basis.
RUNNING LIST OF AFFECTED PROPERTIES: I will update / add to this list as I encounter the issues and add screencaps
Sorry if that is crazy obsessive. (emphasis on crazy) One of the apps I work with requires ridiculous documentation of what you observe and is heavy on steps and context - habit.
Some of this almost feels purposeful or intentional, like the color value. The last color used is helpful / useful and feels intuitive.
When I style navbar’s preset elements (e.g. navlinks), their preset settings are not shown correctly - e.g. navlinks have some preset paddings, but when I add a class to a navlink, I see default padding values of zero.
Hi @uzzer, thanks for the info, this does not look browser related, I have been able to reproduce this and I have filed a bug about this. As soon as there is an update, I will notify here on the post.
Hey @Revolution thank you so much for pointing this out, I am looking into this right now and will let you know right away as soon as I have more information.
Hey @Revolution do you have a site where the form wrapper margin reverts back to 15px after you’ve made the change and the site has saved? I was unable to reproduce this issue on my end.
Once I made the change, I made sure that the site had saved, then exited the designer and came back and the margin was still at 0px. Are you seeing different behavior on your side?
Hey @Revolution I see what you’re referring to now, thank you very much for sharing the screen share. Once you click to remove the styles on the margin setting after it was set to 0px, then it says 0px even though it should be changed back to 15px as that was the original default style.
Thank you very much, I will let you know as soon as I have an update on this issue! Cheers!