skobes/pdr did we make any changes to text autosizing in 56?

Hmm, it's reminiscent of  issue 666378 , but that fix was merged into M56... no other changes that I'm aware of.

Yeah,  issue 666378  is the only change I'm aware of. It landed in two parts (https://codereview.chromium.org/2514733005, https://codereview.chromium.org/2340553003 but both should be in M56.

Just a guess, but this could be more fallout from supporting the text-size-adjust CSS property in M54 (https://bugs.chromium.org/p/chromium/issues/detail?id=623158) and folks might just now be noticing it?

@jainabhishek, do you have any more data about these issues? A specific site+device that changed would be great.

The screenshots in the zip file seem too pathological to be text-size-adjust fallout.

Deleted: 53972168958.jpg 48.2 KB

	53972168958.jpg 48.2 KB View Download

Devices from play store reviews 
Galaxy J7(2016) (j7xelte)   OS Android 6.0
Galaxy S7 (herolte)         OS Android 6.0
Galaxy Tab A 9.7 (gt510lte) OS Android 6.0
Xperia Z1 Compact (D5503)   OS Android 5.1
L-01F (g2)                  OS Android 5.0


URLs
Wikipedia
Google Search
http://www.visir.is/bandariskur-haestarettardomari-hrosar-fjolmidlum/article/2017170229395
http://forum.canucks.com/
http://m.bbc.com/sport
http://oyechiapas.com/estado/tuxtla-gutierrez/29555-anciano-fue-masacrado-a-machetazos.html
http://reload.dyndns.org:8009/Reload.aspx


More PlayStore reviews : go/vlocd
More Feedback : go/fmhmc

Deleted: 1.jpg 26.6 KB

	1.jpg 26.6 KB View Download

Thanks!

Adding R-V-G because one of those screenshots looks like it might have non-public feedback data.

cc'ing some Android folks

Didn't find anything valuable in logcat or event logs.
Reached out to the user on Forum to get some more details.

Please ask for the full text of the chrome://version/ page from a user who can reproduce this problem.  (In particular, I'm interested in the codes in "Variations:" in case this is due to a Finch experiment I can look up on http://go/finch-debugging, which might explain the repro pattern.)

I deleted the screenshot with PII, reopening this to public in case this helps users chime in with useful repro information.

This seems like some kind of broader layout bug not necessarily related to text autosizing, so changing label.

Reached out to a user on Forum to share experiment IDs
We dont capture experiment data in feedback reports.

It would also be helpful to know if clearing cache or clearing data changes anything.

56.0.2924.87 () 
0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}
Android 6.0.1; SM-G920F Build/MMB29K
JavaScript	V8 5.6.326.50
Mozilla/5.0 (Linux; Android 6.0.1; SM-G920F Build/MMB29K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Mobile Safari/537.36
--use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-pinch --enable-viewport --enable-overlay-scrollbar --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-gpu-process-crash-limit --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --ui-prioritize-in-gpu-process --profiler-timing=0 --prerender-from-omnibox=enabled --enable-dom-distiller --flag-switches-begin --flag-switches-end --enable-instant-extended-api
/data/user/0/com.android.chrome/app_chrome/Default
12af154-7de500df
6a89113b-a7aa8ed
90757ebb-3f4a17df
3095aa95-3f4a17df
8364a5c2-644ef267
236d5d9e-347fc86a
47e5d3db-3d47f4f4
77207729-3d47f4f4
4bf94d2-26e7b859
2a33b90e-e7b70917
ba3f87da-45bda656
3982a4f-771fb42f
58aac55e-3f4a17df
1ce8a192-ca7d8d80
6da04977-464993c3
684d1cdf-51126808
5e3a236d-4113a79e
287f29ba-3f4a17df
7b340ca7-f3ccdcf5
a5e07222-f23d1dea
3e1c19dd-faac447d
93731dca-3f4a17df
6b121ae7-ca7d8d80
f79cb77b-3d47f4f4
b7786474-d93a0620
23a898eb-ca7d8d80
158a87f-3f4a17df
9e46b3e5-3d47f4f4
2182dcae-ca7d8d80
4ea303a6-121b72d9
f66ea88e-4eb6d224
25012ca7-ca7d8d80
867c4c68-3f4a17df
7fc902e8-ca7d8d80
db5efd10-ca7d8d80
f11cb941-e2a41e10
3ac60855-486e2a9c
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-4ad60575
e7e71889-e1cc0f14
dd139bd7-9828aafd
828a5926-ca7d8d80
b0628a6b-ca7d8d80

Deleted: Screenshot_20170301-141031.png 257 KB

	Screenshot_20170301-141031.png 257 KB View Download

The more I wait the more I think this is a showstopper because I now get more and more of my friends telling me Chrome is broken (same symptoms).

We still don't have a local repro.  If there's someone in MTV with the symptoms, I'd like to borrow the device.

Christian & Dominik, can you please help in trying to track this down?
Similarly if the testing team has any way to either repro or bisect it that would be incredibly helpful.

I compared the symbolized Finch hashes to a control device, but I don't see a smoking gun.  It's probably not a Finch experiment causing this.

Finch hashes present only in regression report #15 above:
> ChromeSuggestionsTuning-UnclickedSearchResults
> DataCompressionProxyPromoVisibility-Disabled
> DataReductionProxyUseQuic-Enabled10_NoControl
> DisallowFetchForDocWrittenScriptsInMainFrame-DocumentWriteScriptBlockGroup_20161208_Launch
> MetricsAndCrashSampling-OutOfReportingSample
> NTPBookmarkSuggestions-Enabled1w
> NTPRecentForeignTabs-Control
> NTPSnippets-Enabled3-ZineServerCR
> PasswordGeneration-Disabled
> QUIC-EnabledDisableDiskCache
> TabManagementExperiment-Default
> TranslateRankerLogging-TranslateRankerLoggingControl
> UMA-Population-Restrict-normal
> UMA-Uniformity-Trial-10-Percent-group_04
> UMA-Uniformity-Trial-20-Percent-default
> UpdateMenuItem-EnabledWithDownloadVideosSummary

Finch hashes present only in control device:
< ChromeSuggestionsTuning-IncludeExternalApps
< DataCompressionProxyLoFi-Control_Dogfood
< DataCompressionProxyPromoVisibility-Enabled
< DataReductionProxyUseQuic-Enabled10_NoControl_Dogfood
< DisallowFetchForDocWrittenScriptsInMainFrame-Control_20161208_Launch
< ExternalDataUseObserver-Enabled_Dogfood
< NTPBookmarkSuggestions-Enabled
< NTPRecentForeignTabs-Enabled-ThreeHour
< NTPSnippets-Enabled3-ZineServerFCS
< OfflinePageCache-Enabled_Dogfood
< PageSpeedDemotion-DemotionDisabled
< PasswordGeneration-Enabled
< QUIC-EnabledInitialReceiveWindow1MBJanuary
< TabManagementExperiment-Elderberry_0
< TranslateRankerLogging-TranslateRankerLoggingDefault
< UMA-Population-Restrict-dogfood
< UMA-Uniformity-Trial-10-Percent-group_01
< UMA-Uniformity-Trial-20-Percent-group_02
< UpdateMenuItem-Control

I'm thinking the most likely cause is that the font metrics in a particular system font file is busted, and Chrome started making use of that metrics information in M56.  If finnur@ is hearing a lot of bug reports from local users, that might be because this font file is widespread in Icelandic locale devices.

Assigning to drott@ because he fixed a similar issue  http://crbug.com/637464 

+ amineer@ &  candrada@

hansjulius, are you able to reproduce the bug?

It is curious that hansjulius's screenshot of chrome://version looks quite different from my local one (same chrome version).

56.0.2924.87 () 
0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}
Android 6.0.1; SGP621 Build/23.5.A.1.291
JavaScript	V8 5.6.326.50
Mozilla/5.0 (Linux; Android 6.0.1; SGP621 Build/23.5.A.1.291) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
--top-controls-show-threshold=0.27 --top-controls-hide-threshold=0.17 --enable-pinch --enable-viewport --enable-overlay-scrollbar --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-gpu-process-crash-limit --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --ui-prioritize-in-gpu-process --profiler-timing=0 --prerender-from-omnibox=enabled --enable-dom-distiller --flag-switches-begin --flag-switches-end --enable-instant-extended-api
/data/user/0/com.android.chrome/app_chrome/Default
12af154-7de500df
6a89113b-a7aa8ed
90757ebb-3f4a17df
3095aa95-3f4a17df
8364a5c2-ca7d8d80
236d5d9e-347fc86a
47e5d3db-3d47f4f4
77207729-3d47f4f4
4bf94d2-26e7b859
2a33b90e-e7b70917
ba3f87da-45bda656
3982a4f-771fb42f
58aac55e-3f4a17df
1ce8a192-ca7d8d80
6da04977-464993c3
684d1cdf-51126808
287f29ba-3f4a17df
7b340ca7-3f4a17df
a5e07222-f23d1dea
3e1c19dd-7d64b17b
93731dca-3f4a17df
6b121ae7-ca7d8d80
f79cb77b-3d47f4f4
b7786474-d93a0620
23a898eb-e0e2610f
158a87f-3f4a17df
9e46b3e5-3fc362e4
4ea303a6-ecbb250e
f66ea88e-4eb6d224
25012ca7-ca7d8d80
867c4c68-3f4a17df
7fc902e8-ca7d8d80
db5efd10-ca7d8d80
f11cb941-d6606b56
3ac60855-486e2a9c
4442aae2-e1cc0f14
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e7e71889-4ad60575
dd139bd7-48702b26
828a5926-ca7d8d80
b0628a6b-ca7d8d80

