Firefox, Safari and Edge all have the same behavior, matching what it's shown in expected-result.png

This issue is only happening in Chrome, then. 

I couldn't find any explicit statement about this behavior in the spec, but I think the following one is perhaps the one we should follow in this case:

https://drafts.csswg.org/css-text-3/#valdef-overflow-wrap-break-word

"An otherwise unbreakable sequence of characters may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line."

Note the *if there are no otherwise-acceptable break points* part of the sentence. I think the leading white-spaces should be considered as better soft-breaking opportunities in this case. 

The white-space sequence is not collapsed because of the white-space: pre-wrap rule.

Oh, interesting case. So the question here is, while there's a break opportunity between a space and a non-space, whether there should be one or not when the space is a leading space.

I guess I have to re-read UAX14 more carefully later to know what it says for this case, but it looks to me that the current blink behavior looks reasonable from the typography perspective.

Hi Florian, could you give your opinion about this issue ? I think it's related to some [1][2] of the tests you wrote for the combination of break-word and break-spaces. 

I think this issue is, in a way, related to this discussion [3] that happened a while ago in the W3C. 

Although the mentioned discussion was specifically about the combination of break-word and break-spaces, it concludes that because 'break-words' can break at "any character" it indeed allows breaking before the white-space between 2 words.

This will imply that the word following will me moved down to the next line with a leading space. The only way to achieve the expected result of overflow-wrap-break-word-003.html is by considering such leading white-space as a soft wrap opportunity that 'break-word' should consider to avoid breaking the word.   

[1] https://github.com/frivoal/web-platform-tests/blob/master/css/css-text/overflow-wrap/overflow-wrap-break-word-002.html
[2] https://github.com/frivoal/web-platform-tests/blob/master/css/css-text/overflow-wrap/overflow-wrap-break-word-003.html
[3] https://github.com/w3c/csswg-drafts/issues/2003

A few more updates:
* Checked UAX#14, it doesn't talk about leading spaces at all, so break after leading spaces seems correct. Though, it's possibly an overlook. I might make a feedback to UAX#14.
* Created tests by myself but did not reproduce. Meaning it's probably hitting some other conditions and Blink behavior is unreliable.

I'm not opposed to change, especially if it makes more interoperable. Great if you guys can help.

Note, I think you should first test without 'break-word' and see if the line breaks or not. It's a line breaker test.

If the line doesn't break, meaning no break opportunity is recognized by the UA, then 'overflow-wrap' should kick in if you apply it. It's an 'overflow-wrap' test.

...not sure if I could explain well. In other words in case this wasn't clear, since break opportunity is UA-dependent, you should test break opportunity first, and then test 'overflow-wrap' only for when it overflows without 'overflow-wrap'. Did I explain well?

> ...Blink behavior is unreliable.

Found it. Blink behavior vary by one or two leading spaces. They should be consistent.

LayoutNG, on the other hand, does not break after leading spaces, so it's more like to what I described, but 'overflow-wrap' is consistent. In other words, 'overflow-wrap' in NG does not have the problem the current engine has, but breaking behavior (which is out-of-scope for CSS) is a bit different. This may not be what you desire as I understand from your case.

> I think this issue is, in a way, related to this discussion [3] that happened a while ago in the W3C. 

I hope you agree by now but, this test is about Blink 'overflow-wrap' behaves inconsistent with line break algorithm when there is only one leading space. I agree it's a bug.

Whether to have a break opportunity after leading spaces or not is a separate issue, an interesting topic to me, I thought this is about it, but sorry it was not related.

> I hope you agree by now but, this test is about Blink 'overflow-wrap' behaves inconsistent with line break algorithm when there is only one leading space. I agree it's a bug.

Yes, I can confirm the bug is about inconsistencies when there is only one leading space. I also thought the root cause was not considering leading white-spaces as breaking opportunities, but now I have doubts. 

I'll study the issue further and change the issue title if needed. 

Thanks for your feedback.

> LayoutNG, on the other hand, does not break after leading spaces, so it's more like to what I described, but 'overflow-wrap' is consistent. In other words, 'overflow-wrap' in NG does not have the problem the current engine has, but breaking behavior (which is out-of-scope for CSS) is a bit different. This may not be what you desire as I understand from your case.

