This is working correctly in m56, broken by m59. Please use the behavior in Firefox as a guide for correctness.

(Alternatively, *correct* behavior is that the arrow to the left of "Why does the span start here????" points to the beginning of the line below "Spaces and tabs do not collapse". *incorrect* behavior is that it points somewhere in the middle of the line).

I strongly suspect this is a layout issue, but we can wait until bisection to see what turns up.

I only see that it's broken on ToT if I run with --enable-experimental-web-platform-features.

Unable to reproduce the issue on windows 10,Mac 10.12.4 & Ubuntu 14.04 using chrome reported version-59.0.3055.0 ,stable-57.0.2987.133 & Canary-59.0.3067.0 as per the provided html file. Observed that the arrow to the left of "Why does the span start here????" points to the beginning of the line below "Spaces and tabs do not collapse".
Same behaviour observed in Firefox also.
Please find the attached screencast & let us know if we miss anything to reproduce the issue.

Thank you!!

Deleted: 709808-3055.mp4 202 KB

	709808-3055.mp4 202 KB View Download

Did you enable experimental web platform features?
As comment 3 says, display:contents requires that flag.
Attaching my screencast. The colors are not great because it's a gif. What program do you use to record screencasts?

Deleted: screencast.gif 177 KB

	screencast.gif 177 KB View Download

This feature is not shipped, so no need to target a fix for it. Just made it blocking the display:contents issue.

I believe this is another instance of https://groups.google.com/a/chromium.org/forum/#!topic/layout-dev/8ldUMbjFUwU, where we're using the parent layout object style for text layout.

I'm not sure how painful it's going to be to fix it yet.

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

commit fbd1a3402bc3c99f5096f10bdd567f05f1df46b8
Author: Rune Lillesveen <futhark@chromium.org>
Date: Thu Nov 30 12:27:32 2017

Test that display:contents text properties applies to text children.

Bug:  709808 
Change-Id: I8cc58884f64b01d73468231e44f9255d458521bb
Reviewed-on: https://chromium-review.googlesource.com/799932
Reviewed-by: nainar <nainar@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520518}
[modify] https://crrev.com/fbd1a3402bc3c99f5096f10bdd567f05f1df46b8/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/fbd1a3402bc3c99f5096f10bdd567f05f1df46b8/third_party/WebKit/LayoutTests/external/wpt/css/css-display/display-contents-text-inherit-ref.html
[add] https://crrev.com/fbd1a3402bc3c99f5096f10bdd567f05f1df46b8/third_party/WebKit/LayoutTests/external/wpt/css/css-display/display-contents-text-inherit.html

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

commit fc5c3629044888b8d723cc11424879bb883d8d3e
Author: Rune Lillesveen <futhark@chromium.org>
Date: Tue Dec 05 12:13:10 2017

Wrap text child of display:contents in anonymous if necessary.

A text node gets its style from its flat tree parent. The problem is
that our layout code expects the LayoutObject parent to have the same
inherited styles as the text node. That is not the case if a text node
has display:contents ancestors and the display:contents parent does not
have the same inherited styles as the closest ancestor generating a box.

Example:

  <div>
    <div style="display:contents;font-size:50px">Text</div>
  </div>

We're solving this by inserting an anonymous inline between the
LayoutText and its parent LayoutObject. We do not try to merge inline
wrappers for subsequent text nodes, so for:

  <div style="display:contents:color:pink">A<!-- -->B</div>

we create one wrapper for each of A and B, even though one would
suffice.

We attach and detach these wrappers on-demand, so if, for instance, the
inherited computed styles of the display:contents change so that it
matches the computed styles of the LayoutObject parent, we detach the
wrapper as it's no longer needed.

We also currently detach the wrapper when the computed style of the
display:contents and hence the computed style of the wrapper changes. We
could have optimized this through more checking and SetStyle on the
anonymous wrapper.

Bug:  717460 ,  706316 ,  709808 ,  713019 
Change-Id: Ia53b9fe2c0a6067c4600dab49cdf43f23b95b8fa
Tests: see removed lines from TestExpectations.
Reviewed-on: https://chromium-review.googlesource.com/806158
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Robert Hogan <robhogan@gmail.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521673}
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/dom/LayoutTreeBuilder.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/dom/LayoutTreeBuilder.h
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/dom/Text.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/layout/LayoutBlock.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/layout/LayoutInline.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/layout/LayoutObjectTest.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/style/ComputedStyle.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/style/ComputedStyle.h