I cannot edit the issue...? Anyway, the field name on the error is "EmployeeGender" (not "MySelectFieldName", I've just put that as an example). And by the way, if I remove the field "EmployeeGender", the same error occurs on the next field "EmployeeTitle".

Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome stable version #60.0.3112.78 and latest canary #62.0.3174.2.

Bisect Information:
=====================
Good build: 57.0.2980.0	 Revision(443474)
Bad Build : 57.0.2981.0	 Revision(443771)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/994437489ea2c9aaf7fac316a90bf4dffeedf7b2..ab7a0ee9d3485c19da8b50af2d1cfc95fd6e4a98

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2628723004

mkwst@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

It looks like code in https://go.geniac.com/fe/app.9330045c072b2207c2a6.js?306a812b45e4fd5dd987 is constructing an HTML string that contains a number of `<select>` elements, but no corresponding `</select>` closing tags. The experiment landed in https://bugs.chromium.org/p/chromium/issues/detail?id=680462 aims to block those submissions, leading to the experience you're having.

You can satisfy this dangling markup mitigation by closing your `<select>` tags explicitly. Is that possible for your application?

(Dropping both priority and regression status: this is behind the experimental web platform features flag, not shipping by default)

Hi! Thanks for the answer.

Well, actually is not under my control... That's an angular-material
component... 🤔

El 2 ago. 2017 14:30, "mk… via monorail" <monorail+v2.189620131@chromium.org>
escribió:

Filed https://github.com/angular/material/issues/10828. :)

#6 - this seems like a pretty weird consequence, though.
If that element was unclosed in the source code, I would understand.
But it was apparently unclosed within innerHTML (I do not think of any other way to create an unclosed <select> dynamically), where <select> will surely be closed when the containing element is closed. Do you really think Chrome should be blocking the form submission in that case?

Were you trying to protect any unclosed <select> case? Even JavaScript generated cases?

Also, note that the angular.element("<select class=\"visuallyhidden\">") is basically creating a document fragment, a <div> within it and puts the string as its inner HTML.
So kind of like -
div.innerHTML = "<select class=\"visuallyhidden\">";

That does not look like a malicious use case or something that should be prevented, it is isolated to a single element, it is the only element in the string...

phistuck@: The parser isn't in a position to distinguish between `innerHTML` usage and parsing an entire document. I'd also push back a bit on the notion that anything you put into `innerHTML` is "safe"; if you accept user-generated content as part of an `innerHTML` call, you're going to have a bad time, even if you prevent direct code execution via CSP or something similar. The risk is certainly _lower_, as the open tag won't eat the rest of the page, it'll only eat the rest of the contents of the `innerHTML`, but it's not nothing.

Given the numbers (https://www.chromestatus.com/metrics/feature/timeline/popularity/1767), I'd prefer not to distinguish `innerHTML` from any other parser-inserted values.

Yeah, I can understand that. It just seems very likely when you are creating a single element using innerHTML, especially in jQuery ($("<select>")). I hope the numbers are not misleading.

The underlying library was fixed. We'll circle back to the consequences once we're closer to actually shipping this flag.