Issue 638852  has been merged into this issue.

 Issue 732277  has been merged into this issue.

The bug description makes it seem like it's only a display bug, which it isn't.

A simple example is copying style attributes from one element to another.

e1.style.height = window.getComputedStyle(e2).height; // 10.5px

This sets invalid height 10,5px on e1.

Clearly the suggested CL can't be the culprit as it was merged 2 years ago, and this bug is a recent regression in M60.

I don't think it is a recent regression - this has been hanging around for ages. This bug was filed regarding stable in May, and the bug this was split from was filed in August 2016. And the suggested CL definitely adds this behaviour.

The problem only occurs as of M60 for me. Likewise for the person who reported the recently merged duplicate. (Perhaps there are several sub-issues here.)

Perhaps a separate CL made this show up more often? I'm not sure how though.

​I'll run a bisect when I get to it.​

The culprit is between 467223 and 467230.

https://chromium.googlesource.com/chromium/src/+log/65df576fce3007b62084239cc8e37a45aea0368f..74946c37525c8b29f9b7b117c2d092a31b467b4d

I think this is the winner.

https://chromium.googlesource.com/chromium/src/+/368d0cd01a9c13281b2526feb9dc083b27f2af91

Seems unrelated, but modifies lots of code with names like String.

Might also be this.

https://chromium.googlesource.com/chromium/src/+/74946c37525c8b29f9b7b117c2d092a31b467b4d

It has a critical line, that's merely moved from one file to another. Why that would cause a problem I don't know.

setlocale(LC_NUMERIC, "C");

(I think the recent duplicate should be un-merged, as it's a very specific issue.)

I lean towards the commit I mentioned second now. It seems moving the code below in this big refactor might have caused the problem.

https://chromium-review.googlesource.com/c/477393/17/content/app/content_main_runner.cc#b245

 Issue 737701  has been merged into this issue.

Hey Ken - please see comment #11 and #12, it looks like your patch moving the setLocale() call may have caused the renderer not to have its locale set, and so use the system one instead?

Yes it's that change, and the problem is that the new code does not actually result in setlocale() being called in the zygote process. Because renderers are forked from the zygote some time beyond that point, this means that renderers will inherit the browser's locale as well.

I'm bumping the priority of this and will land a fix ASAP.

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

commit 4e92a9428c27532b6d8a8d10a5d554aea795483a
Author: Ken Rockot <rockot@chromium.org>
Date: Thu Jul 06 21:43:03 2017

Service Manager: Fix embedder subprocess init

Service Manager's main() previously assumed that any embedder subprocess
would include a service pipe token on the commandline, and it thus used
this as a signal to perform additional subprocess initialization,
including locale override.

This assumption is incorrect for e.g. the content zygote process.

This CL introduces an explicit embedder API to which the SM delegates
when determining whether or not to perform subprocess initialization.
Content's implementation then indicates that several specific child
process types are subprocesses.

BUG= 720222 
R=jcivelli@chromium.org

Change-Id: I9d5487a503f942b0c7b41462cc9f00d4fab01ef2
Reviewed-on: https://chromium-review.googlesource.com/562080
Reviewed-by: Jay Civelli <jcivelli@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#484749}
[modify] https://crrev.com/4e92a9428c27532b6d8a8d10a5d554aea795483a/content/app/content_service_manager_main_delegate.cc
[modify] https://crrev.com/4e92a9428c27532b6d8a8d10a5d554aea795483a/content/app/content_service_manager_main_delegate.h
[modify] https://crrev.com/4e92a9428c27532b6d8a8d10a5d554aea795483a/services/service_manager/embedder/main.cc
[modify] https://crrev.com/4e92a9428c27532b6d8a8d10a5d554aea795483a/services/service_manager/embedder/main_delegate.cc
[modify] https://crrev.com/4e92a9428c27532b6d8a8d10a5d554aea795483a/services/service_manager/embedder/main_delegate.h

Does this need merging? Or is the regression not on a branch?

Needs a merge to M60.

@pdknsk - thank you very much for your help in bisecting this bug.

Please add appropriate OSs.

Adding Linux + Chrome OS for the locale bug specifically.

Adding Windows since the root cause of this bug (and the fix) also affects Windows in a less significant way.

Other platforms are unaffected.

​Thanks for the fix and thanks ​mikelawther@ for getting the right person
in.

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

commit 96cc1c04f52fd93fb5e467fb1ca0671a32f79922
Author: Ken Rockot <rockot@chromium.org>
Date: Fri Jul 07 20:25:47 2017

Service Manager: Fix embedder subprocess init

Service Manager's main() previously assumed that any embedder subprocess
would include a service pipe token on the commandline, and it thus used
this as a signal to perform additional subprocess initialization,
including locale override.

This assumption is incorrect for e.g. the content zygote process.

This CL introduces an explicit embedder API to which the SM delegates
when determining whether or not to perform subprocess initialization.
Content's implementation then indicates that several specific child
process types are subprocesses.

BUG= 720222 
R=jcivelli@chromium.org
TBR=rockot@chromium.org

(cherry picked from commit 4e92a9428c27532b6d8a8d10a5d554aea795483a)

Change-Id: I9d5487a503f942b0c7b41462cc9f00d4fab01ef2
Reviewed-on: https://chromium-review.googlesource.com/562080
Reviewed-by: Jay Civelli <jcivelli@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#484749}
Reviewed-on: https://chromium-review.googlesource.com/563526
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#546}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/96cc1c04f52fd93fb5e467fb1ca0671a32f79922/content/app/content_service_manager_main_delegate.cc
[modify] https://crrev.com/96cc1c04f52fd93fb5e467fb1ca0671a32f79922/content/app/content_service_manager_main_delegate.h
[modify] https://crrev.com/96cc1c04f52fd93fb5e467fb1ca0671a32f79922/services/service_manager/embedder/main.cc
[modify] https://crrev.com/96cc1c04f52fd93fb5e467fb1ca0671a32f79922/services/service_manager/embedder/main_delegate.cc
[modify] https://crrev.com/96cc1c04f52fd93fb5e467fb1ca0671a32f79922/services/service_manager/embedder/main_delegate.h

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

meade@ Could you please help us with the html file mentioned in comment #0, to verify this fix from TE-Team

Thank You...

You can repro/verify this by using javascript, e.g. open the developer console and run

window.getComputedStyle(document.getElementById('test')).transitionDuration

and check that the result is "0.35s" (if the bug is still present, it would be "0,35s")

Deleted: test.html 249 bytes

test.html 249 bytes View Download

Thanks for the html.
Tested the issue on Ubuntu 14.04 using chrome version 60.0.3112.66 with the below steps

1. Set the LANG variable to de_DE using command "LANG=de_DE.utf8"
2. Opened chrome LANG=fr_FR google-chrome-beta
3. Opened test.html file from comment #1.
4.Execute "window.getComputedStyle(document.getElementById('test')).transitionDuration
" in console
5. Observed the output as "0.35s"

Observed the same behaviour on chrome version 61.0.3143.0 as well.
Please find the attached screen cast and confirm if anything missed here in verifying the issue.

Also please help us to set the language variable on windows to verify this issue.

Thanks,

Deleted: 720222.ogv 8.2 MB

	720222.ogv 8.2 MB View Download

I'm certain this bug has no effect on Windows.

rockot@, I can still reproduce this issue on Mac OS.

Tested using the html provided in Comment#31 on the Chromium rev#486485 (61.0.3157.0) on Mac OS 10.12.5, output displayed is "0,35s".

So to clarify, upon closer inspection I don't see any evidence that this could cause the same issue on Mac. In fact the affected code is not even compiled on Mac.

It's possible that there was a separate regression for locales on Mac, so it might be worth doing another bisect for that.

​> Observed the same behaviour on chrome version 61.0.3143.0 as well.

In that case your tests for ​both that version and 60.0.3112.66 are
invalid, as the fix didn't make it into that version. (I have exact
reproduction steps in one of the merged duplicates.)

