Confirmed. Spamming labels to see if anyone has a clue what might be causing this. The character spacing has increased, suggesting it's a metrics thing. I doubt it's actually paint but it could be SVG text layout or general layout.

I don't think it's a Release Block because most text is still legible. But we should figure this out ASAP in the event we get to roll out a new M-57 on Android.

Good build: 57.0.2938.0
Bad build: 57.0.2939.0
Regression range: https://chromium.googlesource.com/chromium/src/+log/57.0.2938.0..57.0.2939.0?pretty=fuller&n=10000

Good commit: 435598
Bad commit: 435599
Culprit CL: https://chromium.googlesource.com/chromium/src/+/6f80957a6a5e7ec792a2f3cd7f06e2a744196d1d

+ govind as this may be on Desktop too.

+ Prudhvi, could you please try to repro on Desktop?

Does repro on Linux. So all platforms.

Revert might be hard. 2 other patches have landed on top. See https://bugs.chromium.org/p/chromium/issues/detail?id=664961

This is likely caused by rounded metrics. (Forcing subpixel-text makes it render slightly better, but still pretty bad, so it's not a full solution it seems.) What happens here I think is that we compute a scale factor and a new font-size using that scale factor - that scaled font-size is < 1 and without subpixel positioning we'll end up rounding font (or glyph) metrics which of course gives completely bogus results for tiny (< 1) font-size. The font code is subtly different depending on platform though, so this should probably be properly checked per platform.
In this particular case, setting "text-rendering: geometricPrecision" no the <svg> should provide a reasonable workaround I think.
As for solutions I think there are essentially two options:

1) Go "all in" (complete) issue 664961 by always using a scale factor of 1 (== don't produce a scaled font face.) I've tried this before, but wasn't entirely happy with the quality of rendering in layout times (sometimes it looks better, sometimes worse.) It should however be fairly easy to get right wrt backporting I think, and would likely even be a step in the right direction. Rendering errors mention previously here is not of the magnitude seen in this bug, but more of a +/-1 pixel position (not unlikely due to the same metrics rounding.)

2) Do the revert of CLs landed in issue 664961. I suspect that the reverts themselves will not be too difficult, but there could be interactions with other fixes.

Using text-rendering: geometricPrecision has a major caveat of much increasing the time taken to draw the map in our case. This is critical as SVG refresh strategy used during pinch&zoom on Android solved last year with will-change (cf.  https://bugs.chromium.org/p/chromium/issues/detail?id=600482 and 
https://docs.google.com/document/d/1f8WS99F9GORWP_m74l_JfsTHgCrHkbEorHYu72D4Xag/edit#) would be impaired. It relies on a quick SVG redraw.

On the other hand, rendering errors shown in the example above are not acceptable by our customers. The map looks crappy and some texts are not rendered (check-out "AGRAFRESH" and "REMOFRESH" labels which have disappeared)

I would therefore advise a revert until a complete fix is available.

Note that the missing text might be due to https://bugs.chromium.org/p/chromium/issues/detail?id=674279

I've reverted everything (w/o major conflicts) from issue 664961, but to no avail. Presumably there's some additional change that prevents layouts from triggering when the zoom happens or something.

Hi,
what would be the next step then ? 
Thank you

I'm currently bisecting (w/ the additional reverts applied at each step) to try and find any additional culprit.

Tentatively marking RB-Stable for M58 given this is a regression affecting users in the field; we can't spin 57 again but I think we should get this fixed in 58 if at all possible.

fs@, schenney@, please let me know (and CC me) if you disagree so we can chat.

I agree with the release block plan. Thanks.

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

commit 7c6520814282912a6c6437e0c68537e11d77a9b6
Author: fs <fs@opera.com>
Date: Thu Apr 06 18:52:25 2017

Revert "Neuter the "screen scale factor" computation for SVG <text>"

This reverts commit 6f80957a6a5e7ec792a2f3cd7f06e2a744196d1d.

Clean revert, but a reference to FrameHost had to be changed to Page, and
an ASSERT was changed to a DCHECK.

BUG= 706880 ,664961

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

[modify] https://crrev.com/7c6520814282912a6c6437e0c68537e11d77a9b6/third_party/WebKit/LayoutTests/platform/mac/svg/custom/masking-clipping-hidpi-expected.txt
[modify] https://crrev.com/7c6520814282912a6c6437e0c68537e11d77a9b6/third_party/WebKit/Source/core/layout/svg/SVGLayoutSupport.cpp
[modify] https://crrev.com/7c6520814282912a6c6437e0c68537e11d77a9b6/third_party/WebKit/Source/core/layout/svg/SVGLayoutSupport.h

A friendly reminder that M58 Stable is launch is coming soon (less than 2 weeks)! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). 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), bhthompson@(ChromeOS), govind@(Desktop)

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

