So, continuing the test, quite a few test are failing under this directory:
https://www.khronos.org/registry/webgl/sdk/tests/deqp/data/

I can't reproduce this failure on a Retina MBP (NVIDIA GPU) on Mac OS X with 51.0.2688.0 (Official Build) canary (64-bit). https://www.khronos.org/registry/webgl/sdk/tests/conformance/glsl/misc/global-variable-init.html is also passing here.

Possibly due to stricter enforcement of the GLSL ES spec in recent Chrome OS graphics drivers? Stephane, can you help confirm?

I can definitely reproduce the issue on pixel 1 (which is a gen7 GPU like swanky). I'll take a look at the specifics.

There is a shader in v3.polarr.co which isn't GLSL 3.0-compliant:

uniform highp mat3 webgl_3b2d29a79fdd759;
uniform highp mat4 webgl_68f98e133992702;
uniform highp mat4 webgl_45bed897a94f114b;
uniform highp mat4 webgl_a9b0b00e18338362;
uniform highp mat4 webgl_d12cde9aef2de2aa;
uniform highp mat4 webgl_8a9499bc2f061d6f;
uniform highp mat4 webgl_b1af74958616260e;
varying highp vec4 webgl_6e7401d51b4bde27;
uniform lowp sampler2D webgl_7b2a3abeb835f4b0;
uniform highp vec2 webgl_583a9938eb4b5ad5;
highp vec2 webgl_c6341531287f7986 = (1.0 / (webgl_583a9938eb4b5ad5 / 2.0));
highp float webgl_ef065a426845c30b = 0.029999999;
highp float webgl_6ab1329514a0ffbb(in highp vec3 webgl_fdf716b85bed8f4d, in highp float webgl_418dfd92d46d2d70){
  return fract(((sin(dot((gl_FragCoord.xyz + webgl_418dfd92d46d2d70), webgl_fdf716b85bed8f4d)) * 43758.547) + webgl_418dfd92d46d2d70));
}
highp float webgl_2a40d9ff5de77aea(in highp vec3 webgl_95a61de88fbe7420){
  return (((0.29899999 * webgl_95a61de88fbe7420.x) + (0.58700001 * webgl_95a61de88fbe7420.y)) + (0.114 * webgl_95a61de88fbe7420.z));
}
void main(){
  highp float webgl_7e4bbdc60f955abb = 9.0;
  highp float webgl_fe782ebee3db7792 = 0.0;
  highp vec3 webgl_950dae34b39eacf9 = vec3(0.0, 0.0, 0.0);
  highp vec3 webgl_7d944f9a37f561ae = texture2D(webgl_7b2a3abeb835f4b0, webgl_6e7401d51b4bde27.xy).xyz;
  highp float webgl_d1643eec4757d6a8 = ((((0.5 * webgl_7e4bbdc60f955abb) * webgl_7e4bbdc60f955abb) * webgl_c6341531287f7986.x) * webgl_c6341531287f7986.y);
  highp vec2 webgl_fe615915f60fa25c = vec2(0.89999998, -1.0);
  highp float webgl_6e28d2ef381e2489 = webgl_6ab1329514a0ffbb(vec3(12.9898, 78.233002, 151.7182), 0.0);
  highp float webgl_e26f2de81508f315 = webgl_6ab1329514a0ffbb(vec3(112.9898, 178.233, 51.718201), 0.0);
  for (highp float webgl_6fdd29f02130ae3a = -4.0; (webgl_6fdd29f02130ae3a <= 4.0); (webgl_6fdd29f02130ae3a++))
  {
    highp vec2 webgl_3b694304131c2486 = (webgl_6e7401d51b4bde27.xy + (vec2(((webgl_6fdd29f02130ae3a + webgl_6e28d2ef381e2489) - 0.5), (webgl_e26f2de81508f315 - 0.5)) * webgl_c6341531287f7986));
    highp vec3 webgl_f88f5d79c2ad2913 = texture2D(webgl_7b2a3abeb835f4b0, webgl_3b694304131c2486).xyz;
    highp float webgl_ca4676b82002f7c1 = (webgl_2a40d9ff5de77aea(webgl_f88f5d79c2ad2913) - webgl_2a40d9ff5de77aea(webgl_7d944f9a37f561ae));
    highp float webgl_1334bcd279dcd3d0 = exp(((-(webgl_6fdd29f02130ae3a * webgl_6fdd29f02130ae3a)) * webgl_d1643eec4757d6a8));
    (webgl_1334bcd279dcd3d0 *= exp((-min(((((webgl_ca4676b82002f7c1 * webgl_ca4676b82002f7c1) / 2.0) / webgl_ef065a426845c30b) / webgl_ef065a426845c30b), 10.0))));
    (webgl_950dae34b39eacf9 += (webgl_f88f5d79c2ad2913 * webgl_1334bcd279dcd3d0));
    (webgl_fe782ebee3db7792 += webgl_1334bcd279dcd3d0);
  }
  (gl_FragColor = vec4((webgl_950dae34b39eacf9 / webgl_fe782ebee3db7792), (webgl_fe782ebee3db7792 / 10.0)));
}

