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

Issue 71624 link

Starred by 13 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Mar 2011
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment

"experimental-webgl" breaks page on chrome 10

Reported by, Feb 2 2011

Issue description

Chrome Version       : 10.0.648.11
Other browsers tested: chrome 8,9 (they work)

What steps will reproduce the problem?
1. run the index.html

What happens is the getContext("experimental-webgl") tag breaks the page (you can't select the input box and enter data). When you use getContext("webgl") it works fine. 

Of course this shouldn't work, but it shouldn't break the page either.

Example source attached
663 bytes View Download

Comment 1 Deleted

Comment 2 by, Feb 2 2011

update: changing experimental-webgl to webgl on chrome 10 will not break the page, but webgl will no longer initiate.

Check the 7z file for the entire source
webGL calc.7z
23.0 KB Download

Comment 3 by, Mar 10 2011

still a problem - now with chrome stable.

this is not good...

Comment 4 by, Mar 10 2011


I submitted this report ( a while ago and nobody on the chrome dev team has flagged it or anything.

It's a pretty critical bug, since my major project is broken because of it (

If you know javascript + basic webGL could you take a look at the index.html file I submitted with the bug report and see if you see anything wrong with it?

Also mention whether or not you have a the problem.
Are you running XP? WebGL was disabled in it ( I went to the linked page on Chrome 10 (Windows 7) and it appeared to work fine.

Comment 6 by, Mar 10 2011

odd, I'm running windows 7 as well on chrome 10.

NVIDIA Quadro FX 370M ( driver)

When I first posted this, it didn't work on chrome os, but now it does.

Could you modify the input box?
I could, though it seemed to be difficult. The only one that seemed easy enough to change was the Z Codomain. The others would change but not in realtime and it would be very difficult to select and change those.

In case your driver was blacklisted you can set the flag off (set --ignore-gpu-blacklist in the launcher) to see if it runs on your Windows 7 box. I didn't think Chrome OS had WebGL abilities as of yet (but I could just be out of the loop).

Comment 8 by, Mar 10 2011

you may be having the same problem I'm having then. Did you check the condensed index.html? (the one that's 663 bytes).

See if you can modify the input file on that.

It's not black listed (just tested your argument). I could already run google bodybrowser fine. (probably because they force blur the input box).
You are right, I can modify it but it's difficult to select and I can't see changes in real time. Interestingly there isn't that much difference between this and (which also has an input and a canvas but doesn't suffer the slowdown seen in the attached file).
I'm having this same problem too. It was working but then today, all my input fields are not rendering properly.

Comment 11 by, Mar 11 2011

Maybe I should post this under security. They respond to those in under an hour lol.

As far as I'm concerned this is a critical error, but I don't think it's a security risk.

Does anyone who knows how to use gdb,know if this is exploitable?
I'm having the same problem when my Windows users had their Chrome automatically update from 9 to 10.

You can see the problem here: http://visual.local/seasons/earth/chrome10-test.html

On Windows you can click on the "Predict Average Temperature" input element but you will NOT see any blinking cursor. If you click in the input field and enter say "12" and scroll the window down and back up the entered text "12" will be visible and the text entry field will have a yellow highlight. You can click in the field again and press delete twice. Again you will see no change ... but scroll down and up and the entered number will be gone.

Taking a closer look this problem only appears when I load and run the final javascript:

If I don't load this file the text input field works fine.

This works fine in Chrome 9 and also in the Canary release but not in Chrome 10.

There is a strange possible clue when I inspect the style of the input element.

On Windows there is an extra style which is the third from the top. Here's what I see on Windows:

1) {}

Matched CSS Rules
2) from style.css:1
{ margin: 0px; padding: 0px; }

3) from user: agent stylesheet
input:not([type]), input[type="text"], input[type="password"] { padding: 1px 0px; }

4) from user: agent stylesheet
input, input[type="password"], input[type="search"], isIndex { ... }

That third element appears on Windows where I have the problem and does not appear on Chrome 10 on the Mac where I do not have the problem.

I also do not have the problem on FFv4 on Windows.

Here's a very simple test page that shows the problem:


On Chrome 10 on Windows I can't see any visible response when I click on the text entry field.

The page is also in git here:
I'm having the same problem.

See here:

Sliders and input boxes can affect the canvas, but they do not change in real time.

Comment 15 by, Mar 14 2011

Labels: -Area-Undefined Area-Internals Internals-Graphics Feature-GPU
Status: Assigned
Possible duplicate of 75819.

Comment 16 Deleted

Comment 17 by, Mar 14 2011

kbr, is their an option for bug submitters to upgrade the urgency of their report without sending a new one?

I sent this a month and a half ago (when I encountered it on the dev channel), but didn't know what to do when the bug continued into stable.

Should I have sent a new report?

Furthermore, the issue in a nutshell is webgl (or how the gpu handles webgl) cripples all html input types (sliders, buttons, text etc)

Comment 18 by, Mar 14 2011

Labels: -Pri-2 Pri-1
Status: WontFix
confirmed in 10.0.648.133 beta, but cannot repro in 11.0.696.3 dev or 12.0.703.0 canary build, so the good news is it looks like it's fixed.  adding a few more CC's, this is pretty bad but not a security issue so it won't be merged back to 10.  enne, vangelis, jamesr, this seems like it would be a useful automated test.

