Able to reproduce the issue on win8.1, mac 10.11 and Linux 14.04 chrome version 52.0.2724.0  - green WebGL Cube on the left is not displayed

This is a regression in M52 and below is the bisect info

Manual Bisect:

Good Build: 52.0.2714.0  
Bad Build: 52.0.2715.0

Bisect Tool Info:

You are probably looking for a change made after 388918 (known good), but no later than 388932 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/cc6f5bb234e3f7f0dd29037dc9196d02022fad1f..0f9d36e6579569f4c727f964fee4fd642e39b67e

Possible suspect : https://codereview.chromium.org/1896953003

Please reassign if this is not related to your change.

This is not caused by https://codereview.chromium.org/1896953003

CC'ing chrishtr@ as the next best guess.

chrishtr@, Is it possible that https://codereview.chromium.org/1864603003 could have caused this?

It's not my change. Trying manual builds to see what really caused it.

The proximate cause is:
https://chromium.googlesource.com/chromium/src/+/57139d64c5b98142ca9305792f39ae23a4950375

helumt@ Is it possible to add, for debugging's sake, a charset meta tag on the page (or let the server send charset http header) to see if that makes the problem go away? I see the page missing the right encoding info.

Or just turn on auto encoding detection from menu -> More tools -> encoding for the same effect.

I have added <meta charset="iso-8859-1"> to the page. This did not solve the problem. Also <meta charset="utf-8"> makes no difference w.r.t to the javascript problem, but the special German characters in the page need the iso-8859-1.

I just discovered that the problem also occurs on 
http://www.taccgl.org/blog/parallax-scrolling/example1.html 
(and example2.html - example9.html as well). 
This is a much shorter example page, on the same server as 
the included lib and does not use any German encoding. 
On the other hand there are plenty of other pages on that domain,
that include the lib and work fine.

The js is encoded in UTF-8 which had been previously ignored and just treated as iso-8859-1 (seen as windows-1252). The encoded characters were in the comment section so it worked without problems. Now UTF-8 detector added in the patch detected it correctly but somehow the decoded js seems to have a problem. I'll take a look.

helmut@ Could you try to add a charset tag in the script tag embedding the js file?

<script src="http://www.taccgl.org/scripts20130819/src/taccgl.js" defer async></script>

--->

<script src="http://www.taccgl.org/scripts20130819/src/taccgl.js" defer async charset="utf-8"></script>

I'm not suggesting this as a permanent solution. It would just help me see where to look. 

> On the other hand there are plenty of other pages on that domain,
> that include the lib and work fine.

Could you give me some pages that work fine? I'd like to compare what the difference is.

Thanks!

Adding the charset="utf-8" declaration makes the js work. I added the charset only to the "?dbg=t" version, so http://www.h-e-i.de still exposes the problem.

>  Could you give me some pages that work fine?
http://www.taccgl.org, http://www.taccgl.org/blog/HTMLpages-with-3D-objects.html,
http://www.taccgl.org/blog/css-transition-visibility.html and all the other blog 
articles, except for the http://www.taccgl.org/blog/parallax-scrolling/example1.html.

The same for the Tutorial http://www.taccgl.org/tutorial/ and all the 15 subpages
work, except for the super simple http://www.taccgl.org/tutorial/firstExampleCode.html.
In the manual all pages seem to work, e.g. http://www.taccgl.org/developer_doc/taccgl_class/actor.html.

Also the http://www.taccgl.de page works, which uses utf-8 for the special german
characters, in contrast to http://www.h-e-i.de which is still on iso-8859-1.

Also Supported for all programs

Tested the issue on windows 7, Mac 10.11.4 using chrome version 52.0.2738.0 with the URL http://www.h-e-i.de/?dbg=t.Able to see the green webgl on the left side.Please find the attached screen shot for the same.

helmut.emmelmann@ Request you please check the issue from your end as well with the latest canary and update the thread if the issue still persists.

Thanks,

The problem still persists in chrome 52.0.2738.0 Win 8.1 on http://www.h-e-i.de.
It does not show up on the http://www.h-e-i.de/?dbg=t version, since 
I changed that version (see my comment #11) because I was asked to do so in comment #10.

CL for fix is in review. Stay tuned.

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

commit 1673e2f6087df0f802117110dda2bf6b42b56ef4
Author: jinsukkim <jinsukkim@chromium.org>
Date: Mon May 16 22:43:28 2016

Revert "Reland "UTF-8 detector for pages missing encoding info""

UTF-8 detector introduced in crrev.com/1890103002 is suspected to
cause a couple of bugs due to UTF-8 encoding detection being applied
to wider ranges of web documents. It may have caused overall page
loading time regression by 5% reported via Omaha
PageLoad.Timing2.NavigationToFirstContentfulPaint.
(Update: the regression was caused by something else)

The other bug was confirmed to have been caused by the CL since
the detection changed (albeit correctly) the encoding of the documents
that had not been affected before.

An alternative to address them would be narrow the scope of
the encoding detector but it defeats one of the the goals of the UTF-8
detection expected to set the previously misinterpreted encodings
right for more documents. crrev.com/1960943002

I'm reverting the CL in the hope that the bugs will go away before
branching to M52 scheduled this week. The plan is bring CED to light,
substitute ICU and turn on the automatic encoding detection by
default. CED is much more efficient than ICU, and can potentially
eliminate the need for UTF-8 detection. I'll evaluate the usefulness
of UTF-8 encoding detection afterwards.

This reverts commit 57139d64c5b98142ca9305792f39ae23a4950375.

BUG= 609053 

Review-Url: https://codereview.chromium.org/1979103003
Cr-Commit-Position: refs/heads/master@{#393957}

[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/LayoutTests/TestExpectations
[delete] https://crrev.com/19211b57d72c9f80763494278659f0b2322a8e75/third_party/WebKit/LayoutTests/fast/encoding/unlabelled-non-ascii-utf8-expected.html
[delete] https://crrev.com/19211b57d72c9f80763494278659f0b2322a8e75/third_party/WebKit/LayoutTests/fast/encoding/unlabelled-non-ascii-utf8.html
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/core/core.gypi
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/core/html/parser/TextResourceDecoder.cpp
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/core/html/parser/TextResourceDecoder.h
[delete] https://crrev.com/19211b57d72c9f80763494278659f0b2322a8e75/third_party/WebKit/Source/core/html/parser/TextResourceDecoderTest.cpp
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/platform/text/TextEncodingDetector.cpp
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/platform/text/TextEncodingDetector.h
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/wtf/text/UTF8.cpp
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/wtf/text/UTF8.h
[delete] https://crrev.com/19211b57d72c9f80763494278659f0b2322a8e75/third_party/WebKit/Source/wtf/text/UTF8Test.cpp
[modify] https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4/third_party/WebKit/Source/wtf/wtf.gypi

[Auto-generated comment by a script] We noticed that this issue is targeted for M-52; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-52 label, otherwise remove Merge-TBD label. Thanks.

[Bulk edit]

Our blockerbot script was offline; it was recently brought back online, and thus labeled many old issues (including this one) erroneously.  Removing Merge-TBD label since all milestones for this issue are already completed; no further work should be done.