This will probably be fixed by adding the rounding in StyleBuilderConverter::ConvertLineWidth() to getComputedStyle()'s getters for border widths:
  if (result > 0.0 && result < 1.0)
    return 1.0;

Have confirmed that this issue was introduced at https://chromium.googlesource.com/chromium/src/+/eb499bd02c68f68b5f74d534a673e920f8e7a5e6

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

commit e87da780e04bf05f5ae863d7fda517ee6c03d534
Author: Jia <jiameng@chromium.org>
Date: Tue Jul 18 04:17:02 2017

Make border width rounding visible to js via getComputedStyle.

CL (https://chromium-review.googlesource.com/c/525536/) moved rounding of border 
widths to the painting stage, hence rounding is no longer visible in js via 
getComputedStyle. This cl makes rounding visible again to users via getComputedStyle.

This cl contains the following changes
* Implemented a ZoomAdjustedPixelValueWithRounding method.
- This method is the same as ZoomAdjustedPixelValue except that it
rounds pixel value to 1 if original value is between 0 and 1.0.
* Changed ComputedStyle for border-[top|right|bottom|left] to use
ZoomAdjustedPixelValueWithRounding so that getComputedStyle will
display rounded pixels for these properties (and also border-width that
is a shorthand of these 4 longhand properties).
* Changed a layout test.

Bug:  737962 
Change-Id: I0656f7ea1212fe32f866d95218995fb3de109e05
Reviewed-on: https://chromium-review.googlesource.com/560917
Commit-Queue: Jia Meng <jiameng@chromium.org>
Reviewed-by: Alan Cutter <alancutter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487384}
[modify] https://crrev.com/e87da780e04bf05f5ae863d7fda517ee6c03d534/third_party/WebKit/LayoutTests/fast/sub-pixel/sub-pixel-border.html
[modify] https://crrev.com/e87da780e04bf05f5ae863d7fda517ee6c03d534/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

@alexclarke, I've put in a cl that fixes this rounding issue when using getComputedStyle. I've verified the behavior from my end, please verify it as well so that we can close the issue.
Thanks.

In my humble opinion, this issue is invalid.  https://www.w3.org/TR/cssom-1/#resolved-values specifies that getComputedStyle() should return the computed value for border widths, not the rounded value.  If anything, the issue is that the return value is "0.390625px" and not "0.4px".

The spec says that getComputedStyle() for properties like padding, etc. returns the used value, and it would make sense to change the spec to also cover border widths.

Thanks for looking into this, the patch does appear to restore previous behaviour.  This is good because it seems a behaviour change wasn't expected with the original patch.

Re #9 you might be right :)

I think commit e87da780e04bf05f5ae863d7fda517ee6c03d534 should be reverted. The original patch caused a behavior change, and that's expected.

Additionally, we're dealing with Blink's inability to accurately represent fraction values here, but that's an old issue. Probably because the value is of type LayoutUnit at some stage, which is a fixed-point data type with only 6 bits reservered for the fractional part.

So: If a border-width of 1.4px reads out as 1.390625px via getComputedStyle(), should 0.4px really become 1px, rather than 0.390625px?

I'll go ahead and revert the fix for this. It should also be reverted on M61.

If the specified width is 0.4px, so is the computed width, and therefore that's what should be returned from getComputedStyle(). Clamping it to 1px is wrong.

Thanks for your comments and also the link to the spec.

It appears the behavior of border width is unclear/undefined. I'm fine to have the patch reverted, but can we please finalize the decision on the spec first? i.e. could we update the spec to document the expected behavior so that it won't cause any confusion in the future?

Thanks.

I don't think the spec is unclear. To quote the spec:

'getComputedStyle() was historically defined to return the "computed value" of an element or pseudo-element. However, the concept of "computed value" changed between revisions of CSS while the implementation of getComputedStyle() had to remain the same for compatibility with deployed scripts. To address this issue this specification introduces the concept of a resolved value.'

So, ideally it should always return the computed value, but in order to stay compatible with old scripts, that won't work. Hence the concept "resolved value", so that properties that need to diverge from "computed value" are allowed to do so. Border*width must have been found to be unproblematic properties in this regard, so using its computed value is fine.

Thanks a lot for clarifying this. 

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

commit 6e2e63240bfae36af4dc2b7f059a9d82b5bf753b
Author: Morten Stenshorne <mstensho@opera.com>
Date: Mon Jul 24 11:43:27 2017

Revert "Make border width rounding visible to js via getComputedStyle."

This reverts commit e87da780e04bf05f5ae863d7fda517ee6c03d534.

Reason for revert: This fix is a spec violation, and the previous behavior was more correct. A slightly inaccurate representation (off by less than 0.02px) is better than clamping it to 1px.

