The data from the analysis linked to at https://crbug.com/883633#c26 suggests that the impact is limited. The analysis also provided some example pages, which will be analysed in later updates here.

Case 1:
https://cibnext.icicibank.com/corp/AuthenticationController?FORMSGROUP_ID__=AuthenticationFG&__START_TRAN_FLAG__=Y&FG_BUTTONS__=LOAD&ACTION.LOAD=Y&AuthenticationFG.LOGIN_FLAG=1&BANK_ID=ICI

With old parser, manual fallbacks for saving and filling (from password field) work.

With the new parser ignoring readonly, fallbacks stop working (saving one appears, but fails silently).

With the new parser with readonly, fallbacks work again.

Case 2:
https://velocity.ocbc.com/login.html

With old parser, manual fallbacks for saving and filling (from password field) work.

With the new parser ignoring readonly, fallbacks stop working (saving one appears, but fails silently).

With the new parser with readonly, fallbacks work again.

Case 3:
https://aliorbank.pl/hades/do/LoginAlias
Page has a one-field-per-character set of "password" fields to enter some parts of a PIN. Password manager cannot help here. In no setting (old, new, new+ignore-readonly) there is any unwanted interference, except for a save prompt, which pops-up on reloading the page in all settings.

Case 3:
https://www.youtube.com/live_dashboard -> accounts.google.com
Seems to work fine and the same in all three situations.

Case 4:
https://escritorio11.hinode.com.br/
Seems to work fine and the same in all three situations.

Case 5:
https://www4.bfc.com.ve/IBFCPersonas/
Virtual keyboard, breaks password manager completely in all three situations.

More analysis of case 2:

The password form has one visible and one invisible password field.

The new parser (with considering readonly fields) is better in that it correctly detects the visible password field as "current password" and ignores the invisible one, whereas the old parser thinks that the visible one is "new password", whereas one invisible one is "current password".

This is how the old parser arrives at its conclusion:
(1) Because there are visible fields, ignores the invisible ones, leaving just the visible password in the shortlist.
(2) Because the visible password is readonly, eliminates it as well, emptying the shortlist.
(3) Because there were some passwords initially, but all got shortlisted, defaults to a Plan B: considering all passwords. Among those, the invisible is the first (-> current) and the visible the second (-> new).

The hack in step (3) was not carried over to the new parser on purpose, to keep the design clear and predictable.

The situation of case 1 looks to be the same.

The 5 cases from above were selected arbitrarily among those flagged as concerning readonly fields, but with a bias towards frequently hit pages.

Out of those, in 2 cases, the proposed change in the new parser led to fixing a regression and overall improving over what the old parser did. In the other 3 cases, there was no change.

I just spotted that I had two "case 3". So the statisitics is 2 improvements and 4 no changes.

Also highlighting: There is an independent block against filling readonly fields in PasswordAutofillAgent, so even if the new parser starts using readonly fields, the forms will not start to get filled on load because of that.

The parsing (and hence the result of fill on account select) might get better, though, because of server hints applied.

The current state stays that the new parser accepts disabled fields and not readonly fields (in base heuristics).
I documented this in the design doc [1].

If we want to change this, we should add an appropriate metric (follow the pattern of https://crrev.com/c/1261984), check the impact and then make the change.

I am marking this bug as Available, because I leave the team this week.


[1] https://docs.google.com/document/d/1KxWnt3-Pykz4ut4P1IHxNhn6Ef64v3VMyGobUWyLnDg/edit#heading=h.azxb6xacxjq2