Regarding that, I don't understand why line-breaking behavior is out-of-scope of CSS. Is then acceptable that browsers behave different in these cases ? 

At least, this case will affect several of the WPT defined for the break-spaces value; maybe we should discuss first if those tests are correct.

This is absolutely a bug. overflow-wrap:break-word is not supposed to do anything unless the line would otherwise overflow. Line breaking should be done first normally, and if after that we're still overflowing, overflow-wrap:break-word kicks in and allows breaks in the middle of words.

> This property specifies whether the UA may break at otherwise disallowed points within a line to prevent overflow, when an otherwise-unbreakable string is too long to fit within the line box,

> An otherwise unbreakable sequence of characters may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line

Now, should there be a wrap opportunity before that leading space and that word? Yes:

> If white-space is set to pre or pre-wrap, any sequence of spaces is treated as a sequence of non-breaking spaces. However, a soft wrap opportunity exists at the end of the sequence. 


Koji said:
> Note, I think you should first test without 'break-word' and see if the line breaks or not. It's a line breaker test.
>
> If the line doesn't break, meaning no break opportunity is recognized by the UA, then 'overflow-wrap' should kick in if you apply it. It's an 'overflow-wrap' test.

In stable chrome, the line does break after the leading space if you remove overflow-wrap:break-word, so that's a bug in overflow-wrap, not in line breaking.

For Layout-NG, I cannot test, but if you say that it does not wrap after the leading spaces when overflow-wrap:break-word is removed, that's a bug, as this is a clear violation of :

> If white-space is set to pre or pre-wrap, any sequence of spaces is treated as a sequence of non-breaking spaces. However, a soft wrap opportunity exists at the end of the sequence. 

Attached a test case for the issue without overflow-wrap property, so we can evaluate the line-breaking logic, only combined with the white-space rules.

1- The basic case, as it's attached, produces the following results:

Chrome, Firefox, Edge: 
|  WO|
|RD  |

Safari:
|    |
|WORD|
 
Now with just 1 single white space:

Chrome, Firefox, Edge: 
| WOR|
|D   |

Safari:
|    |
|WORD|


2- Now lets try with 'word-break: normal; white-space: pre-wrap'

Chrome, Firefox, Edge, Safari: 
|    |
|WORD|

Now with just 1 single white space:

Chrome, Firefox, Edge, Safari: 
|    |
|WORD|


3- Now lets try with 'line-break: anywhere; white-space: pre-wrap'

Chrome, Firefox, Edge, Safari:
|    |
|WORD|

Now with just 1 single white space:

Chrome, Firefox, Edge, Safari: 
|    |
|WORD|

Deleted: word-break-bug.html 202 bytes

word-break-bug.html 202 bytes View Download

#14: I think you misunderstood some of #13, but I agree that this case is a bug as in #13. Changed summary to my understanding, reporter, please correct if I seem to understood incorrectly.

> In stable chrome, the line does break after the leading space if you remove overflow-wrap:break-word, so that's a bug in overflow-wrap, not in line breaking.

Yes, the examples above confirm that line-breaking must occur after the leading white-space, so the bug is clearly in the overflow-wrap, which is preventing this to happen (when there is only 1 leading white-space) which cause the word to be broken instead. 

What I still not sure about is whether layout-ng should behave like that and, even consistently, prefer to break the work instead of using the soft wrap opportunity at the end of the leading white-space sequence.

#15: line-break:anywhere is not implemented yet, so the result of 2- and 3- should be the same.

> What I still not sure about is whether layout-ng should behave like that and, even consistently, prefer to break the work instead of using the soft wrap opportunity at the end of the leading white-space sequence.

I don't see why allows this in the spec. If word-break has its initial value of normal, breaking in the middle of (english) words is not ok. if white-space is pre-wrap, there is a soft wrap opportunity after the leading space(s). It is the only one in the line, so to avoid overflow, that is the point where we should break.

How do you reach a different conclusion?

> How do you reach a different conclusion?

It was not a conclusion, I really think it shouldn't behave like that. I'm just questioning what koji said in comment #10: 

> LayoutNG, on the other hand, does not break after leading spaces, so it's more like to what I described, but 'overflow-wrap' is consistent. In other words, 'overflow-wrap' in NG does not have the problem the current engine has, but breaking behavior (which is out-of-scope for CSS) is a bit different. This may not be what you desire as I understand from your case.