Deleted: tmp_23552-Screenshot_20170301-2238191046837960.png 52.7 KB

	tmp_23552-Screenshot_20170301-2238191046837960.png 52.7 KB View Download

How can we confirm a special font file is in use on Android? I'm not aware of Icelanders installing special fonts -- as far as I know we're just using the stock fonts. In fact, I've never installed any fonts on Android... but then again -- I'm not seeing the problem. :)

pdr: Can you elaborate on what exactly looks different?

Devices

Samsung Galaxy Tab 10.1
Honor7
Sony SGP621 tab

Locale Estonian

"stock" font files are packaged by OEMs and vary by device.  They aren't standardized across Android.

Re #22, the behaviour looks much different from  issue 637464 . Something is going wrong with choice of font size or zoom factor, or both, but I don't think it's a font metrics issue. It's after midnight in Europe here, I can continue looking tomorrow, but in the meantime I am not a good owner for this. kojii@, any other ideas?

Same site firefox vs chrome

Deleted: tmp_23552-Screenshot_20170302-002627326647097.png 979 KB

	tmp_23552-Screenshot_20170302-002627326647097.png 979 KB View Download

Deleted: tmp_23552-Screenshot_20170302-0026591353948942.png 1.2 MB

	tmp_23552-Screenshot_20170302-0026591353948942.png 1.2 MB View Download

