My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 71624: "experimental-webgl" breaks page on chrome 10
14 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Closed:  Mar 2011

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Reported by wartex8, Feb 1, 2011
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
Feb 1, 2011
#2 wartex8
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
Mar 10, 2011
#3 wartex8
still a problem - now with chrome stable.

this is not good...
Mar 10, 2011
#4 wartex8

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.
Mar 10, 2011
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.
Mar 10, 2011
#6 wartex8
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?
Mar 10, 2011
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).
Mar 10, 2011
#8 wartex8
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).
Mar 10, 2011
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).
Mar 10, 2011
#10 leith.john
I'm having this same problem too. It was working but then today, all my input fields are not rendering properly.

Mar 11, 2011
#11 wartex8
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?
Mar 13, 2011
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.

Mar 13, 2011
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:
Mar 14, 2011
#14 stephen.panosian
I'm having the same problem.

See here:

Sliders and input boxes can affect the canvas, but they do not change in real time.
Mar 14, 2011
Possible duplicate of 75819.

Status: Assigned
Labels: -Area-Undefined Area-Internals Internals-Graphics Feature-GPU
Mar 14, 2011
#17 wartex8
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)
Mar 14, 2011
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.
Status: WontFix
Labels: -Pri-2 Pri-1
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".

Mar 14, 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".
Mar 14, 2011
(No comment was entered for this change.)
Labels: -Area-Internals -Internals-Graphics -Feature-GPU Feature-Autofill
Mar 14, 2011
A similar autofill crash was fixed in  issue 68783 
Status: Assigned
Mar 14, 2011
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.
Status: WontFix
Mar 15, 2011
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

Mar 15, 2011
#25 wartex8
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.
Mar 15, 2011
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.
Labels: -Feature-Autofill Internals-Graphics OS-Windows Restrict-AddIssueComment-Commit
Mar 15, 2011
My best guess is that we're not correctly setting up the layer to render GDI form controls into on m10.
Mar 15, 2011
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.

Status: Assigned
Labels: Regression Mstone-10
Mar 15, 2011
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
Mar 16, 2011
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.

Mar 16, 2011
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.
Mar 17, 2011
ANGLE rolled to r551 in 648 branch.
Status: Fixed
Mar 17, 2011
 Issue 76536  has been merged into this issue.
Mar 17, 2011
 Issue 76155  has been merged into this issue.
Mar 17, 2011
 Issue 76449  has been merged into this issue.
Mar 18, 2011
Chrome Version       : 10.0.648.11
Other browsers tested: chrome 8,9 (they work)

<b>What steps will reproduce the problem?</b>
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
Labels: -Regression bulkmove Type-Regression
Mar 23, 2011
The fix should be out shortly, in the upcoming 10 update.
Mar 9, 2013
(No comment was entered for this change.)
Labels: -Internals-Graphics -Mstone-10 -Type-Regression Type-Bug-Regression Cr-Internals-Graphics M-10
Mar 13, 2013
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment

Powered by Google Project Hosting