Mean to say Roboto Thin is rendering incorrectly not Roboto Light.

Able to reproduce the issue in Android. Observed the Robot Bold is in light color.

Steps Followed
1. Launched Browser
2. navigated to http://www.artesea.co.uk/roboto-test.html
3. Observed the Robot Bold is in light color.

Chrome versions tested
62.0.3202.19
63.0.3215.0

OS
Android 8.0.0, 6.0.1, 

Android Devices
8.0.0 Nexus 6P Build/OPR1.170623.011, 6.0.1: SM-J710F Build/MMB29K

Below is the bisect info:
========================

Good Build: 62.0.3167.0
Bad Build: 62.0.3168.0

MANUAL CHANGELOG URL: 
https://chromium.googlesource.com/chromium/src/+log/62.0.3167.0..62.0.3168.0?pretty=fuller&n=10000

Unable to pinpoint the exact culprit from the above change log. Untriaged to get further input's on this issue.

Issue is seen in M63 as well

Thanks!!

Sandeep, can you try a per revision bisect?

Also does it repro in desktop?

Below is the per revision bisect info:
=====================================

You are looking for a change made after 489123(GOOD), but before 489284(BAD).

CHANGELOG URL: 
https://chromium.googlesource.com/chromium/src/+log/62.0.3167.0..62.0.3168.0?pretty=fuller&n=10000

Unable to find the suspect from above ChangeLog. Someone from Blink>Fonts dev team please have a look on this issue.

Note: Issue is not seen in #61.0.3163.91 Mac 10.12.6, Win 10 and Linux Ubuntu 14.04

Thanks!!

Please find the logs and videos in the below URL --
go/chrome-androidlogs/765980--sandeepkumars/

Thanks!!

As per Comment# 3 & Comment# 5, re-ran the bisect.
Chrome Good Build -- 62.0.3166.0
Chrome Bad Build  -- 62.0.3168.0

https://chromium.googlesource.com/chromium/src/+log/62.0.3166.0..62.0.3168.0?pretty=fuller&n=10000

Results from pre revision bisect --
You are looking for a change made after 489123(GOOD), but before 489284(BAD)

From the above revision range suspecting the following --
https://chromium.googlesource.com/chromium/src/+/ad9b5da819de07237b1986dc59ca06a792467728

@drott -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

Have you had a chance to look into this drott? It's a pretty bad regression.

I'll prioritize this one, thanks for the reminder.

We definitely had larger changes in how we resolve web fonts here, but just in case: Ben, were there any changes to how 
fm->legacyCreateTypeface(name.data(), font_description.SkiaFontStyle()))
resolves fonts on Android since 62 beta?

I'm pretty sure nothing interesting has happened to the Android font handling in Skia. There was a change to language handling / parsing which shouldn't affect this at all, and some changes to some APIs to use smart pointers instead of bare pointers.

I fired this up in the inspector against both Chrome 61 and 62. The output of the "Computed" "Rendered Fonts" appears to be the same across these two.

All of these seem to hit local files (both 61 and 62), which seems really broken. This may stem from the ridiculous CSS that fonts.googleapis.com seems to serve up, which prefers local fonts to the web fonts (this seems ridiculous to even think of, the local font is likely to be a completely different version and in the case of Roboto especially a completely different look). However, on Android at least, it appears these should have all resolved to the web fonts (since there is no font that can be looked up by the name 'Roboto' on Android, 'sans-serif' is normally backed by Roboto, but there is no 'Roboto' in the fonts.xml). It seems 'Roboto' (for the web font) never got matched but the secondary 'sans-serif' took precedence for some reason?

One thing to note is that "Bold" looks like "Regular" in the inspector because they have the same internal font name. On the Android system image the sans-serif 400 (Roboto-Regular.ttf) and sans-serif 700 (Roboto-Bold.ttf) fonts have the same internal display name of 'Roboto'. I hope the display names are never used to disambiguate, as it's very common for these to collide. I'm not sure about the 'Thin'. Maybe it's been fake bolded?

Thanks for the analysis and update on Skia changes in that range. 