Device language for most affected users was Estonian and Icelandic
One play store review suggested changing device language back to english fixed the issue.

In the meanwhile, reached out to few users on play store to share chrome://version details on this bug.

Is there anything we can ask users ?

test team is trying to replicate the issue.

pdr@, skobes@, can we reconsider text-autosizing or text-size-adjust? Something seems to largely scale down the font size. Even if micro-small, but there still seem to be different font sizes on the screenshots for headlines and text in the Delfi screenshots in #31, so some very low multiplier might bring them down here:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/resolver/FontBuilder.cpp?dr&l=312

xHeight from font metrics plays a role in this function as well, but I am not sure it's at fault here, since this would lead to errors for one font that has problems with xHeight.

pdr@, can I assign this to you for now? I am going to bed here in Europe and I can take over tomorrow, but for now it might be worth looking into auto sizing?

A friend of mine reported that switching device language to English "fixed" the issue. But I tried switching _to_ Icelandic and could not repro on my Nexus 6P.

We can pretty much rule out text-size-adjust which is not present on chrome://version.

I think this is related to text autosizing but something changed to cause it to go a little overboard. I will try to get it to repro locally, but I think our best bet is for someone to get a device that it repros on.

The autosizer could do this if there is something broken in the plumbing of text-size-adjust styles or the accessibility setting (prefs::kWebKitFontScaleFactor).

