Always use user preference font before system fallback

Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html

Committed: https://crrev.com/5af9dfc5f6ed2163b13d8c20d679bdb44c783769
Cr-Commit-Position: refs/heads/master@{#366532}

[Kunihiko Sakamoto, 2015-11-27 08:25:36]

Description was changed from

==========
WIP

BUG=299010
==========

to

==========
WebFont "loading" fallback and "failure" fallback should match

FontFallbackList::getFontData() returns user's preferred standard font
if it couldn't find any FontData for the family list. If there's at
least one valid FontData, getFontData() for subsequent familyIndex
returns nullptr, so that per-character system fallback is used.

Before this patch, this logic treated "loading" FontData as valid, so
per-character fallback was used while it's loading, and then switched to
standard font if the load failed.

This patch makes getFontData() choose per-character fallback only when
the FontFallbackList has non-blank (non-loading) FontData.

BUG=299010
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

[Kunihiko Sakamoto, 2015-11-27 08:27:03]

Description was changed from

==========
WebFont "loading" fallback and "failure" fallback should match

FontFallbackList::getFontData() returns user's preferred standard font
if it couldn't find any FontData for the family list. If there's at
least one valid FontData, getFontData() for subsequent familyIndex
returns nullptr, so that per-character system fallback is used.

Before this patch, this logic treated "loading" FontData as valid, so
per-character fallback was used while it's loading, and then switched to
standard font if the load failed.

This patch makes getFontData() choose per-character fallback only when
the FontFallbackList has non-blank (non-loading) FontData.

BUG=299010
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

to

==========
WebFont "loading" fallback and "failure" fallback should match

FontFallbackList::getFontData() returns user's preferred standard font
if it couldn't find any FontData for the family list. If there's at
least one valid FontData, getFontData() for subsequent familyIndex
returns nullptr, so that per-character system fallback is used.

Before this patch, this logic treated loading FontData as valid, so
per-character fallback was used while it's loading, and then switched to
standard font if the load failed.

This patch makes getFontData() choose per-character fallback only when
the FontFallbackList has non-blank (non-loading) FontData.

BUG=299010
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

[Kunihiko Sakamoto, 2015-11-27 08:44:28]

Description was changed from

==========
WebFont "loading" fallback and "failure" fallback should match

FontFallbackList::getFontData() returns user's preferred standard font
if it couldn't find any FontData for the family list. If there's at
least one valid FontData, getFontData() for subsequent familyIndex
returns nullptr, so that per-character system fallback is used.

Before this patch, this logic treated loading FontData as valid, so
per-character fallback was used while it's loading, and then switched to
standard font if the load failed.

This patch makes getFontData() choose per-character fallback only when
the FontFallbackList has non-blank (non-loading) FontData.

BUG=299010
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

to

==========
WebFont "loading" fallback and "failure" fallback should match

FontFallbackList::getFontData() returns user's preferred standard font
if it couldn't find any FontData for the family list. If there's at
least one valid FontData, getFontData() for subsequent familyIndex
returns nullptr, so that per-character system fallback is used.

Before this patch, this logic treated loading FontData as valid, so
per-character fallback was used while it's loading, and then switched to
standard font if the load failed.

This patch makes getFontData() choose per-character fallback only when
the FontFallbackList has non-blank (non-loading) FontData.

BUG=299010,545778
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

[Kunihiko Sakamoto, 2015-12-01 04:59:10]

Patchset #1 (id:1) has been deleted

[Kunihiko Sakamoto, 2015-12-01 04:59:18]

Patchset #1 (id:20001) has been deleted

[Kunihiko Sakamoto, 2015-12-01 05:01:53]

ksakamoto@chromium.org changed reviewers:
+ drott@chromium.org

[Kunihiko Sakamoto, 2015-12-01 05:01:53]

PTAL

[drott, 2015-12-01 07:13:57]

Very good to see fallback further fine tuned. I am trying to better understand
the consequences and behavior change of the patch - and I am getting closer, but
could you perhaps explain the before and after a bit more and elaborate a bit on
the change?

> FontFallbackList::getFontData() returns user's preferred standard font
> if it couldn't find any FontData for the family list. 

Do you mean: "...returns the user's preferred standard font if it couldn't find
any font data from the font family list for a given family index."?

> If there's at least one valid FontData, getFontData() for subsequent 
> familyIndex returns nullptr, so that per-character system fallback is used.

This should happen only for loading fonts so that no additional load's are
triggered while the first web font is loading, right?

[Kunihiko Sakamoto, 2015-12-01 08:32:46]

On 2015/12/01 07:13:57, drott wrote:
> Very good to see fallback further fine tuned. I am trying to better understand
> the consequences and behavior change of the patch - and I am getting closer,
but
> could you perhaps explain the before and after a bit more and elaborate a bit
on
> the change?
> 
> > FontFallbackList::getFontData() returns user's preferred standard font
> > if it couldn't find any FontData for the family list. 
> 
> Do you mean: "...returns the user's preferred standard font if it couldn't
find
> any font data from the font family list for a given family index."?

I meant ".. if it couldn't find any font data from *entire* the font family
list".
For example, assume the family list is [Takao, Roboto, NotoSans]. If none of
them is available, user's preferred font is used as fallback. If only Roboto is
available, per-character system fallback is used for characters that Roboto does
not have glyphs.

Now assume Roboto is a webfont and loading. (Takao and NotoSans are not
abailable.)
Before this patch:

 getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
 getFontData(desc, 2) -> nullptr  // per-character fallback

After this patch:

 getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
 getFontData(desc, 2) -> standard font


> > If there's at least one valid FontData, getFontData() for subsequent 
> > familyIndex returns nullptr, so that per-character system fallback is used.
> 
> This should happen only for loading fonts so that no additional load's are
> triggered while the first web font is loading, right?

Not really. In the above example, if NotoSans is also a webfont,
getFontData(desc, 2) returns loading fallback (both before and after this
patch), and getFontData(desc, 3) returns nullptr before this patch, standard
font after this patch.

[drott, 2015-12-01 09:36:22]

On 2015/12/01 08:32:46, Kunihiko Sakamoto wrote:
> On 2015/12/01 07:13:57, drott wrote:
> > Very good to see fallback further fine tuned. I am trying to better
understand
> > the consequences and behavior change of the patch - and I am getting closer,
> but
> > could you perhaps explain the before and after a bit more and elaborate a
bit
> on
> > the change?
> > 
> > > FontFallbackList::getFontData() returns user's preferred standard font
> > > if it couldn't find any FontData for the family list. 
> > 
> > Do you mean: "...returns the user's preferred standard font if it couldn't
> find
> > any font data from the font family list for a given family index."?
> 
> I meant ".. if it couldn't find any font data from *entire* the font family
> list".
> For example, assume the family list is [Takao, Roboto, NotoSans]. If none of
> them is available, user's preferred font is used as fallback. If only Roboto
is
> available, per-character system fallback is used for characters that Roboto
does
> not have glyphs.
> 
> Now assume Roboto is a webfont and loading. (Takao and NotoSans are not
> abailable.)
> Before this patch:
> 
>  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
>  getFontData(desc, 2) -> nullptr  // per-character fallback
> 
> After this patch:
> 
>  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
>  getFontData(desc, 2) -> standard font
> 
> 
> > > If there's at least one valid FontData, getFontData() for subsequent 
> > > familyIndex returns nullptr, so that per-character system fallback is
used.
> > 
> > This should happen only for loading fonts so that no additional load's are
> > triggered while the first web font is loading, right?
> 
> Not really. In the above example, if NotoSans is also a webfont,
> getFontData(desc, 2) returns loading fallback (both before and after this
> patch), and getFontData(desc, 3) returns nullptr before this patch, standard
> font after this patch.

Thanks for the additional explanations, perhaps you can add some of this
information in the commit msg. 

It seems to me that avoiding the user preference font once there is a match from
the fallback list makes things perhaps unnecessarily complicated. In
FontFallbackIterator, which is used for all shaping soon, I try to hand out the
preference font has one step before going to system fallback. It may sound a bit
vague, but could we do this accordingly in FontFallbackList? Also, I am
considering unifying FontFallbackIterator and FontFallbackList - but that's a
separate subject.

https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp (right):

https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp:240: else
Is there a way we could avoid the additional flag? Could it be expressed through
a combination of familyIndex and m_hasLoadingfallback? It seems a bit odd to me
that the flag is set outside of getFontData based on getFontData's result, and
then used inside the getFontData function.

[Kunihiko Sakamoto, 2015-12-11 06:36:18]

On 2015/12/01 09:36:22, drott (travelling until 10th) wrote:
> On 2015/12/01 08:32:46, Kunihiko Sakamoto wrote:
> > On 2015/12/01 07:13:57, drott wrote:
> > > Very good to see fallback further fine tuned. I am trying to better
> understand
> > > the consequences and behavior change of the patch - and I am getting
closer,
> > but
> > > could you perhaps explain the before and after a bit more and elaborate a
> bit
> > on
> > > the change?
> > > 
> > > > FontFallbackList::getFontData() returns user's preferred standard font
> > > > if it couldn't find any FontData for the family list. 
> > > 
> > > Do you mean: "...returns the user's preferred standard font if it couldn't
> > find
> > > any font data from the font family list for a given family index."?
> > 
> > I meant ".. if it couldn't find any font data from *entire* the font family
> > list".
> > For example, assume the family list is [Takao, Roboto, NotoSans]. If none of
> > them is available, user's preferred font is used as fallback. If only Roboto
> is
> > available, per-character system fallback is used for characters that Roboto
> does
> > not have glyphs.
> > 
> > Now assume Roboto is a webfont and loading. (Takao and NotoSans are not
> > abailable.)
> > Before this patch:
> > 
> >  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
> >  getFontData(desc, 2) -> nullptr  // per-character fallback
> > 
> > After this patch:
> > 
> >  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
> >  getFontData(desc, 2) -> standard font
> > 
> > 
> > > > If there's at least one valid FontData, getFontData() for subsequent 
> > > > familyIndex returns nullptr, so that per-character system fallback is
> used.
> > > 
> > > This should happen only for loading fonts so that no additional load's are
> > > triggered while the first web font is loading, right?
> > 
> > Not really. In the above example, if NotoSans is also a webfont,
> > getFontData(desc, 2) returns loading fallback (both before and after this
> > patch), and getFontData(desc, 3) returns nullptr before this patch, standard
> > font after this patch.
> 
> Thanks for the additional explanations, perhaps you can add some of this
> information in the commit msg. 
> 
> It seems to me that avoiding the user preference font once there is a match
from
> the fallback list makes things perhaps unnecessarily complicated. In
> FontFallbackIterator, which is used for all shaping soon, I try to hand out
the
> preference font has one step before going to system fallback. It may sound a
bit
> vague, but could we do this accordingly in FontFallbackList? Also, I am
> considering unifying FontFallbackIterator and FontFallbackList - but that's a
> separate subject.
> 
>
https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp (right):
> 
>
https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp:240: else
> Is there a way we could avoid the additional flag? Could it be expressed
through
> a combination of familyIndex and m_hasLoadingfallback? It seems a bit odd to
me
> that the flag is set outside of getFontData based on getFontData's result, and
> then used inside the getFontData function.

Sorry for slowness, was busy with other things.

Yeah using preference font unconditionally makes the logic simpler. Updated
patch accordingly.

To pass layout tests, besides rebaselines I had to mark two tests as slow on
Mac:
- fast/writing-mode/Kusa-Makura-background-canvas.html
- fast/text/unicode-fallback-font.html

These are already pretty slow (ToT is slower than Chrome stable -- is this
crbug.com/548696?), this change makes them almost 2x slower. Most of running
time is consumed in hb_shape(), and this patch doubles the number of hb_shape()
calls.

I'm a bit worried that this might cause performance regression in real websites.
WDYT?

[drott, 2015-12-21 13:57:14]

On 2015/12/11 06:36:18, Kunihiko Sakamoto wrote:
> On 2015/12/01 09:36:22, drott (travelling until 10th) wrote:
> > On 2015/12/01 08:32:46, Kunihiko Sakamoto wrote:
> > > On 2015/12/01 07:13:57, drott wrote:
> > > > Very good to see fallback further fine tuned. I am trying to better
> > understand
> > > > the consequences and behavior change of the patch - and I am getting
> closer,
> > > but
> > > > could you perhaps explain the before and after a bit more and elaborate
a
> > bit
> > > on
> > > > the change?
> > > > 
> > > > > FontFallbackList::getFontData() returns user's preferred standard font
> > > > > if it couldn't find any FontData for the family list. 
> > > > 
> > > > Do you mean: "...returns the user's preferred standard font if it
couldn't
> > > find
> > > > any font data from the font family list for a given family index."?
> > > 
> > > I meant ".. if it couldn't find any font data from *entire* the font
family
> > > list".
> > > For example, assume the family list is [Takao, Roboto, NotoSans]. If none
of
> > > them is available, user's preferred font is used as fallback. If only
Roboto
> > is
> > > available, per-character system fallback is used for characters that
Roboto
> > does
> > > not have glyphs.
> > > 
> > > Now assume Roboto is a webfont and loading. (Takao and NotoSans are not
> > > abailable.)
> > > Before this patch:
> > > 
> > >  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
> > >  getFontData(desc, 2) -> nullptr  // per-character fallback
> > > 
> > > After this patch:
> > > 
> > >  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
> > >  getFontData(desc, 2) -> standard font
> > > 
> > > 
> > > > > If there's at least one valid FontData, getFontData() for subsequent 
> > > > > familyIndex returns nullptr, so that per-character system fallback is
> > used.
> > > > 
> > > > This should happen only for loading fonts so that no additional load's
are
> > > > triggered while the first web font is loading, right?
> > > 
> > > Not really. In the above example, if NotoSans is also a webfont,
> > > getFontData(desc, 2) returns loading fallback (both before and after this
> > > patch), and getFontData(desc, 3) returns nullptr before this patch,
standard
> > > font after this patch.
> > 
> > Thanks for the additional explanations, perhaps you can add some of this
> > information in the commit msg. 
> > 
> > It seems to me that avoiding the user preference font once there is a match
> from
> > the fallback list makes things perhaps unnecessarily complicated. In
> > FontFallbackIterator, which is used for all shaping soon, I try to hand out
> the
> > preference font has one step before going to system fallback. It may sound a
> bit
> > vague, but could we do this accordingly in FontFallbackList? Also, I am
> > considering unifying FontFallbackIterator and FontFallbackList - but that's
a
> > separate subject.
> > 
> >
>
https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp:240: else
> > Is there a way we could avoid the additional flag? Could it be expressed
> through
> > a combination of familyIndex and m_hasLoadingfallback? It seems a bit odd to
> me
> > that the flag is set outside of getFontData based on getFontData's result,
and
> > then used inside the getFontData function.
> 
> Sorry for slowness, was busy with other things.
> 
> Yeah using preference font unconditionally makes the logic simpler. Updated
> patch accordingly.
> 
> To pass layout tests, besides rebaselines I had to mark two tests as slow on
> Mac:
> - fast/writing-mode/Kusa-Makura-background-canvas.html
> - fast/text/unicode-fallback-font.html
> 
> These are already pretty slow (ToT is slower than Chrome stable -- is this
> crbug.com/548696?), this change makes them almost 2x slower. Most of running
> time is consumed in hb_shape(), and this patch doubles the number of
hb_shape()
> calls.

It doubles the shape calls because the preference font is tried first, and only
then system fallback?

> I'm a bit worried that this might cause performance regression in real
websites.
> WDYT?

LGTM in terms of the code change. Can you check whether the commit msg is still
up to date with the change regarding using the preference font first?

Regarding performance: AAT shaping is slow on Mac, yes, that's one of the issues
and the word cache is not very effective on CJK, that's crbug.com/570229 - the
latter one is something that Koji is working on. The AAT performance can either
be recovered by changing the default fonts, or also get HarfBuzz to implement
AAT natively without falling back to CoreText.

[Kunihiko Sakamoto, 2015-12-22 02:24:58]

Description was changed from

==========
WebFont "loading" fallback and "failure" fallback should match

FontFallbackList::getFontData() returns user's preferred standard font
if it couldn't find any FontData for the family list. If there's at
least one valid FontData, getFontData() for subsequent familyIndex
returns nullptr, so that per-character system fallback is used.

Before this patch, this logic treated loading FontData as valid, so
per-character fallback was used while it's loading, and then switched to
standard font if the load failed.

This patch makes getFontData() choose per-character fallback only when
the FontFallbackList has non-blank (non-loading) FontData.

BUG=299010,545778
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

to

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

[Kunihiko Sakamoto, 2015-12-22 03:01:58]

On 2015/12/21 13:57:14, drott wrote:
> On 2015/12/11 06:36:18, Kunihiko Sakamoto wrote:
> > On 2015/12/01 09:36:22, drott (travelling until 10th) wrote:
> > > On 2015/12/01 08:32:46, Kunihiko Sakamoto wrote:
> > > > On 2015/12/01 07:13:57, drott wrote:
> > > > > Very good to see fallback further fine tuned. I am trying to better
> > > understand
> > > > > the consequences and behavior change of the patch - and I am getting
> > closer,
> > > > but
> > > > > could you perhaps explain the before and after a bit more and
elaborate
> a
> > > bit
> > > > on
> > > > > the change?
> > > > > 
> > > > > > FontFallbackList::getFontData() returns user's preferred standard
font
> > > > > > if it couldn't find any FontData for the family list. 
> > > > > 
> > > > > Do you mean: "...returns the user's preferred standard font if it
> couldn't
> > > > find
> > > > > any font data from the font family list for a given family index."?
> > > > 
> > > > I meant ".. if it couldn't find any font data from *entire* the font
> family
> > > > list".
> > > > For example, assume the family list is [Takao, Roboto, NotoSans]. If
none
> of
> > > > them is available, user's preferred font is used as fallback. If only
> Roboto
> > > is
> > > > available, per-character system fallback is used for characters that
> Roboto
> > > does
> > > > not have glyphs.
> > > > 
> > > > Now assume Roboto is a webfont and loading. (Takao and NotoSans are not
> > > > abailable.)
> > > > Before this patch:
> > > > 
> > > >  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
> > > >  getFontData(desc, 2) -> nullptr  // per-character fallback
> > > > 
> > > > After this patch:
> > > > 
> > > >  getFontData(desc, 0) == getFontData(desc, 1) -> loading fallback
> > > >  getFontData(desc, 2) -> standard font
> > > > 
> > > > 
> > > > > > If there's at least one valid FontData, getFontData() for subsequent

> > > > > > familyIndex returns nullptr, so that per-character system fallback
is
> > > used.
> > > > > 
> > > > > This should happen only for loading fonts so that no additional load's
> are
> > > > > triggered while the first web font is loading, right?
> > > > 
> > > > Not really. In the above example, if NotoSans is also a webfont,
> > > > getFontData(desc, 2) returns loading fallback (both before and after
this
> > > > patch), and getFontData(desc, 3) returns nullptr before this patch,
> standard
> > > > font after this patch.
> > > 
> > > Thanks for the additional explanations, perhaps you can add some of this
> > > information in the commit msg. 
> > > 
> > > It seems to me that avoiding the user preference font once there is a
match
> > from
> > > the fallback list makes things perhaps unnecessarily complicated. In
> > > FontFallbackIterator, which is used for all shaping soon, I try to hand
out
> > the
> > > preference font has one step before going to system fallback. It may sound
a
> > bit
> > > vague, but could we do this accordingly in FontFallbackList? Also, I am
> > > considering unifying FontFallbackIterator and FontFallbackList - but
that's
> a
> > > separate subject.
> > > 
> > >
> >
>
https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
> > > File third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp
(right):
> > > 
> > >
> >
>
https://codereview.chromium.org/1483543002/diff/40001/third_party/WebKit/Sour...
> > > third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp:240: else
> > > Is there a way we could avoid the additional flag? Could it be expressed
> > through
> > > a combination of familyIndex and m_hasLoadingfallback? It seems a bit odd
to
> > me
> > > that the flag is set outside of getFontData based on getFontData's result,
> and
> > > then used inside the getFontData function.
> > 
> > Sorry for slowness, was busy with other things.
> > 
> > Yeah using preference font unconditionally makes the logic simpler. Updated
> > patch accordingly.
> > 
> > To pass layout tests, besides rebaselines I had to mark two tests as slow on
> > Mac:
> > - fast/writing-mode/Kusa-Makura-background-canvas.html
> > - fast/text/unicode-fallback-font.html
> > 
> > These are already pretty slow (ToT is slower than Chrome stable -- is this
> > crbug.com/548696?), this change makes them almost 2x slower. Most of running
> > time is consumed in hb_shape(), and this patch doubles the number of
> hb_shape()
> > calls.
> 
> It doubles the shape calls because the preference font is tried first, and
only
> then system fallback?

Exactly.

> > I'm a bit worried that this might cause performance regression in real
> websites.
> > WDYT?
> 
> LGTM in terms of the code change. Can you check whether the commit msg is
still
> up to date with the change regarding using the preference font first?

Commit msg updated.

> Regarding performance: AAT shaping is slow on Mac, yes, that's one of the
issues
> and the word cache is not very effective on CJK, that's crbug.com/570229 - the
> latter one is something that Koji is working on. The AAT performance can
either
> be recovered by changing the default fonts, or also get HarfBuzz to implement
> AAT natively without falling back to CoreText.

Got it, thanks for the explanation. Let me reuse crbug.com/570656 to track the
slow tests.

[Kunihiko Sakamoto, 2015-12-22 03:02:47]

The CQ bit was checked by ksakamoto@chromium.org

[Kunihiko Sakamoto, 2015-12-22 03:02:47]

The patchset sent to the CQ was uploaded after l-g-t-m from drott@chromium.org
Link to the patchset: https://codereview.chromium.org/1483543002/#ps140001
(title: "Update bug # for slow expectations")

[commit-bot: I haz the power, 2015-12-22 03:03:57]

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

[commit-bot: I haz the power, 2015-12-22 03:10:12]

Description was changed from

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

to

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

[commit-bot: I haz the power, 2015-12-22 03:10:13]

Committed patchset #6 (id:140001)

[commit-bot: I haz the power, 2015-12-22 03:10:54]

Description was changed from

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html
==========

to

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html

Committed: https://crrev.com/5af9dfc5f6ed2163b13d8c20d679bdb44c783769
Cr-Commit-Position: refs/heads/master@{#366532}
==========

[commit-bot: I haz the power, 2015-12-22 03:10:55]

Patchset 6 (id:??) landed as
https://crrev.com/5af9dfc5f6ed2163b13d8c20d679bdb44c783769
Cr-Commit-Position: refs/heads/master@{#366532}

[Noel Gordon, 2015-12-22 04:47:37]

fast/forms/text/text-font-height-mismatch.html change behavior when this change
landed, refer to:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fas...

Please fix or revert.

[Noel Gordon, 2015-12-22 04:53:20]

Description was changed from

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html

Committed: https://crrev.com/5af9dfc5f6ed2163b13d8c20d679bdb44c783769
Cr-Commit-Position: refs/heads/master@{#366532}
==========

to

==========
Always use user preference font before system fallback

Before this patch, FontFallbackList::getFontData() returned user's
preferred standard font only if it couldn't find any FontData in the
family list. otherwise, per-character system fallback was used.

This patch makes getFontData() always return preference font when
it reached the end of family list, so that preference font comes
one step before going to system fallback. This fixes the bug where
webfont fallback while loading and after load failure were inconsistent.

BUG=299010, 545778
TEST=http/tests/webfont/fallback-font-while-loading.html

Committed: https://crrev.com/5af9dfc5f6ed2163b13d8c20d679bdb44c783769
Cr-Commit-Position: refs/heads/master@{#366532}
==========

[Kunihiko Sakamoto, 2015-12-22 05:01:56]

On 2015/12/22 04:47:37, noel gordon wrote:
> fast/forms/text/text-font-height-mismatch.html change behavior when this
change
> landed, refer to:
> 
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fas...
> 
> Please fix or revert.

Thanks for the heads up. Fixing in https://codereview.chromium.org/1539333004/.

[Noel Gordon, 2015-12-22 05:24:36]

Thank you.

[Noel Gordon, 2015-12-22 05:27:08]

On 2015/12/22 05:24:36, noel gordon wrote:
> Thank you.

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20XP/builds/23412 

fast/forms/text/text-font-height-mismatch.html failed on XP too :(