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

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
Committed: https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4
Cr-Commit-Position: refs/heads/master@{#393957}

[Jinsuk Kim, 2016-05-16 06:17:41]

jinsukkim@chromium.org changed reviewers:
+ jshin@chromium.org, tkent@chromium.org

[tkent, 2016-05-16 06:25:41]

Please handle imported/web-platform-tests/html/semantics/interfaces.html
failure.

[Jinsuk Kim, 2016-05-16 08:39:19]

Fixed the failing test. The other failing tests look like flaky.

[tkent, 2016-05-16 08:43:55]

https://codereview.chromium.org/1979103003/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/imported/web-platform-tests/html/semantics/interfaces.html
(right):

https://codereview.chromium.org/1979103003/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/imported/web-platform-tests/html/semantics/interfaces.html:2:
<meta charset=utf-8>
Do no modify imported tests.  Such changes will be reverted by the next import.

[Jinsuk Kim, 2016-05-16 09:24:41]

On 2016/05/16 08:43:55, tkent wrote:
>
https://codereview.chromium.org/1979103003/diff/20001/third_party/WebKit/Layo...
> File
>
third_party/WebKit/LayoutTests/imported/web-platform-tests/html/semantics/interfaces.html
> (right):
> 
>
https://codereview.chromium.org/1979103003/diff/20001/third_party/WebKit/Layo...
>
third_party/WebKit/LayoutTests/imported/web-platform-tests/html/semantics/interfaces.html:2:
> <meta charset=utf-8>
> Do no modify imported tests.  Such changes will be reverted by the next
import.

Rebaselined the test instead. Let me know if this works. I suppose the
-expected.txt can be updated as it won't be imported like the html/js.

[Jinsuk Kim, 2016-05-16 11:48:29]

Patchset #4 (id:60001) has been deleted

[tkent, 2016-05-16 12:09:14]

lgtm

[Jinsuk Kim, 2016-05-16 20:46:09]

The CQ bit was checked by jinsukkim@chromium.org

[commit-bot: I haz the power, 2016-05-16 20:47:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1979103003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1979103003/80001

[Jinsuk Kim, 2016-05-16 21:07:05]

The CQ bit was unchecked by jinsukkim@chromium.org

[Jinsuk Kim, 2016-05-16 21:46:21]

Description was changed from

==========
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.
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,608424
==========

to

==========
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
==========

[Jinsuk Kim, 2016-05-16 21:46:55]

The CQ bit was checked by jinsukkim@chromium.org

[commit-bot: I haz the power, 2016-05-16 21:47:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1979103003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1979103003/80001

[commit-bot: I haz the power, 2016-05-16 22:43:44]

Description was changed from

==========
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
==========

to

==========
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
==========

[commit-bot: I haz the power, 2016-05-16 22:43:45]

Committed patchset #4 (id:80001)

[commit-bot: I haz the power, 2016-05-16 22:44:41]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4
Cr-Commit-Position: refs/heads/master@{#393957}
==========

[commit-bot: I haz the power, 2016-05-16 22:44:42]

Patchset 4 (id:??) landed as
https://crrev.com/1673e2f6087df0f802117110dda2bf6b42b56ef4
Cr-Commit-Position: refs/heads/master@{#393957}