> #15: line-break:anywhere is not implemented yet, so the result of 2- and 3- should be the same.
 
Yes, sorry for the noise that case introduced. It behaves like that using a line-break: normal" too. What I wanted to show with those examples is that current line-breaking implementation in all the engines, including chrome, clearly considers leading white-spaces as soft wrap opportunities. 

Attaching my test. The position of "1" should match in each pair of boxes.

Deleted: line-break-leading-space-854624.html 905 bytes

line-break-leading-space-854624.html 905 bytes View Download

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

commit 6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Tue Jul 17 10:01:57 2018

[css-text] A leading white-space should break before handling overflow

Leading white-spaces are indeed breaking opportunities that should
prevent, if there are no other css properties forcing it, breaking text
in the middle of a word when honoring the word-wrap/overflow-wrap CSS
property.

We are doing so if the leading white-space sequence is longer than 1
character, but when we have a single leading white-space, we are missing
that breaking opportunity and we may lead to cases, like the one
described in the bug.

However, this breaking opportunity should be considered together
with other provided by the word-break CSS property (eg, break-word or
break-all).

There is a discussion [1] in the CSS WG github about this issue, which
provides an interoperability analysis of a few cases where a single
leading white-space character may produce different results, depending
on the browser and the combination of line-breaking properties.

[1] https://github.com/w3c/csswg-drafts/issues/2907

Bug:  854624 
Change-Id: I49ec8282e899a32990662c104b48cab04057b909
Reviewed-on: https://chromium-review.googlesource.com/1130515
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575596}
[add] https://crrev.com/6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a/third_party/WebKit/LayoutTests/external/wpt/css/css-text/overflow-wrap/overflow-wrap-break-word-004.html
[add] https://crrev.com/6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/reference/word-break-break-all-010-ref.html
[add] https://crrev.com/6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-010.html
[add] https://crrev.com/6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-011.html
[modify] https://crrev.com/6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a/third_party/blink/renderer/core/layout/line/breaking_context_inline_headers.h

This issue should be FIXED now. However, I think the layout-ng engine still has the same issue. Should we keep this bug open, maybe updating the component ? Or should we file a new bug against the layout-ng engine ? 

So are you going to fix LayoutNG as well? That is awesome if so.

Regarding the process for LayoutNG, we may or may not file bugs for each test failures.

Once-a-few-days a semi-auto process runs to maintain FlagExpectations for LayoutNG[1]. This process adds new failures if any, and since you added tests, they will appear there. The total number of failures is tracked in this chart[2]. Your tests are in css-text directory, so the count of the directory will increase automatically.

We're trying to make it zero by the end of Q3. To do this, you can file a bug for specific failures, or you can just fix and tag the CL with any meta-bug such as issue 636993. Since there are so many failures at this point, filing bugs is optional, only when needed for some other purposes such as discussing how to fix etc.

If you can help LayoutNG, I'm more than happy to provide further guidance that may help you to work on it.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/FlagExpectations/enable-blink-features%3DLayoutNG?type=cs&q=FlagExpectation&sq=package:chromium&g=0
[2] https://kojiishi.github.io/chromium-tools/index.html

Learning more about LayoutNG is always a top task in my TODO lost, so I wouldn't mind to spend some time on this. However, I don't want to interfere or delay a fix if you are already working on it. 

If there is not to much pressure to fix this ASAP, I can definitively give it a try. 

Thank you Javier, no rushing at all, appreciate your efforts to help LayoutNG!

I'll reopen this bug since I reverted the fix (https://crrev.com/c/1146360)

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

commit 04c10b73375e9b4886aa67fe484d18b6c2af1fc7
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Sun Jul 22 21:53:14 2018

Revert "[css-text] A leading white-space should break before handling overflow"

