... and here's the screenshot of the expected layout

Deleted: Correct card page.png 88.9 KB

	Correct card page.png 88.9 KB View Download

Your page relies on "display: -webkit-box;" and related CSS rules, which is the very old draft flexbox spec from 2009. It looks like this has been removed in 51, or at least broken?

You need to update your content to use the final spec ("display: flex" - you may also have to make other changes to the CSS as it's not just the names that are different, but some of the meanings).

Adding flexbox component - can anyone confirm whether this was intentionally removed/changed in M51, or if this is actually a bug we should fix?

I don't think we should block the M51 rollout on this, though, so updating your app to use the current flexbox spec is the best plan, rather than relying on us changing anything here.

We didn't really intentionally change anything in -webkit-box, and broadly speaking it should work as it used to (we do have some layout tests). But it is not actively maintained and I'd really rather not fix bugs in it.

(removing from the Flexbox component, because it's -webkit-box instead)

I'm happy to investigate this further though -- could you provide the rendered HTML? Maybe we can reproduce in desktop chrome and bisect it.

I get no repro on Nexus 6 with the given WebView version. Here's the HTML and CSS from inside the app, anyway.

Deleted: index.html 3.4 KB

index.html 3.4 KB View Download

Deleted: style.css 150 KB

style.css 150 KB View Download

Yes, I can't reproduce either on my Nexus 6 with that webview version. I also can't reproduce on Windows 7 with 53.0.2756.0 dev-m using the provided files.

Good to hear because the guys responsible for the css/html/javascript have deployed some changes today to fix the error (based on your feedback). So thanks for your help. Consider this as fixed :)

Can you get us a copy of the original, pre-fix HTML/CSS? We'd like to verify what the actual issue is here, in case it may affect other pages/apps.

This CSS rule is the one that broke the view: 
-webkit-user-modify: read-write-plaintext-only;

Until further we will not limit the input fields, but to me it looks like it's a bug?
It's hard to describe what it does, but a lot of padding and other css rules looks affected. 

Please can you give us a copy of the original content that reproduces the bug, not just speculation on a specific rule?

The content is provided by a third party vendor. I will ask them to provide the original content.

I was not able reproduce this issue on Moto X Pure Edition/ M51.0.2704.81(webview).

Note:-
-But I do notice 4 seconds delay in opening the compose active screen when (+) is clicked from "Kort" screen. 
 

Dheenu, you won't be able to reproduce this as the server is now sending different content that doesn't have the bug, see c#9. We're just waiting for a copy of the old content so we can debug this.

Heres the old source code:
https://onedrive.live.com/redir?resid=4FD353D900D811A2!61232&authkey=!AHHuPu15tk94mrA&ithint=file%2czip

Only adjustment to get it working with new webview was to remove line 60 in style.css.

Line 60 is:
>     -webkit-user-modify: read-write-plaintext-only;

You're saying removing that line changed the *layout* of the page?

Yes, that's what I was told by the developers...

I edited that line of CSS *into* the current version of the page in the app and it does indeed completely change the layout, though it doesn't quite reproduce the original bug - the z ordering appears to be different and so some of the page elements are still visible, but some are missing, and a lot of the boxes have moved back to the incorrect locations that I observed them as when originally debugging the broken page, so that does appear to be the cause of the issue.

I took the source code from the archive (which isn't quite directly loadable as it's PHP) and mangled it until I got to this not-really-minimal but single-file repro case (attached). If you load it, it has a broken layout, and using devtools to disable the "-webkit-user-modify: read-write-plaintext-only" rule fixes the layout. This repros fine on desktop and is not android specific :)

Any idea what's going on here, Blink folks? Is this even related to old flexbox at all?

Deleted: repro-618181.html 6.4 KB

repro-618181.html 6.4 KB View Download

Hmm that does not sound flexbox related. Could be due to this:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp?sq=package:chromium&rcl=1466493474&l=250

Looks like tkent touched this code:
https://chromium.googlesource.com/chromium/src/+/73a59b847f8b048bf26d7806bafa403c8f3f95d6%5E%21/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp

I made some changes about read-write-plaintext-only for M51.  read-write-plaintext-only really supports only plaintext now.  In the affected HTML code, read-write-plain-text-only elements contain HTML elements.  It's completely invalid.

tkent: That seems like a significant change, was there an intent to ship or at least a chromestatus entry for that? I don't see one right now...

I didn't think intent-to-ship was necessary because it's just a bug fix.  I should have made a chromestatus entry.  Will do now.

Done: https://www.chromestatus.com/feature/5743696054059008

Thanks!