Please find the log and Video @ http://go/chrome-androidlogs1/7/788137

Could you please any one look into issue.Can't do per-cl bisect due not reproducible on Nexus devices.

Thanks!

I won't have time to investigate this today, leaving for next bugcop.
In the meantime, would it be possible to get a screenrecording with the "show layout borders" setting applied?

gsennton@Uploaded screen record and logs of "show layout borders",please look into @ http://go/chrome-androidlogs1/7/788137

I think the setting we want is the flag:

$ adb shell "echo '_ --show-composited-layer-borders' > /data/local/tmp/webview-command-line"

When I looked at this, it appeared to be that about:blank was drawing at incorrect scale. I don't believe that this would ever be visible without composited layer borders, but it would be good to ensure that there's no potential to racily affect other content and that it doesn't cause a visible difference in the case where the content behind the webview is not white.

Toby, was c#6 meant for a different bug? This bug isn't about composited layer borders, but issue 787980 is.

Here are some screenshots (with the good build and bad build). It's pretty obvious that the big issue here is that the fonts and layouts change from one version to another (this reminds me of http://b/70151530).

I decided to test this on 2 font size settings: the smallest and the biggest. Observations:

 * quora-good-webview-small-font looks basically identical to quora-good-webview-big-font. System font does *not* affect webview
 * quora-bad-webview-small-font looks *super* different from quora-bad-webview-big-font

Looks like a real bug.

Deleted: quora-good-webview-small-font.png 263 KB

	quora-good-webview-small-font.png 263 KB View Download

Deleted: quora-bad-webview-small-font.png 256 KB

	quora-bad-webview-small-font.png 256 KB View Download

Deleted: quora-bad-webview-big-font.png 280 KB

	quora-bad-webview-big-font.png 280 KB View Download

Deleted: quora-good-webview-big-font.png 265 KB

	quora-good-webview-big-font.png 265 KB View Download

Also, this might be our first M63 regression which is *not* PlzNavigate. Issue still repros even with --disable-browser-side-navigation.

Heads up to anyone trying to repro on a DCHECK build: Quora sets bad cookies, hitting the dcheck in  issue 779887 . Need to remove those dchecks before trying to repro (of course, this is unrelated to the underlying bug).

So far the best guess I have is bfe88542d3e3fd92c64c281207b46f13ab4a2513, so I'll CC jaebaek@chromium.org. Any chance your CL could play a part here--does it take system font settings into account anywhere?

ntfschr@, I am not sure, but I don't think the bug is from the CL. Basically, the CL has impact only when --use-zoom-for-dsf is enabled. If the flag is disabled, the CL does not change any behavior. Currently, the flag is disabled by default and there is no way to turn it on in Android WebView.

By using chrome://inspect, I found that the element size is different in different version of WebViews.

M63 (bad build) with largest font size -> element size 140 * 243.594
M61 (good build) with largest font size -> element size 140 * 244

More specifically, I think the "people plus" icon near "Follow | xx.xk" caused this issue. By changing the font size, the icon is showing extra bit near the bottom if we take a closer look. I also checked that "0.594" is from this part.


battun@, this is repro with Nexus device, you need to go to settings -> Display -> Font size then choose the largest one. Could you please do a per-CL bisect with this setting? Thanks! 

Whoops, I forgot to test on Nexus--makes sense that it would repro across all devices, good catch Shimi.

Yeah, to reiterate, the bug is not "tile borders are broken." The real bug is "WebView renders things differently for different system font sizes."

So for each build, you'll need to try the largest and smallest font settings on the device (kill & restart the app after you change the font size). A good build means the app looks the same with either font setting. A bad build means the app looks different.

Thanks, all!

battun@,
as per #13, please do bisect. thanks!

I don't see anything secret here, so I'm going to open this up and direct followers of https://b.corp.google.com/issues/70151530 over here.

Also, removing jaebaek@ since his CL doesn't appear to be the culprit so far.

Per-CL bisect information:
Good commit:501156
Bad commit:501157

Suspect CL:
https://chromium.googlesource.com/chromium/src/+/707023d380f9c090b21bce9d0f4cb502cce2858a


chrishtr@  Might be it looks like this issue is related to your change. please look into once, if its not related to your change please reassign back to me. 

Thansk!

battun@ please re-check the bisect. I locally reverted 707023d380f9c090b21bce9d0f4cb502cce2858a and it didn't fix the problem.

chrishtr@ please correct me if I'm mistaken and this is indeed your bug.

I also tested on the Quora web app, which appears to have the same UI, and
could not reproduce.

I don't think this pertains to the web app. Android WebView appears to be confused about how to size-up some elements. It should use the sizes specified in the CSS, but now it sometimes computes something based on the system-wide font setting.

ntfschr@ I have tried multiple times per-cl bisect as per #13 but, it's pointing same Suspect CL as i mentioned in #17.

Thanks!

chrishtr@ could you double-check if your CL is affected by the Android system font (maybe I was wrong in #18)?

Essentially, android system font size should not affect layouts in WebView. I've found that quora is the best app to repro this (most parts always render the same, but sections which resemble "discover new people" tend to show the bug).

You can find the setting at:

Settings > Display > Font size > (toggle between "small" and "largest") (Make sure to kill & restart the app after toggling the setting)

If your Cl doesn't cause this, please pass back.

We just got pinged on b/72113267. Any update?

Hoping to make progress on this next week.

 Issue 816509  has been merged into this issue.

I don't think there is a bug in Chrome. The error is in the app's HTML.
I installed a custom webview, then loaded the quora app, and inspected its
webview. Each of these "follow" elements that are clipped have
overflow:hidden, and is sized too small to not clip the text.

DevTools also agrees, indicating that the <div>'s clip bounds don't include
the full size of the text. Removing overflow:hidden from the element also
"fixes" the bug.

That makes sense. However, why does the page's font size change based on the Android system font size? That's the unanswered question (and it's a behavior change that was introduced in that bisect range).

http://b/72113267 and http://b/70151530 are examples where apps claim to be *unable* to specify consistent font size, because it always varies according to the device's system font size. That's a poor developer experience, and I don't think it is working-as-intended (if I'm wrong, please explain and re-close). If these really are bad apps, then let's talk with the developers of the 1P apps ( issue 816509 ) and explain how to fix their HTML.

I don't know, but it was not my CL.

(Note that Chrome itself sets font size as a function of both the user's browser
settings and what the developer desires.)

Bo?

It seems like we *should* be changing font sizes based on the system font size, and if we previously weren't doing so, then that's a bug. Pages probably *shouldn't* be able to prevent this, since font size can be used for accessibility..

Nate, why are you assuming that this is bad? :)

http://b/70151530 was an example of an app which couldn't get a consistent UX because of the font changes. I guess it's ok to say "bad HTML/CSS", since they worked around the issue by changing their web site.

At this point, the behavior has changed for the past 2 releases, and only a handful of apps appear broken. Not enough impact to merit fixing?

All web apps loaded in the browser need to account for the possibility of
browser zoom changing their font size, and respond accordingly. It does seem
reasonable to expect this of apps with webviews, but maybe there should be
an override?