(Unable to narrow down the range using per-revision bisect,hence providing bisect using old script)

This is a regression issue, broken in M-68 and below is the narrow bisect info:
Good Build : 68.0.3438.0  (Revision : 560884)
Bad Build : 68.0.3439.0 (Revision : 561388)

Narrow bisect URL :
https://chromium.googlesource.com/chromium/src/+log/dc6ff4ef543f5491073f442c1fae7928024da5eb..435dd3259184cedbb03f6f088a51181e6cb22c84

Suspecting : r561365

@Esmael : Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note : 
1. Issue is also reproducible on Linux(14.04 LTS) and will update Mac(10.12.6, 10.13.1, 10.13.5) OS behaviour once build gets available.

This issue is also observed on Mac(10.12.6, 10.13.1, 10.13.5) OS

marking as RBS, please change if required.

I can reproduce on an optimized build only. Seems like something is tripping polymer and/or polymer-css-build to behave incorrectly.

 Issue 846258  has been merged into this issue.

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

commit 1350b7a5002547d277410140ef7444969aadf4c9
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Fri May 25 00:14:15 2018

WebUI: set initial values for padding so there is a default value

When a polyer element style is overridden and there is no explicitly set
style, all the other usages of that polymer element will erroneously
try to override the style with an undefined variable and no default.

Example: |padding-bottom: var(--cr-dialog-body_-_padding-bottom);|

This is only happens when |optimize_webui=true| is set in the build
arguments.

Bug:  846254 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I010c560e80f89c0473722351dce346d481cd3113
Reviewed-on: https://chromium-review.googlesource.com/1072236
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561700}
[modify] https://crrev.com/1350b7a5002547d277410140ef7444969aadf4c9/chrome/browser/resources/md_extensions/options_dialog.html
[modify] https://crrev.com/1350b7a5002547d277410140ef7444969aadf4c9/chrome/browser/resources/print_preview/new/destination_dialog.html
[modify] https://crrev.com/1350b7a5002547d277410140ef7444969aadf4c9/chrome/browser/resources/print_preview/new/search_dialog_css.html
[modify] https://crrev.com/1350b7a5002547d277410140ef7444969aadf4c9/chrome/browser/resources/settings/languages_page/add_languages_dialog.html
[modify] https://crrev.com/1350b7a5002547d277410140ef7444969aadf4c9/ui/webui/resources/cr_elements/cr_dialog/cr_dialog.html

[Auto-generated comment by a script] We noticed that this issue is targeted for M-68; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-68 label, otherwise remove Merge-TBD label. Thanks.

Update : 
Retested above issue in latest Canary build #68.0.3440.0 on Windows(7, 8, 8.1, 10), Mac(10.12.6, 10.13.1, 10.13.5) and Linux 14.04 LTS OS (with build #68.0.3440.2) and the issue is fixed. Language list appears properly in 'Add Languages' dialog. Kindly review an attached screen-cast for the reference.

Thank you..!

Deleted: Canary_behaviour.mp4 762 KB

	Canary_behaviour.mp4 762 KB View Download