I have this same exact problem.  Just started happening a couple of days ago.  My chrome version is "Version 56.0.2924.87 (64-bit)".  From what I've read, it seems to be related to EVGA precision X (Overclocking software for nVidia graphics cards) which I have, but precision X has been on my PC for quite sometime (as I am sure many other people have also) and this issue never showed up until now.  Its not related to a change in precision x either because I have not updated precision x for while (maybe 6 months or so).

Hello I got the same problem but only on youtube and nothing else. I have tried all the steps as you described and even downloading the developer version "canary" of chrome and the problem is still the same. (note that the developer version runs entirely separate from ordinary chrome. This just happened as I was rendering a video in sony vegas a few days ago and mid browsing everything turned bold. This might be a bug with an update and some hardware or something. I don't have this problem on my laptop or phone so it's something between our computers and in my case youtube.Also disabled my extensions and done basically everything the people in the yt and google help forums asked me to.

Deleted: bugpic1.png 1.1 MB

	bugpic1.png 1.1 MB View Download

Unable to reproduce the issue on Win-10, Ubuntu 14.04 and Mac 10.12.2 using chrome reported version #56.0.2924.76, latest stable #56.0.2924.87 and latest canary #58.0.3007.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
(1) Opened Chrome and navigated to google.com and youtube.com
(2) Searched by typing some text.
(3) Did not observe any font bold issue while searching in google.com or youtube.com.

jainabhishek@ - Could you please check this issue on latest stable #56.0.2924.87 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Deleted: 690334.mp4 10.4 MB

	690334.mp4 10.4 MB View Download

Seems there might be some relation to having EVGA Precision XOC installed: https://productforums.google.com/d/msg/chrome/GoQ7NqvQG-w/3EcUMrfNBgAJ

Users have tried 
- deleting cookies/cache etc
- running in incognito mod
- disabling all my extensions
- disable hardware acceleration

Users also report that Removing  Roboto-Bold font from the font folder (C:\Windows\Fonts) fixes the issue.

Forum : https://productforums.google.com/forum/#!topic/chrome/W3mCbEMZ7sE

Thanks jainabhishek. If a user has roboto-bold installed but not roboto-regular then a site that requests Roboto (as a local font) would get the bold version which explains the behavior.

Installing Roboto-Regular or removing Roboto-bold would both fix it.

As we've seen a few similar bugs like this and quite a few reports of this one instance we might want to change FontCache::createFontPlatformData to not match bold typefaces when a regular weight one is requested. Even if it is the closest match. Dominik, what do you think?

I can confirm that installing "Roboto Regular" worked on removing the bold on youtube. I only had "Roboto Black" installed apparently. I installed "Roboto Bold" as well but I can't seem to see bold comments anymore on youtube, thoughts? 

Also if I delete all the roboto fonts what font will be displayed instead?

Seems to have something to do with font matching against local fonts for Roboto Bold vs. Regular. Roderick, any insights?

Regarding comment #8, I believe the issue here is not in font-family: matching but in matching src: 'local(Roboto)' - for this case we should definitely not match "Roboto Bold" for "Roboto".  In the regular font-family: matching, I don't think we should deviate from the "nearest match" approach in the spec. WDYT, Emil?

I can try to create a reduction and see if this assumption is correct.

I agree in principle but it's tricky as the weight isn't really a part of the name of a font. local(Roboto) should work for all weights and styles that are available locally.

Google Fonts issues src: local('Roboto'), local('Roboto-Regular'), url(...) for Roboto 400. If local('Roboto') matches locally installed Roboto Bold that would be surprising.

If I'm reading the spec right local('Roboto') should "match only the Postscript name or the full font name in the name table of locally available fonts." [1] so ... either the font 'name' table or the local() matching is wrong?

Hm. Are we running the matching algorithm for local() names?

1: https://www.w3.org/TR/css-fonts-3/#src-desc

It is hard to tell without the font in question. Google Fonts correctly sets both the postscript and full name fields to "Roboto Bold".

With a test like:

<style>
  @font-face {
  font-family: robototest;
  src: local("Roboto Regular");
  }
  body {
  font-family: robototest, serif;
  }
</style>
Roboto Bold or Times

We match against Roboto Bold if that's the only Roboto installed. This is because FontCache::isPlatformFontAvailable() returns true in this case and matches against the bold version. Family name is not sufficient to distinguish Roboto weights.

We do unfortunately go through the same code path for matching local() vs. font-family:, which causes this problem: Roboto Regular has "Roboto-Regular" for nameid 6 (postscript name) in the name table, Roboto Bold has "Roboto-Bold" there but both of them have family name (nameid 1) Roboto and this seems to be what we can access through Skia.

We should fix this by retrieving the postscript name for FontPlatformData/SkTypeface, and - as a first approximation - only accept a local() match if the requested name in local() matches the namerecord 4 value. Ideally, we should search by Postscript name on the platform, instead of by family name.

However, for the "Regular" case, Emil, I think we can have a temporary fix. In FontCacheSkiaWin.cpp we do this:

    } else if (typefacesHasWeightSuffix(creationParams.family(), adjustedName,
                                        variantWeight)) {
      FontFaceCreationParams adjustedParams(adjustedName);
      FontDescription adjustedFontDescription = fontDescription;
      adjustedFontDescription.setWeight(variantWeight);
      tf = createTypeface(adjustedFontDescription, adjustedParams, name);
      if (!tf || !typefacesMatchesFamily(tf.get(), adjustedName))
        return nullptr;

    } else if (typefacesHasStretchSuffix(creationParams.family(), adjustedName,

I believe this cuts off the " Regular" weight suffix and triggers the "overeager" match towards "Roboto" just by family name in this case. Similar to your CL, we could probably get away with not returning a bold typeface if the requested family name was "... Regular" to fix this temporarily.

Ok, that makes sense. Do you want to make the change or should I?

Thanks drott.

I'll try to do the temporary Windows fix until the end of the week.

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

commit d31bcba110520454ced012b05695f9c471446a52
Author: drott <drott@chromium.org>
Date: Tue Feb 28 14:57:25 2017

Fix matching Roboto Bold for src: local("Roboto Regular")

Our @font-face { src: local() } matching is incorrectly going down the
same code path that is used for matching CSS font-family. On Windows,
this family match code path takes extra steps to ensure something like
"Roboto Regular" is matched against Roboto, or "Roboto Bold" is matched
against Roboto, in a bold variant. However, this type of matching is too
wide for local(), where the CSS fonts module specification expects a
unique match against full font name or postscript name. On Windows, it
was incorrectly matching local("Roboto Regular") against "Roboto Bold"
if that was the only available Roboto font on the system.

This CL is a temporary fix for the case of "Roboto Regular" matching
against Roboto Bold. However, matching local("Roboto Bold") against the
actual Roboto Bold does still not work, also local("Roboto") still
matches against Roboto Bold if that is the only available Roboto on the
system. A full fix requires access to the OpenType name table and
reading the full font name or postscript name.

TEST=Manual, using src: local("Roboto"), local("Roboto Regular"),
     local("Roboto Bold") with only Roboto Bold installed on the system
BUG= 690334 

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

[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/LayoutTests/fast/css/beforeSelectorOnCodeElement.html
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/LayoutTests/fast/css/font-face-multiple-ranges-for-unicode-range.html
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/core/css/CSSFontSelector.cpp
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/core/css/CSSFontSelector.h
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/core/css/FontFaceSet.cpp
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/core/css/LocalFontFaceSource.cpp
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/platform/fonts/FontCache.cpp
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/platform/fonts/FontCache.h
[modify] https://crrev.com/d31bcba110520454ced012b05695f9c471446a52/third_party/WebKit/Source/platform/fonts/win/FontCacheSkiaWin.cpp

This CL should help, closing this one as fixed and de-duping, issue 627143 is still not completely fixed.  jainabhishek@, could you please verify in a Canary by installing Roboto Bold on Windows locally using the download from Google Fonts and visiting a Google login page or any of the mentioned problematic URLs? Thank you.

Thanks! Installed Roboto Regular and it was fixed for me immediately. I also have EVGA Precision XOC installed and my chrome version is 57.0.2987.110 with Windows 10 Pro 64 bit + anniversary update. It was driving me nuts search results looked terrible on a 27" 4k screen. Appreciate the work!

This problem occurs after installing EVGA Precision. 
https://forums.evga.com/Precision-X-Replaces-Arial-Bold-Font-m2220653-p2.aspx