As a speculative fix, we could enforce multiplier >= 1 in TextAutosizer::applyMultiplier, even when text-size-adjust is present.

Testing was able to repro on a couple of devices:  LG 2 / L, Galaxy S7 / M, Xperia M2 / L.

Steps:
1.  Change device language to Icelandic.
2.  Make sure you have old version of Chrome installed, and visit bland.is or visir.is.
3.  Upgrade to M56.
4.  Relaunch Chrome.


Note:
- It's fine with English
- If you already have M56 and then change the device language, the page appears fine.

We'll try to bisect.

 Issue 696313  has been merged into this issue.

Could it be that in clean/new profiles with device language set to Icelandic (and Estonian?) the default value for this prefs::kWebKitFontScaleFactor setting is not populated correctly?

I agree with skobes and drott that kWebKitFontScaleFactor is a likely issue.

In comment 36 Steve asked for clarification about "text-size-adjust which is not present on chrome://version". If you inspect the chrome://version page, the text-size-adjust css string is not present, so the page doesn't use text-size-adjust.

Since it repros without text-size-adjust, kWebKitFontScaleFactor seems less likely.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/TextAutosizer.cpp?type=cs&q=setTextAutosizingMultiplier&l=1176

56.0.2901.0 - first bad build
56.0.2900.3 - last Good build

regression range: https://chromium.googlesource.com/chromium/src/+log/56.0.2900.0..56.0.2901.0?pretty=fuller&n=10000

Couldn't bisect it to exact CL as this issue happens only on upgrade.

It seems related to the determination of default font size for the document.

This url repros the bug:

  data:text/html,<div style="font-size:100%">hello world

But this does not:

  data:text/html,<div style="font-size:16px">hello world

Is sfntly used in this codepath?

These changes were rolled in the range listed above:
https://chromium.googlesource.com/external/github.com/googlei18n/sfntly/+log/1ef790a..e33ba7a

The document font size defaults to "medium", and setting "font-size:medium" is also broken.  Tracing through FontSize::fontSizeForKeyword led me to prefs::kWebKitDefaultFontSize.  I suspect this pref isn't getting set correctly, but I'm not sure where it's supposed to come from.

Summarizing what we know so far:

I have an LG G2 from candrada@ that exhibits the issue consistently if the language has been set to Icelandic since (and during) the installation of Chrome.  Switching language to English makes the problem disappear.

Based on devtools inspection over ADB in the affected state, it appears to affect all text specified in keyword font-size values ("small", "medium", "large", etc.), inherited from the document, or derived from the document with percentages.  It does not affect text specified in px or pt.

I think that rules out TextAutosizer and things applied through it (text-size-adjust, font_scale_factor, device_scale_adjustment), and implicates kWebKitDefaultFontSize pref which is registered here:

https://cs.chromium.org/chromium/src/chrome/browser/ui/prefs/prefs_tab_helper.cc?type=cs&q=kWebKitDefaultFontSize&l=593

IDS_DEFAULT_FONT_SIZE looks like it's defined in various .grd files.  Assigning back to aelias - is there someone who knows more about locale-specific prefs on Android?

Exactly bisected to http://crrev.com/427236 "grit: Reorganize and compact resource_ids."  I suspect this is an older resource ID getting reused across version upgrade with a totally different meaning.  That's really sketchy.

It looks like thestig@ and flackr@ are both OOO for the rest of the week. 
 sdefresne@, do you understand this stuff?  Is this patch even safe to revert or would that risk causing new regressions?

I have a fix up at https://codereview.chromium.org/2724203003