Before we approve merge to M58, could you please confirm revert listed at #16 is baked/verified in Canary and safe to merge to M58?

Verified in 59.0.3065.0 (on Android)

Approving merge to M58 branch 3029 based on comment #21. Please merge ASAP. Thank you.

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

commit 93d2ca20f15362df7dd3e46754dc12a0570728b3
Author: Fredrik Söderquist <fs@opera.com>
Date: Tue Apr 11 07:46:46 2017

Revert "Neuter the "screen scale factor" computation for SVG <text>"

This reverts commit 6f80957a6a5e7ec792a2f3cd7f06e2a744196d1d.

Clean revert, but a reference to FrameHost had to be changed to Page, and
an ASSERT was changed to a DCHECK.

BUG= 706880 ,664961

Review-Url: https://codereview.chromium.org/2805043002
Cr-Commit-Position: refs/heads/master@{#462563}
(cherry picked from commit 7c6520814282912a6c6437e0c68537e11d77a9b6)

Review-Url: https://codereview.chromium.org/2807023004 .
Cr-Commit-Position: refs/branch-heads/3029@{#663}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/93d2ca20f15362df7dd3e46754dc12a0570728b3/third_party/WebKit/LayoutTests/platform/mac/svg/custom/masking-clipping-hidpi-expected.txt
[modify] https://crrev.com/93d2ca20f15362df7dd3e46754dc12a0570728b3/third_party/WebKit/Source/core/layout/svg/SVGLayoutSupport.cpp
[modify] https://crrev.com/93d2ca20f15362df7dd3e46754dc12a0570728b3/third_party/WebKit/Source/core/layout/svg/SVGLayoutSupport.h

Tested the issue on Win-10, Mac 10.12.4 and Ubuntu 14.04 using chrome beta version #58.0.3029.68.

Attached screen shots of different OS.

Following are the steps followed to test the issue.
------------
1. Navigated to sirha-prod.mobile-spot.com and pressed Map.
2. Zoomed-in up to read labels on stands.
3. Observed different behavior in different OS which is as follows:
a. In Win-10, after navigating to the above site and zooming-in up resulted into kind of object images rather rendering proper font as in SVG_text_Chrome_56.png(Comment #0).
b. In Ubuntu 14.04, characters were abnormally spaced.
c. In Mac 10.12.4, characters were complete and accurate as expected in SVG_text_Chrome_56.png(Comment #0)

fs@ - Could you please check the screen shots and please confirm the expected behavior in three OS.

Thanks...!!

Deleted: Font_rendering@Win.JPG 185 KB

	Font_rendering@Win.JPG 185 KB View Download

Deleted: Font_rendering@Mac.png 476 KB

	Font_rendering@Mac.png 476 KB View Download

Deleted: Font_rendering@Linux.png 276 KB

	Font_rendering@Linux.png 276 KB View Download

Yes, this is highly platform dependent, depending on things like if subpixel position is enabled or not (and most likely other factors.) The observed behavior on Windows is tracked by  issue 704893 . I'm not aware of bug for the behavior on Linux, but I think at least part of the issue there is metrics rounding.
Note that the screenshots in c#0 is from Android which is yet another slightly different setup, so comparing before and after on each platform (i.e 58 vs. 56) is really the only relevant comparison.

So you mean, on Android, with the fix, we have exactly the same render as on M56 ?

Based on my testing, yes.

Hi 
we confirm the fix is OK on Android Chrome Beta and Android Webview 58.0.3029.70
Thank you all for your support.