https://storage.googleapis.com/chromium-find-releases-static/4e9.html#
4e92a9428c27532b6d8a8d10a5d554aea795483a

I just tried 484749 and can confirm it's fixed in Ubuntu.

 Issue 717216  has been merged into this issue.

Bug didn't close?

I confirm this issue with russian system locale

Use Electron.js ( base Node.js with Chromium 59  )
Mac OS 10.13.2

This was fixed a while ago, but the fix didn't make it into M59. M59 is nearly a year old now.

How long has the bug been fixed? On what version of Chrome. The latest version of electron.js uses Chrome 61, now in beta mode

It's fixed in M61.

Thank you.

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

commit 564d6622552e2a12c165861291a882f168e81f58
Author: Oleg Maximenko <olegmax@yandex-team.ru>
Date: Wed Apr 25 17:39:10 2018

Force C locale on MacOS.

I believe that in old times when this locale reset was introduced (https://codereview.chromium.org/6347045), MacOS was not excluded for some particular reason just Linux was the main target.
Here (https://bugs.chromium.org/p/angleproject/issues/detail?id=2493) is another reason to force C locale on MacOS too.

Bug= 720222 

Change-Id: I1cdc92e0b5561e0659e7b1bac7ec27655a2c73f6
Reviewed-on: https://chromium-review.googlesource.com/1025091
Reviewed-by: Ken Rockot <rockot@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553632}
[modify] https://crrev.com/564d6622552e2a12c165861291a882f168e81f58/services/service_manager/embedder/main.cc

Tested this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 17.10 on the reported version 61.0.3141.7 and the build with fix 68.0.3409.0 as per  issue 737701 (duped in comment #14).

On changing the chrome languages to Portuguese (Brazil), navigating the page https://jsbin.com/tibasolude/1/edit?html,js,output and inspecting the element, cannot find comma instead of point in css values.
Tried changing the system language to Portuguese (Brazil) as well on Ubuntu 17.10 and unable to reproduce the issue.
Attached is the screen cast for reference.

rockot@ Request you to check and help us in verifying the fix on the latest M-68 68.0.3409.0 build.

Thanks...

Deleted: 737701.webm 9.3 MB

	737701.webm 9.3 MB View Download