Hi. Reporting as requested by support. Clearing cache itself did not work, all data needed to be deleted. That worked with version 55. With ver.56 chrome crashes. 
56.0.2924.87 (Mark non-secure origins as non-secure, or as "dubious".) Mark non-secure origins as non-secure.
Enables saving pages as MHTML: a single text file containing HTML and all sub-resources.	0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}
MHTML Generation Option	Android 6.0.1; S60 Build/MMB29M
JavaScript	V8 5.6.326.50
Provides experimental options for MHTML file generator.	Mozilla/5.0 (Linux; Android 6.0.1; S60 Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Mobile Safari/537.36
Skips no-store main frame.	--use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-pinch --enable-viewport --enable-overlay-scrollbar --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-gpu-process-crash-limit --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --ui-prioritize-in-gpu-process --profiler-timing=0 --prerender-from-omnibox=enabled --enable-dom-distiller --flag-switches-begin --flag-switches-end --enable-instant-extended-api
/data/user/0/com.android.chrome/app_chrome/Default
12af154-7de500df
6a89113b-a7aa8ed
90757ebb-3f4a17df
3095aa95-3f4a17df
8364a5c2-ca7d8d80
236d5d9e-347fc86a
47e5d3db-3d47f4f4
77207729-3d47f4f4
4bf94d2-26e7b859
2a33b90e-e7b70917
ba3f87da-b4a760c3
3982a4f-771fb42f
58aac55e-3f4a17df
1ce8a192-ca7d8d80
6da04977-464993c3
684d1cdf-51126808
287f29ba-3f4a17df
7b340ca7-3f4a17df
a5e07222-88f98026
3e1c19dd-7d64b17b
93731dca-3f4a17df
9e5c75f1-dc6f1dc2
6b121ae7-ca7d8d80
f79cb77b-3d47f4f4
b7786474-d93a0620
23a898eb-ba11b537
158a87f-3f4a17df
9e46b3e5-3d47f4f4
2182dcae-ca7d8d80
4ea303a6-bf4f4de
25012ca7-ca7d8d80
867c4c68-3f4a17df
7fc902e8-ca7d8d80
db5efd10-ca7d8d80
f11cb941-d6606b56
3ac60855-486e2a9c
4442aae2-4ad60575
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e7e71889-e1cc0f14
dd139bd7-ca7d8d80
828a5926-ca7d8d80
b0628a6b-ca7d8d80

aelias@chromium.org, What is the ETA for this fix to get checked-in? It needs to be baked,verified in canary before we merge to M56.

We have a issue 697679 filed for 'Clear data' not working in M56 when device language is set to Icelandic. And its a regression from M55.

 Issue 697734  has been merged into this issue.

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

commit 0df335a1ea5a09d4860168bc05bbf0d11e802bf5
Author: aelias <aelias@chromium.org>
Date: Thu Mar 02 23:43:51 2017

Don't look up font size preferences on Android.

These are not configurable on Android so we should rely on the default
value on the WebPreferences object.  The use of the unnecessary pref
appears to have caused the value to be reused from an unrelated pref
when the resource ID space changed.

Detailed rationale:
* The default value for the font size preference is coming from a resource.
* That resource isn't defined on Android, only on all desktop platforms.
* This nevertheless used to work for some reason, but that changed with the
resource ID reshuffle http://crrev.com/427236.  Why precisely this used to work
and why it's now broken is not yet fully understood.
* This CL fixes this by removing the pref completely, given that there are no
other sources for the pref anyway, and the WebPreferences struct has its own
default, which matches what's in the GRD file on other platforms.  Because this is
for 56 cherry-pick and the resource ID situation is not yet fully understood, this
seems like a safer fix than, for instance, trying to add a new resource to the
Android GRD file.

BUG= 696364 

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

[modify] https://crrev.com/0df335a1ea5a09d4860168bc05bbf0d11e802bf5/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/0df335a1ea5a09d4860168bc05bbf0d11e802bf5/chrome/browser/prefs/chrome_pref_service_unittest.cc
[modify] https://crrev.com/0df335a1ea5a09d4860168bc05bbf0d11e802bf5/chrome/browser/ui/prefs/prefs_tab_helper.cc

 Issue 692781  has been merged into this issue.

Verified fix from #55 in M58 (58.0.3029.0). Text is now readable after upgrade to this build.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

From the CL description:

""" Because this is
for 56 cherry-pick and the resource ID situation is not yet fully understood, this
seems like a safer fix than, for instance, trying to add a new resource to the
Android GRD file. """

The fact that we still have gaps in understanding this issue worries me a bit. Are we confident that there's no way this can regress anything else?

Yes, I'm confident it won't regress anything else, since my patch just stops using the not-fully-understood subsystem.  I'm less confident that my patch fixes the entire set of regressions introduced by the original patch, there may be some other symptoms (presumably more subtle, given unreported) if unrelated IDs overlap.

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

commit a712551885b2761f50a16fa69395d55406e4b386
Author: Alexandre Elias <aelias@chromium.org>
Date: Fri Mar 03 20:06:19 2017

Don't look up font size preferences on Android.

These are not configurable on Android so we should rely on the default
value on the WebPreferences object.  The use of the unnecessary pref
appears to have caused the value to be reused from an unrelated pref
when the resource ID space changed.

Detailed rationale:
* The default value for the font size preference is coming from a resource.
* That resource isn't defined on Android, only on all desktop platforms.
* This nevertheless used to work for some reason, but that changed with the
resource ID reshuffle http://crrev.com/427236.  Why precisely this used to work
and why it's now broken is not yet fully understood.
* This CL fixes this by removing the pref completely, given that there are no
other sources for the pref anyway, and the WebPreferences struct has its own
default, which matches what's in the GRD file on other platforms.  Because this is
for 56 cherry-pick and the resource ID situation is not yet fully understood, this
seems like a safer fix than, for instance, trying to add a new resource to the
Android GRD file.

BUG= 696364 

Review-Url: https://codereview.chromium.org/2724203003
Cr-Commit-Position: refs/heads/master@{#454437}
(cherry picked from commit 0df335a1ea5a09d4860168bc05bbf0d11e802bf5)

Review-Url: https://codereview.chromium.org/2734513002 .
Cr-Commit-Position: refs/branch-heads/2987@{#756}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/a712551885b2761f50a16fa69395d55406e4b386/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/a712551885b2761f50a16fa69395d55406e4b386/chrome/browser/prefs/chrome_pref_service_unittest.cc
[modify] https://crrev.com/a712551885b2761f50a16fa69395d55406e4b386/chrome/browser/ui/prefs/prefs_tab_helper.cc

Merge approved for M56 branch 2924.

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

commit 83e5576bf385f4bfd919c7f20d641c05ec13be32
Author: Alexandre Elias <aelias@chromium.org>
Date: Fri Mar 03 21:46:11 2017

Don't look up font size preferences on Android.

These are not configurable on Android so we should rely on the default
value on the WebPreferences object.  The use of the unnecessary pref
appears to have caused the value to be reused from an unrelated pref
when the resource ID space changed.

Detailed rationale:
* The default value for the font size preference is coming from a resource.
* That resource isn't defined on Android, only on all desktop platforms.
* This nevertheless used to work for some reason, but that changed with the
resource ID reshuffle http://crrev.com/427236.  Why precisely this used to work
and why it's now broken is not yet fully understood.
* This CL fixes this by removing the pref completely, given that there are no
other sources for the pref anyway, and the WebPreferences struct has its own
default, which matches what's in the GRD file on other platforms.  Because this is
for 56 cherry-pick and the resource ID situation is not yet fully understood, this
seems like a safer fix than, for instance, trying to add a new resource to the
Android GRD file.

BUG= 696364 

Review-Url: https://codereview.chromium.org/2724203003
Cr-Commit-Position: refs/heads/master@{#454437}
(cherry picked from commit 0df335a1ea5a09d4860168bc05bbf0d11e802bf5)

Review-Url: https://codereview.chromium.org/2734573002 .
Cr-Commit-Position: refs/branch-heads/2924@{#939}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/83e5576bf385f4bfd919c7f20d641c05ec13be32/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/83e5576bf385f4bfd919c7f20d641c05ec13be32/chrome/browser/prefs/chrome_pref_service_unittest.cc
[modify] https://crrev.com/83e5576bf385f4bfd919c7f20d641c05ec13be32/chrome/browser/ui/prefs/prefs_tab_helper.cc

Fixed per se, although I'd like thestig@ to look further into the root cause when he gets back, as this may only have fixed the symptom.

 Issue 698829  has been merged into this issue.

Verified fix on upgrade to the Latest M56 and M57 Builds, Works as per expected behavior i.e Text rendering looks good and readable.

Tested Devices: 
Samsung Galaxy S7 Edge (SM-G935F) / MMB29K
Samsung galaxy S7 (SM-G930F) / MMB29K

All - I reported  bug 698829 . I read thru all your comments and want to add input that can help or bring more clarity.

OS language - could be a trigger. My abdroid OS is also not english. I use Tamil as my android OS language. I read that some of you mentioned only icelandic etc. Hence, this info to you.

Device - oneplus (first version 2014)
Mode - no difference. Regular or incognito, same effect on text size for my chrome in this device.
Websites - i faced this issue on many sites but dont want to say that it is the same (affect) for all sites. 

Issues I faced - font size small

Additionally - Beta and developer app wouldnt even install. Is there language issue conflicting with install as well - of these two apps ? 

Deleted: tmp_8614-Screenshot_20170303-212303-655220840.png 93.4 KB

	tmp_8614-Screenshot_20170303-212303-655220840.png 93.4 KB View Download

Deleted: tmp_8614-Screenshot_20170306-150651-1662534935.png 178 KB

	tmp_8614-Screenshot_20170306-150651-1662534935.png 178 KB View Download

Deleted: tmp_8614-Screenshot_20170306-145822-1883244671.png 86.5 KB

	tmp_8614-Screenshot_20170306-145822-1883244671.png 86.5 KB View Download

One of the reporters of this particular problem here - 
As far as I understood the problem has been fixed? Someone mentioned some M56 and M57 versions having the fix. How do I update? I don't speak developer lol, can someone tell me how to get the fix because play store says my chrome is up to date but the problem is still there. 

The issue has been marked as fixed and has gotten verification by QA. But keep in mind: that doesn't mean you'll instantly see the fix on your device; a build still has to be produced and verified and once that passes that test the roll-out the update is then staged (due to the large user-base). Not sure where in the pipeline all of this is, but I would just keep an eye out for the update notification on your device.

 Issue 698849  has been merged into this issue.

Verified fix on Samsung galaxy S7. Font on sites load back well on upgrade. 

Re. Comment #70 - language could be an issue for me aswell - OS lang is Irish - 

Also, don't know if related, but getting this error after downloading and installing Beta

Deleted: Screenshot_20170308-195104.png 123 KB

	Screenshot_20170308-195104.png 123 KB View Download

@deibhinn - This is not related. Chrome might not launch in case it is installed on SD Card but there could be other reasons too.

In case you need help, please reach out to our team on product forum on this link, https://productforums.google.com/forum/#!forum/chrome

Restricting comment access as this bug is fixed.

I'm re-enabling comments here since the fix hasn't been deployed and it'd be great to get user feedback on the fix once it is deployed.

@deibhinn - yes, this is related, the bad code that was in M56 (Chrome Stable) is still in M57 (Chrome Beta).  Our test team confirmed that using Irish / Tamil causes crashes for us too (failed during startup like you see) but things no longer crash once we have applied our fix.

@prmrkelli - as finnur@ noted, the fix is not deployed anywhere yet.  I will post updates to this bug as the fix rolls out; if you wouldn't mind trying to install the update when it is available it would be greatly appreciated.

@everyone - I'm quite sorry that we allowed this regression in the first place and apologize for the inconvenience it has caused.  We are working on releasing the fix as soon as possible, but we have a bit more testing to do to ensure everything is working as anticipated.

Thanks again for all of your feedback which led us to the discovery of this bug as well as the fix.

Any update on this issue?

This issue should be fixed in Chrome 57 and up.

Android Chrome Update small text displays incorrectly
This issue just cropped up this week on my Galaxy S5.  Start after my phone updated to G900VVRU2DQF2 overnight Monday night.  Version of Chrome is 56.0.2924.87.  First saw it on Craigslist, then on Amazon.  I'm in USA using English.  If I close all apps and then change language to Spanish, the websites display correctly.  Problem returned when I change language back to English.  Updating Chrome (to 59) seems to have fixed the problem.