As you can see, webgl_c6341531287f7986 is not constant (it depends on webgl_583a9938eb4b5ad5 which is a uniform). However, the GLSL 3.0 specification requires initializers for globals to be constants:

«Initializers may only be used in declarations of globals with no storage qualifier or with a const qualifier. Such initializers must be a constant expression. »

So, it's an application bug.

WebGL 1.0 does make a change to the GLSL ES 1.00 spec to allow uniforms in global variable initializers:

https://www.khronos.org/registry/webgl/specs/latest/1.0/#6.30

This change was made to WebGL to preserve backwards compatibility, since ANGLE nor common drivers didn't validate global variable initializers properly. It may be that the driver in the OS has been updated to follow the spec more strictly, and now requires some shader mangling to implement the WebGL spec.

I should fix this in ANGLE's shader translator, so assigning to myself.

 Issue 596749  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/3d932d839a93bc81a3ed7a971946164298ce2dd0

commit 3d932d839a93bc81a3ed7a971946164298ce2dd0
Author: Olli Etuaho <oetuaho@nvidia.com>
Date: Tue Apr 12 08:10:30 2016

Defer global initializers when necessary

Move global variable initializers that are not constant expressions to
a function that gets called at the start of main(). This is done
with an AST transformation. This needs to be done because global
variable initializers must be constant in native GL, but ANGLE is more
lenient with what can be put into ESSL 1.00 global initializers to
remain compatible with legacy WebGL content.

Non-constant global variable initializers also caused issues in HLSL
output, since in HLSL output some types of expressions get unfolded
into multiple statements. These include short-circuiting operators and
array initialization. To make sure that these cases are covered, any
initializers that can't be constant folded are deferred, even if they
have the const qualifier.

The old deferring mechanism in OutputHLSL is removed in favor of this
new AST transformation based approach.

BUG= angleproject:819 
BUG= angleproject:1205 
BUG= angleproject:1350 
BUG= 596616 
TEST=WebGL conformance test
     conformance/glsl/misc/global-variable-init.html

Change-Id: I039cc05d6b8c284baeefbdf7f10062cae4bc5716
Reviewed-on: https://chromium-review.googlesource.com/338291
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>

[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/libANGLE/renderer/d3d/DynamicHLSL.cpp
[add] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/compiler/translator/DeferGlobalInitializers.cpp
[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/compiler/translator/OutputHLSL.h
[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/compiler/translator/Compiler.cpp
[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/libANGLE/renderer/d3d/ShaderD3D.h
[add] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/compiler/translator/DeferGlobalInitializers.h
[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/compiler.gypi
[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/compiler/translator/OutputHLSL.cpp
[modify] https://crrev.com/3d932d839a93bc81a3ed7a971946164298ce2dd0/src/libANGLE/renderer/d3d/ShaderD3D.cpp

The next ANGLE roll that picks up the patch above should fix this issue, I don't have the specific hardware to verify it though.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7b7a9718959cabe5151e5ea010c35c276744ea1f

commit 7b7a9718959cabe5151e5ea010c35c276744ea1f
Author: geofflang <geofflang@chromium.org>
Date: Thu Apr 14 22:38:54 2016

Roll ANGLE 81efa8e..6684007

https://chromium.googlesource.com/angle/angle.git/+log/81efa8e..6684007

BUG= 596616 

TBR=cwallez@chromium.org

TEST=bots

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.linux:linux_optional_gpu_tests_rel

Review URL: https://codereview.chromium.org/1888713003

Cr-Commit-Position: refs/heads/master@{#387460}

[modify] https://crrev.com/7b7a9718959cabe5151e5ea010c35c276744ea1f/DEPS

Thanks Olli for fixing this!

(Needs verification by the customer.)

Bulk verified