@wartex, no there isn't a way for you to up priority, but thank you for your dilligence.  It's our fault for not triaging fast enough.  in cases like this where it's a regression, prefixing with "regression:" might make us spot it sooner.

Comment 19 by, Mar 14 2011

@wartex, in the future if you see a WebGL related regression please feel free to email me the issue ID directly. I didn't see this bug report until today. I also don't know whether you have access to labels but the ones we look for are "Area-Internals", "Internals-Graphics", and "Feature-GPU".

Comment 20 by, Mar 15 2011

In my testing, this is not a WebGL-related issue.  On Windows and Linux, I get an error after I type the first character whether or not the WebGL context has been received.  In a debug build, the stack trace looks related to AutoFill.

AutoCompleteHistoryManager::OnWebDataServiceRequestDone() is in the stack trace. asserts "Check failed: result".

Comment 21 by, Mar 15 2011

Labels: -Area-Internals -Internals-Graphics -Feature-GPU Feature-Autofill
Status: Assigned
A similar autofill crash was fixed in  issue 68783 
Status: WontFix
Looks like the autofill check is only hit in debug mode when using a profile from a newer version, which should be fine for M10.
Why is this issue closed with "won't fix"?

My web application using WebGL broke in a significant way when my Windows users had Chrome auto-update itself from Chrome 9 to 10. 

My app:

Text will not be displayed in the <input> element used to predict temperature.

The fact that Chrome considers v9 => v10 a minor upgrade and appears to auto-update is causing huge problems for the teachers and students using this interactive visualization.

A very simple test page: http://visual.local/seasons/test-for-webgl.html

Comment 25 by, Mar 15 2011

sbanna, it's fixed on 11, so they're going to roll the changes eventually.

Hopefully this problem will be updated sooner because it's a massive problem for me as well.

Comment 26 by, Mar 15 2011

Labels: -Feature-Autofill Internals-Graphics OS-Windows Restrict-AddIssueComment-Commit
isherman, sorry for the hassle, the autocomplete was a red herring.  If I use --user-data-dir=. *and* run on Windows, I can repro this problem in a Debug or Release build.  Getting a WebGL context does appear to be the trigger, which is awfully curious.  I have no idea what chain of events could cause this behavior or what change could have fixed this.

hbridge points out that this is fixed in m11 and isn't a security issue.  So, even though this bug is quite unfortunate, I'm going to leave this as WontFix.
My best guess is that we're not correctly setting up the layer to render GDI form controls into on m10.
Labels: Regression Mstone-10
Status: Assigned
This is actually a pretty serious regression.  The bug isn't related to WebGL but rather to the accelerated compositor and affects more than input boxes. Page contents (both on composited layers and the root layer) fail to update when dirty.

 It appears to be an ANGLE issue (--use-gl=desktop gets things working again).  After some bisecting it looks like the issue was fixed in ANGLE rev 551 which was rolled into chrome at r73241.

I'll verify tomorrow and work on a patch.

A simple test case without WebGL that demonstrates the issue.  Must run chrome with --enable-accelerated-layers to see the issue. Selecting in either the composited layer or the root layer doesn't highlight the text until the window is forced to redraw (e.g. scaling the window)
126 bytes View Download
I verified that revving ANGLE on the 648 branch from r536 to r551 solves the problem. Angle CLs in that range are the following:

There's a handful of CLs in that range that deal with a branch and can safely be ignored.  The ones that affect the trunk are:

537: Fixed gl_PointCoord Y coordinate. [risk = medium]
538: svn:igore [risk = low]
539: added version info resources [risk = low]
540: Fix issues with preprocessor [risk = medium]
541: Pix [risk = low]
542-544: Branch related [risk = none]
545: Reject non-ascii characters in shaders [risk = low]
546-550: Branch related [risk = none]
551: Fixed commitRect [risk = medium]

The crucial ones here are 537 and 551.  We could create a branch and cherry pick them but looking at the inbetween CLs it doesn't look like it's worth the effort.

We definitely need ANGLE r551 in m10. Not having that will cause all kinds of WebGL and compositor problems. r537 is less important but point sprites won't work properly without it.
Status: Fixed
ANGLE rolled to r551 in 648 branch.

Comment 33 by, Mar 17 2011

 Issue 76536  has been merged into this issue.

Comment 34 by, Mar 17 2011

 Issue 76155  has been merged into this issue.

Comment 35 by, Mar 17 2011

 Issue 76449  has been merged into this issue.
Labels: -Regression bulkmove Type-Regression
Chrome Version       : 10.0.648.11
Other browsers tested: chrome 8,9 (they work)

What steps will reproduce the problem?
1. run the index.html

What happens is the getContext(&quot;experimental-webgl&quot;) tag breaks the page (you can't select the input box and enter data). When you use getContext(&quot;webgl&quot;) it works fine. 

Of course this shouldn't work, but it shouldn't break the page either.

Example source attached
The fix should be out shortly, in the upcoming 10 update.
Project Member

Comment 38 by, Mar 9 2013

Labels: -Internals-Graphics -Mstone-10 -Type-Regression Type-Bug-Regression Cr-Internals-Graphics M-10
Project Member

Comment 39 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Components: -Internals>Graphics Internals>GPU
Moving old issues out of Internal>Graphics to delete this obsolete component (  for details)

Sign in to add a comment