This reverts commit 6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> [css-text] A leading white-space should break before handling overflow
> 
> Leading white-spaces are indeed breaking opportunities that should
> prevent, if there are no other css properties forcing it, breaking text
> in the middle of a word when honoring the word-wrap/overflow-wrap CSS
> property.
> 
> We are doing so if the leading white-space sequence is longer than 1
> character, but when we have a single leading white-space, we are missing
> that breaking opportunity and we may lead to cases, like the one
> described in the bug.
> 
> However, this breaking opportunity should be considered together
> with other provided by the word-break CSS property (eg, break-word or
> break-all).
> 
> There is a discussion [1] in the CSS WG github about this issue, which
> provides an interoperability analysis of a few cases where a single
> leading white-space character may produce different results, depending
> on the browser and the combination of line-breaking properties.
> 
> [1] https://github.com/w3c/csswg-drafts/issues/2907
> 
> Bug:  854624 
> Change-Id: I49ec8282e899a32990662c104b48cab04057b909
> Reviewed-on: https://chromium-review.googlesource.com/1130515
> Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
> Reviewed-by: Koji Ishii <kojii@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#575596}

TBR=jfernandez@igalia.com,kojii@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  854624 
Change-Id: I9ee4cd370dd92b74f9fdc4f42d16638253dd2dee
Reviewed-on: https://chromium-review.googlesource.com/1146360
Reviewed-by: Javier Fernandez <jfernandez@igalia.com>
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Cr-Commit-Position: refs/heads/master@{#577096}
[delete] https://crrev.com/a8bfbc284fd13c6c67eeabdd390b15ff3f7290ec/third_party/WebKit/LayoutTests/external/wpt/css/css-text/overflow-wrap/overflow-wrap-break-word-004.html
[delete] https://crrev.com/a8bfbc284fd13c6c67eeabdd390b15ff3f7290ec/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/reference/word-break-break-all-010-ref.html
[delete] https://crrev.com/a8bfbc284fd13c6c67eeabdd390b15ff3f7290ec/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-010.html
[delete] https://crrev.com/a8bfbc284fd13c6c67eeabdd390b15ff3f7290ec/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-011.html
[modify] https://crrev.com/04c10b73375e9b4886aa67fe484d18b6c2af1fc7/third_party/blink/renderer/core/layout/line/breaking_context_inline_headers.h

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

commit e864e50b8bdc62dd586ceb0a25e6fecd35926765
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Tue Jul 24 14:39:59 2018

Revert "[css-text] A leading white-space should break before handling overflow"

This reverts commit 6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a.

Reason for revert: crbug.com/866109

Original change's description:
> [css-text] A leading white-space should break before handling overflow
> 
> Leading white-spaces are indeed breaking opportunities that should
> prevent, if there are no other css properties forcing it, breaking text
> in the middle of a word when honoring the word-wrap/overflow-wrap CSS
> property.
> 
> We are doing so if the leading white-space sequence is longer than 1
> character, but when we have a single leading white-space, we are missing
> that breaking opportunity and we may lead to cases, like the one
> described in the bug.
> 
> However, this breaking opportunity should be considered together
> with other provided by the word-break CSS property (eg, break-word or
> break-all).
> 
> There is a discussion [1] in the CSS WG github about this issue, which
> provides an interoperability analysis of a few cases where a single
> leading white-space character may produce different results, depending
> on the browser and the combination of line-breaking properties.
> 
> [1] https://github.com/w3c/csswg-drafts/issues/2907
> 
> Bug:  854624 
> Change-Id: I49ec8282e899a32990662c104b48cab04057b909
> Reviewed-on: https://chromium-review.googlesource.com/1130515
> Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
> Reviewed-by: Koji Ishii <kojii@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#575596}

TBR=jfernandez@igalia.com,kojii@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  854624 , 866109
Change-Id: I9ee4cd370dd92b74f9fdc4f42d16638253dd2dee
Reviewed-on: https://chromium-review.googlesource.com/1146360
Reviewed-by: Javier Fernandez <jfernandez@igalia.com>
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Cr-Original-Commit-Position: refs/heads/master@{#577096}(cherry picked from commit 04c10b73375e9b4886aa67fe484d18b6c2af1fc7)
Reviewed-on: https://chromium-review.googlesource.com/1148520
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#39}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[delete] https://crrev.com/076fa3438ad4d2ad9de29ec57ac88afb1eeeb815/third_party/WebKit/LayoutTests/external/wpt/css/css-text/overflow-wrap/overflow-wrap-break-word-004.html
[delete] https://crrev.com/076fa3438ad4d2ad9de29ec57ac88afb1eeeb815/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/reference/word-break-break-all-010-ref.html
[delete] https://crrev.com/076fa3438ad4d2ad9de29ec57ac88afb1eeeb815/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-010.html
[delete] https://crrev.com/076fa3438ad4d2ad9de29ec57ac88afb1eeeb815/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-011.html
[modify] https://crrev.com/e864e50b8bdc62dd586ceb0a25e6fecd35926765/third_party/blink/renderer/core/layout/line/breaking_context_inline_headers.h

I'm back from vacations now, but currently a bit busy with some Grid Layout issues. I'll focus again on this soon, I hope.

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

commit 88e454276c5e763865cc49c3b586be9e070f4ca4
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Wed Oct 03 22:43:04 2018

[css-text] A leading white-space should break before handling overflow

Leading white-spaces are indeed breaking opportunities that should
prevent, if there are no other css properties forcing it, breaking text
in the middle of a word when honoring the word-wrap/overflow-wrap CSS
property.

We are doing so if the leading white-space sequence is longer than 1
character, but when we have a single leading white-space, we are missing
that breaking opportunity and we may lead to cases, like the one
described in the bug.

The root cause of the issue with single leading white-space breaking
opportunities is that the RewindToMidWordBreak expects certain width to
be committed in order to choose opportunities in previous runs if none
of the ones detected by the ICU LazyLineBreakIterator prevents the
overflow.

However, this breaking opportunity should be considered together
with other provided by the word-break CSS property (eg, break-word or
break-all), as it was agreed in the discussion [1] with the CSS WG.

This CL solves the issue identifying the single leading white-space
braking opportunity in a new class field flag, and using it to consider
this opportunity inside the mid-word breaking logic, or prevent to run
it completely in the cases where 'break-all' is not set.

This is basically a reland of 6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a
but with some changes to avoid regressions like the one reported in
issue #866109.

[1] https://github.com/w3c/csswg-drafts/issues/2907

Bug:  854624 
Change-Id: I1cc0f55050d54ea1e76c655cf6b3ef8bcc0b0e2c
Reviewed-on: https://chromium-review.googlesource.com/c/1209745
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596406}
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/overflow-wrap/overflow-wrap-break-word-004.html
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/white-space/pre-wrap-015.html
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/reference/word-break-break-all-010-ref.html
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/reference/word-break-break-all-014-ref.html
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-010.html
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-011.html
[add] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/WebKit/LayoutTests/external/wpt/css/css-text/word-break/word-break-break-all-014.html
[modify] https://crrev.com/88e454276c5e763865cc49c3b586be9e070f4ca4/third_party/blink/renderer/core/layout/line/breaking_context_inline_headers.h

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

commit 50326d70bed86d08b6d1095831267cb37519a57e
Author: Koji Ishii <kojii@chromium.org>
Date: Sun Oct 07 15:01:54 2018

[LayoutNG] Add break opportunity after leading spaces

This patch adds a break opportunity after leading spaces,
when spaces are not collapsed (i.e., pre-wrap).

[CSS Text] says "a soft wrap opportunity exists at the end
of the sequence of preserved spaces." ICU line breaker does
this, but our LazyLineBreakIterator breaks before spaces for
an optimization, and that the break opportunity before
leading spaces is lost.

3 other browsers do this, and Blink recently fixed this in
http://crrev.com/c/1209745.

[CSS Text]: https://drafts.csswg.org/css-text-3/#white-space-phase-1

Bug:  854624 , 636993
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Ie5dfe9cdba291782684ae3f554673c4914a7a178
Reviewed-on: https://chromium-review.googlesource.com/c/1264341
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597462}
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/WebKit/LayoutTests/FlagExpectations/enable-blink-features=LayoutNG
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/blink/renderer/core/layout/ng/inline/ng_inline_item.cc
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/blink/renderer/core/layout/ng/inline/ng_inline_item.h
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/blink/renderer/core/layout/ng/inline/ng_inline_items_builder.cc
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/blink/renderer/core/layout/ng/inline/ng_inline_items_builder.h
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/blink/renderer/core/layout/ng/inline/ng_inline_items_builder_test.cc
[modify] https://crrev.com/50326d70bed86d08b6d1095831267cb37519a57e/third_party/blink/renderer/core/layout/ng/inline/ng_inline_layout_algorithm.cc

This issue is now FIXED.