Vasili, can you investigate?

dvadym@, isn't it connected to the changes you made to the filling function?

My changes are only in M-62, so they have nothing to do with this.

lindsayw@ Would it be possible to test this issue and if it's reproducible to make a bisect?

Isn't this a dupe of  issue 742554  ? I think it is, but plmk if not. If it is, it will be fixed in M62.

It does not seem like a duplicate of 742554 to me. 

1Password works for me as described in that bug, but the same build of Chrome fails with the WashingtonPost and some other sites. 

@dvadym@chromium.org

Hi Srikanth, 
Can you please see if you are able to repro?

I can reproduce this on iOS10 and 11, this is not a recent regression.
Tested back upto M58 Chrome, and the issue is reproducible on M58 too.
On Safari username and password are filled correctly. Let me know if you need any other information.

I tried it and it doesn't fill via 1Password extension.
I'll take a look.

The washingtonpost.com URL is:
https://subscribe.washingtonpost.com/loginregistration/index.html#/register/group/long?action=login&destination=https:%2F%2Fwww.washingtonpost.com%2F%3Fnid&rememberme=true

There's a bug in how URLs with both # and ? are handle. Fix coming.

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

commit aacddc3f63a145d6939bbd91c362d15275d42070
Author: Peter K. Lee <pkl@chromium.org>
Date: Fri Oct 06 17:06:51 2017

Correctly truncate URLs with both query and fragments

According to RFC 3986 section 3 (Syntax Components) and section 3.5
(Fragment), the fragment can contain a "?" and thus if a URL contains
both # and ?, then the URL can be truncated at the first of the two.

Some web sites with URLs containing both # and ? are not autofilled
with passwords from 3rd party Password Managers because the origin
URL did not match the normalized origin URL.

Bug:  768985 
Change-Id: I56c7a193f864a9ffd5d30883cf1a80da5151e203
Reviewed-on: https://chromium-review.googlesource.com/704229
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Jean-François Geyelin <jif@chromium.org>
Commit-Queue: Peter Lee <pkl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507106}
[modify] https://crrev.com/aacddc3f63a145d6939bbd91c362d15275d42070/ios/web/web_state/js/common_js_unittest.mm
[modify] https://crrev.com/aacddc3f63a145d6939bbd91c362d15275d42070/ios/web/web_state/js/resources/common.js

After the fix in comment 13, username/password are inserted into the form from password extension, however, washingtonpost.com still cannot see them when you tap on "Sign In". Still working on it.

WashingtonPost.com changed their web site again. Now it requires Email address to be filled in first before the Password box is even shown on screen. This breaks password managers (including 1Password) even when using Safari.

There's not much else we can do.