Unable to reproduce the issue in Mac 10.12.3 by using chrome reported version #56.0.2924.87 and latest canary #58.0.3028.3.

Steps followed to reproduce the issue are as follows:
-----------
1. Loaded the attached HTML.
2. Did not observe Chrome reporting positions at:
    (0,0) (0,9) (15,0) (15,9) (15,18) (30,9) (60,0)
Also did not got the expected result i.e
(0,0) (0,9) (15,0) (15,9) (30,0) (45,0) (60,0)

Attaching screen cast for reference

siulung@ - Could you please provide the expected result screenshot. It will help us in triaging the issue further.

Thanks...!!

Deleted: 698038.mp4 1.1 MB

	698038.mp4 1.1 MB View Download

@krajshree What you see is exactly what I reported. They are "roughly" at those locations because rounding errors do exist due to font and line-height differences, but the essence is a character is roughly 9px wide and 15px high.


After all, what's important is this result
    (-1,0) (-1,9) (14,0) (14,9) (14,18) (29,9) (59,0)
is too different from the "theoretical" result
    (0,0) (0,9) (15,0) (15,9) (30,0) (45,0) (60,0)

What I claim is I can accept 1px variances so only the 2nd last and 3rd last values are truly wrong.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.3 using chrome version 56.0.2924.87 and canary 59.0.3035.0.
This is non regression issue as the issue seen from M40 old builds.
Marking it as Untriaged to get more inputs from dev.

Thanks,

I uploaded the patch for this issue (https://codereview.chromium.org/2763013002/)

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

commit 19d5f8b3d7cd8ba33ba3f2dd331c339384b299dd
Author: wanchang.ryu <wanchang.ryu@lge.com>
Date: Wed Mar 29 07:10:23 2017

Fix incorrect bounding box position for '\n'

absoluteQuadsForRange function generates unrealted empty quads
with even not overlapping InlineTextBox.
This fix considers inclusive InlineTextbox, overlapping InlineTextbox,
and exclusive InlineTextbox cases separately.
Considering exclusive InlineTextbox is still required because non
rendering characters(e.g. whitespace) are missing and to cover if range
offset is only in this area.

BUG= 698038 

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

[add] https://crrev.com/19d5f8b3d7cd8ba33ba3f2dd331c339384b299dd/third_party/WebKit/LayoutTests/fast/dom/Range/getBoundingClientRect-linebreak-character.html
[modify] https://crrev.com/19d5f8b3d7cd8ba33ba3f2dd331c339384b299dd/third_party/WebKit/Source/core/layout/LayoutText.cpp

Is there any good Bug Components for CSSOM?

hayato@,

I just checked the test case provided by the original report and it seems fixed. is there any further work needed?

Ah, I just re-labeled this bug. Let's close this if this seems fixed.