New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 289007 link

Starred by 5 users

Issue metadata

Status: WontFix
Closed: Sep 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Maps not loading initially in chrome canary.

Project Member Reported by, Sep 10 2013

Issue description

Version:31.0.1626.0 (Official Build 222150)
OS: Win , Mac & Linux

What steps will reproduce the problem?
1. Fresh Install chrome
2. Navigate -
3. Observe
4. Click reload multiple times

What is the expected output? 
Maps should load.

What do you see instead?
After 3: Not loading , and the browser renders grey screen.
After 4: It starts to load after trying reload multiple times.

Works fine till 31.0.1625.0 but broken in 31.0.1626.0 (Official Build 222150).

CL for the above range
Note : I am not able to find a narrow regression range as all the Chromium builds in above range are rendered fine.


Comment 1 by, Sep 10 2013

Status: Assigned
The Developer Tools console reports:

  INVALID_OPERATION: useProgram: program not valid 

and the app throws an exception during initialization.

Either new validation that's being done by Chrome is not correct, or shaders that the app is uploading are illegal and new, stricter validation is causing them to break. The breakage should be investigated from both aspects.

Comment 2 by, Sep 10 2013

Labels: Needs-Bisect
The same failure occurs in the continuous build 31.0.1627.0 (Developer Build 222258).

The new Maps preview must be enabled in the continuous build, which is a multi-step process and which may have confused the bisect. However, it is almost certainly possible to bisect.

Comment 3 by, Sep 10 2013

This is caused by the shaders have the same name for an uniform and a varying.  Since they share the same global namespace, that's a name conflict and illegal.  We recently add the check for this and fail program link if such conflicts are detected.

Comment 4 by, Sep 10 2013

Hm, I could have sworn our shader compiler used the same name set to track
them and thus would not do this. I will investigate our code.

Comment 5 by, Sep 10 2013

Can conflicts happen between function parameter names and uniform and/or attribute names?

Comment 6 by, Sep 10 2013

Sorry I mean attribute names and uniform names.  I'll send you guys conflicting shaders in email in case they are not public information.

Comment 7 by, Sep 10 2013

Status: WontFix
Confirmed this is due to a newly enforced restriction in chromium's webgl implementation.  Maps app should update their shaders to comply to this restriction.  No action is needed on chromium side.

Comment 8 by, Sep 11 2013

So is it the case that uniforms, attributes, varyings, and regular global variables all share the same namespace?

Comment 9 by, Sep 11 2013

I think "regular global variables" is "global" per shader, whereas uniforms, attributes, varyings namespace is "global" per program. Slight difference.

Comment 10 by, Sep 11 2013

Ah, ok.  Thanks for the clarification.

Comment 11 by, Sep 12 2013

The fix for this was checked in yesterday.  The shader compiler was doing everything right except treating 'attribute' declarations as program-global.  I guess we assumed that since those declarations only appear in vertex shaders, that they wouldn't be program-global.

Comment 12 by, Sep 12 2013

It's working for me now on my Linux with ToT chromium, where it failed two days ago.

Comment 13 by, Sep 13 2013 still fails to load for me with 31.0.1628.0 (Official Build 222659) canary on OS X 10.8.4. It still generates an INVALID_OPERATION error, and the app reports "We're sorry, but an error has occurred. Please reload the page." Was the fix already pushed out?

Comment 14 by, Sep 13 2013

Note that I completely cleared the disk cache.

I'm seeing the same thing. Works on Stable but not Canary.
doesn't work for me on 31.0.1629.0 as well 

Comment 17 Deleted

Comment 18 Deleted

Comment 19 Deleted

Comment 20 by, Sep 17 2013

 Issue 293597  has been merged into this issue.

Comment 21 by, Sep 17 2013 looks like it has the fix now.  At least it worked for me in a Chromium from today.

Sign in to add a comment