Shader functions have inconsistent behaviour

The following shader will make an object red in the editor but white in the webgl player.

This is due to a mis-conversion of step(float,float4) into step(float,float) (then promoted back to float4).
This affects step() and smoothstep() for various mixed scalar/vector data types, and possibly other functions.

Observed in 5.2.4 and 5.3.3

Shader "Custom/shadyshader" {
    Properties
    {
    }

    SubShader
    {
        Pass
        {
            Tags {"LightMode"="ForwardBase"}
            CGPROGRAM

            #pragma vertex vert
            #pragma fragment frag
            #include "UnityCG.cginc"
            #include "Lighting.cginc"
            #pragma target 3.0

            struct appdata {
                float4 vertex : POSITION;
            };

            struct v2f
            {
                float4 pos : SV_POSITION;
            };

            v2f vert (appdata v)
            {
                v2f o;
                o.pos = mul(UNITY_MATRIX_MVP, v.vertex);
                return o;
            }

            fixed4 frag (v2f i) : SV_Target
            {
                float4 red_or_white = step(0.50, float4(0.90,0,0,1));
          //    red_or_white = smoothstep(0.40, 0.60, float4(0.90,0,0,1));

                return red_or_white; // red in editor, white in webgl
            }
            ENDCG
        }
    }
}

there seem to be a problem with the step function when the first parameter is a scalar (float), try a vector (float4):

fixed4 frag (v2f i) : SV_Target
{
    float4 red_or_white = step(float4(0.5,0.5,0.5,0.5), float4(0.90,0,0,1));
    return red_or_white; // red in editor, white in webgl
}

UPDATE: It turns out, this is a known bug in our hlsl2glsl conversion, which affects legacy OpenGL2, OpenGL ES 2.0 and Metal. Be also aware that it might affect other similar functions where one of the parameters is a floating scalar and is supposed to be converted to floating vector.
For the time being you can use the workaround above.