Original change's description:
> Make border width rounding visible to js via getComputedStyle.
> 
> CL (https://chromium-review.googlesource.com/c/525536/) moved rounding of border 
> widths to the painting stage, hence rounding is no longer visible in js via 
> getComputedStyle. This cl makes rounding visible again to users via getComputedStyle.
> 
> This cl contains the following changes
> * Implemented a ZoomAdjustedPixelValueWithRounding method.
> - This method is the same as ZoomAdjustedPixelValue except that it
> rounds pixel value to 1 if original value is between 0 and 1.0.
> * Changed ComputedStyle for border-[top|right|bottom|left] to use
> ZoomAdjustedPixelValueWithRounding so that getComputedStyle will
> display rounded pixels for these properties (and also border-width that
> is a shorthand of these 4 longhand properties).
> * Changed a layout test.
> 
> Bug:  737962 
> Change-Id: I0656f7ea1212fe32f866d95218995fb3de109e05
> Reviewed-on: https://chromium-review.googlesource.com/560917
> Commit-Queue: Jia Meng <jiameng@chromium.org>
> Reviewed-by: Alan Cutter <alancutter@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#487384}

TBR=alancutter@chromium.org,jiameng@chromium.org

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

Bug:  737962 
Change-Id: I03120da255990456614ffc3e0e3180eaa20a566a
Reviewed-on: https://chromium-review.googlesource.com/582608
Reviewed-by: Morten Stenshorne <mstensho@opera.com>
Commit-Queue: Morten Stenshorne <mstensho@opera.com>
Cr-Commit-Position: refs/heads/master@{#488947}
[modify] https://crrev.com/6e2e63240bfae36af4dc2b7f059a9d82b5bf753b/third_party/WebKit/LayoutTests/fast/sub-pixel/sub-pixel-border.html
[modify] https://crrev.com/6e2e63240bfae36af4dc2b7f059a9d82b5bf753b/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

The revert should also be merged to M61, to prevent fluctuation in behavior. It was wrong to clamp it to 1px.

Pls apply appropriate OSs. Thank you.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop)

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

Before we approve merge for revert listed at #16 to M61, could you please confirm this revert looks good in canary and will be a safe merge to M61?

I'm on Linux, so I don't think I can test Canary. But what is there to test in Canary anyway? This is a revert of a recent fix, which was incorrect. This is a safe merge.

Thank you mstensho@.

+pbommana@, would it be possible for you to verify this on Canary?

With latest Chrome Canary i.e., 62.0.3166.0 which has Cl from comment#16 I still see that it prints 0.390625px.

Good, that's expected behavior.

Approving merge to M61 branch 3163 based on comment #22, #24 and #25. Please merge ASAP. Thank you.

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

commit 267d63adc287ad2df3e2e681399942f7649d5e04
Author: Morten Stenshorne <mstensho@opera.com>
Date: Wed Jul 26 15:55:05 2017

Revert "Make border width rounding visible to js via getComputedStyle."

This reverts commit e87da780e04bf05f5ae863d7fda517ee6c03d534.

Reason for revert: This fix is a spec violation, and the previous behavior was more correct. A slightly inaccurate representation (off by less than 0.02px) is better than clamping it to 1px.

Original change's description:
> Make border width rounding visible to js via getComputedStyle.
>
> CL (https://chromium-review.googlesource.com/c/525536/) moved rounding of border
> widths to the painting stage, hence rounding is no longer visible in js via
> getComputedStyle. This cl makes rounding visible again to users via getComputedStyle.
>
> This cl contains the following changes
> * Implemented a ZoomAdjustedPixelValueWithRounding method.
> - This method is the same as ZoomAdjustedPixelValue except that it
> rounds pixel value to 1 if original value is between 0 and 1.0.
> * Changed ComputedStyle for border-[top|right|bottom|left] to use
> ZoomAdjustedPixelValueWithRounding so that getComputedStyle will
> display rounded pixels for these properties (and also border-width that
> is a shorthand of these 4 longhand properties).
> * Changed a layout test.
>
> Bug:  737962 
> Change-Id: I0656f7ea1212fe32f866d95218995fb3de109e05
> Reviewed-on: https://chromium-review.googlesource.com/560917
> Commit-Queue: Jia Meng <jiameng@chromium.org>
> Reviewed-by: Alan Cutter <alancutter@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#487384}

TBR=alancutter@chromium.org, jiameng@chromium.org, mstensho@opera.com


(cherry picked from commit 6e2e63240bfae36af4dc2b7f059a9d82b5bf753b)

Bug:  737962 
Change-Id: I03120da255990456614ffc3e0e3180eaa20a566a
Reviewed-on: https://chromium-review.googlesource.com/582608
Reviewed-by: Morten Stenshorne <mstensho@opera.com>
Commit-Queue: Morten Stenshorne <mstensho@opera.com>
Cr-Original-Commit-Position: refs/heads/master@{#488947}
Reviewed-on: https://chromium-review.googlesource.com/586723
Cr-Commit-Position: refs/branch-heads/3163@{#59}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/267d63adc287ad2df3e2e681399942f7649d5e04/third_party/WebKit/LayoutTests/fast/sub-pixel/sub-pixel-border.html
[modify] https://crrev.com/267d63adc287ad2df3e2e681399942f7649d5e04/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

Thank you.

https://chromium-review.googlesource.com/c/525536/ didn't really break anything. It introduced proper sub-pixel layout of borders.

Closing this report as WontFix, because of all the noise in here.

If the number representation inaccuracy 0.390625px vs 0.4px is an issue, please file a new report. But it should certainly not be 1px.