Was this causing a lint error?

It is very strange. When an autofill comes in Chrome it triggers keydown with an event type html.Event

If I don't add this check then I get the following exception:

errors.dart:167 Uncaught Error: Expected a value of type 'KeyboardEvent$', but got one of type 'Event$'
    at Object.throw_ [as throw] (errors.dart:216)
    at Object.castError (errors.dart:64)
    at Object.cast [as as] (operations.dart:444)
    at dart.LegacyType.new.as (types.dart:382)
    at keyboard.dart:39 

Is this necessary? The class is public alread.

We usually use it for a class which is only defined as public for the testing purposes.

My approach is, it is not good practice to define a class public if it can be private. By putting this tag, I'm giving a hint to the future reader: "if it was not the tests, this would have been private"

Suggestion: when there are no fields can we return null instead of creating an empty autofill group?

Why return null? AutofillGroup is the owner of the form. Even if the fields are empty this means form should have only one element.

Shall I rename the AutofillGroup? :) (Any name suggestions, I can say AutofillForm. Or following @yjbanov 's suggestion EngineAutofillForm)

Ah ok that makes sense. I forgot about the form.

Ok, in this case, I still think we don't need a singleElement argument in the constructor. It can simply be a getter:

bool get isSingleElement => items.isEmpty;
// or
bool get isSingleElement => elements.isEmpty;

Thanks for the suggestion. I removed the object property. We also don't need a getter. So far we only needed to use it in the factory constructor.

This method seems to have a non-trivial lifecycle. For example, calling it twice will result in duplicate event subscriptions. Calling it after removeForm will subscribe to detached elements.

I would try to express this functionality with a simpler lifecycle. For example, it seems like the list of elements does not change after the constructor call. Which means that if the list of form fields changes we tear down this class and create a new instance. Perhaps then we could initialize the subscriptions in the constructor once and cancel subscriptions in removeForm?

If a simple lifecycle is not possible, then I would recommend documenting it. As an example, here's another class with a complex lifecycle:

Done. Thanks for the suggestion. I put a lot of thought behind it to address your concern. On the other hand detaching the lifecycle management for this method from rest of all the listener subscriptions seemed more complicated in the end.

I added a more detailed comment. PHAL.

Consider a more useful doc comment. The fact that this class is related to autofill and that it contains "values" is obvious just from the class name and that it has some field in it.

See also: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-useless-documentation

Added more comments on the properties. I don't think we need to change the documentation on top of the class.

Why do we need to prevent default? Consider leaving a comment.

this is only a format change. you can discuss with @mdebbar the keyboard related features. thanks for the suggestions.

@mdebbar let me know if there is any comment you want me to add since I'm around the file :)