I analysed this on Friday and I think I know what "broke" this:
https://chromium-review.googlesource.com/c/chromium/src/+/589270/3/third_party/WebKit/Source/core/css/LocalFontFaceSource.cpp

I put "broke" in quotes, because this change actually makes src: local() handling more correct by taking the styling out the equation, but indeed breaks what Google Fonts is expecting.

There are two problems: Our src: local() matching is broken and does not match full font name or postscript font name, that's issue 627143.

What we do instead, we match src: local() against font family name, plus we take into account the stretch, style, weight request (coming from the CSS styling, stored in FontDescription) and feed this into the family matching.

With this broken local() matching, Google fonts' CSS manages to match against the local robot variants using just local("sans-serif") plus font-weight: bold and font-weight: 100, or 300.

I am going to partially revert the above CL and reinstate the bug, until I get to fixing local() matching in a more durable way.

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

commit dfd362db3e6290db3068702745c2e714fa9c62a4
Author: Dominik Röttsches <drott@chromium.org>
Date: Mon Oct 02 17:10:25 2017

Avoid breaking broken src: local() matching

Partial revert of
https://chromium-review.googlesource.com/c/chromium/src/+/589270

Removing the styling from the FontDescription that is used for local()
matching broke Google Fonts Roboto weights selection on
Android. Reinstate passing those parameters until we have a better fix
for local() matching, which is tracked in crbug.com/627143.

BUG= 765980 

Change-Id: Iffdc1d9f5e19cb841aa1cb3147ca40ca40f5366b
Reviewed-on: https://chromium-review.googlesource.com/695022
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505655}
[modify] https://crrev.com/dfd362db3e6290db3068702745c2e714fa9c62a4/third_party/WebKit/Source/core/css/LocalFontFaceSource.cpp

sandeepkumars@, I tested this on Canary on Android and confirmed the fix. Do you agree? 

The merge should be quite safe, as it is partially reverting to previously existing code.

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

sandeepkumars please confirm

Do you still mean to merge this?

Yes, this should be merged to 62, I am waiting for approval. Let me know if you need anything else from my side.

I still need sandeepkumars to verify this issue. However, go ahead and merge it into 3202 and make sure to verify the fix after merging it.

Sandeep, please verify.

Issue is not seen in latest canary #63.0.3234.0 on Android 6.0.1: SM-J710F Build/MMB29K. Observed the line for Roboto Bold and Light has the correct weights now.

Note: Issue is still seen in beta #62.0.3202.45.

Thanks!!

> I still need sandeepkumars to verify this issue. However, go ahead and merge it into 3202 and make sure to verify the fix after merging it.

Ok, I'll merge. Re the verification: Do you mean in the next updated public Beta build? Or in a local build off of the beta branch?

Merged in https://chromium-review.googlesource.com/c/chromium/src/+/708269/2

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

commit 1af972995791e50fb49070e4665d14ae20fcae2e
Author: Dominik Röttsches <drott@chromium.org>
Date: Tue Oct 10 08:51:21 2017

Avoid breaking broken src: local() matching

Partial revert of
https://chromium-review.googlesource.com/c/chromium/src/+/589270

Removing the styling from the FontDescription that is used for local()
matching broke Google Fonts Roboto weights selection on
Android. Reinstate passing those parameters until we have a better fix
for local() matching, which is tracked in crbug.com/627143.

BUG= 765980 
TBR=drott@chromium.org

(cherry picked from commit dfd362db3e6290db3068702745c2e714fa9c62a4)

Change-Id: Iffdc1d9f5e19cb841aa1cb3147ca40ca40f5366b
Reviewed-on: https://chromium-review.googlesource.com/695022
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#505655}
Reviewed-on: https://chromium-review.googlesource.com/708269
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#632}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/1af972995791e50fb49070e4665d14ae20fcae2e/third_party/WebKit/Source/core/css/LocalFontFaceSource.cpp

Works as per expected behavior,  line for Roboto Bold and Light shows the correct weights.
Issue verified on 62.0.3202.52