1340477 - Support feature detection on autocomplete attribute

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Matthew N. [:MattN]]

Currently dom.forms.autocomplete.experimental controls:
* whether newer @autocomplete tokens (other than on/off) are valid
* whether .autocomplete is exposed on <select> and soon <textarea>

For the Form Autofill project we will want to stop hiding the field names and elements we support behind the pref.

We may want to keep the unsupported field names not exposed to the web but I'm not sure if other browsers are following that pattern to support feature detection.

See also bug 1109188 which says that Chrome code wants to be able to parse all tokens as defined in the spec regardless of whether we support them for .autocomplete (exposed to the web). This allows to know that we don't need to use heuristics to guess the type of a field which we simply don't support yet.

Comment 1

[John Dai[:jdai]]

Hi Matthew,
I have some questions about user story, I'll list as the following:
1) *"section-*" is Yes. Is that mean we need to provide "section-*" in this Form Autofill MVP? Because we didn't support "section-*" in our code[1].
2) "tel-extension" is Not sure. Is there any update in this field name? If there is no update, should we set it as NO by default?

[1] See also bug 1020496 comment #3

Thanks,
John

Comment 2

[Matthew N. [:MattN]]

Hello,

(In reply to John Dai[:jdai] from comment #1)
> 1) *"section-*" is Yes. Is that mean we need to provide "section-*" in this
> Form Autofill MVP? Because we didn't support "section-*" in our code[1].

Yes I think we should as it allows us to properly handle pages with multiple addresses that aren't shipping+billing. Otherwise a separate <form> must be used to tell us how to handle it but if the author needs all fields submitted at once then that doesn't work. I'm fine with it being a separate bug and lower priority than this one though.

> 2) "tel-extension" is Not sure. Is there any update in this field name? If
> there is no update, should we set it as NO by default?

I think we need to ask UX/Product about this. Juwei/Joe, do we plan to support autofill telephone extension fields e.g. filling a field with "92" if we have "[phone] x92" saved for the MVP?

Comment 3

[John Dai[:jdai]]

(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #2)
> Hello,
> 
> (In reply to John Dai[:jdai] from comment #1)
> > 1) *"section-*" is Yes. Is that mean we need to provide "section-*" in this
> > Form Autofill MVP? Because we didn't support "section-*" in our code[1].
> 
> Yes I think we should as it allows us to properly handle pages with multiple
> addresses that aren't shipping+billing. Otherwise a separate <form> must be
> used to tell us how to handle it but if the author needs all fields
> submitted at once then that doesn't work. I'm fine with it being a separate
> bug and lower priority than this one though.
> 
Filed bug 1347426.

Comment 4

[Juwei Huang[:juwei]]

To me it's necessary. Yet I'll let Joe makes the final call :)

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Any thoughts, Joe? ;)

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

let's make sure we don't scope creep for the MVP.
telephone extension is a nice to have so let's leave it out of MVP. Thanks

Comment 7

[Matthew N. [:MattN]]

(In reply to Joe Cheng [:jcheng] (please needinfo) from comment #6)
> let's make sure we don't scope creep for the MVP.
> telephone extension is a nice to have so let's leave it out of MVP.

It's not a nice to have if it's a required part of your phone number. Users will end up saving it in the one telephone field in their profile as a suffix and then we will fill it into the regular phone field where sites may not allow the extension. So be aware that not supporting this will affect users with extensions.  Also note that Chromium seems to do parsing for extensions but I'm not sure if they properly capture and fill them.

Comment 8

[John Dai[:jdai]]

(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #0)
> Currently dom.forms.autocomplete.experimental controls:
> * whether newer @autocomplete tokens (other than on/off) are valid
> * whether .autocomplete is exposed on <select> and soon <textarea>
> 
> For the Form Autofill project we will want to stop hiding the field names
> and elements we support behind the pref.
> 
> We may want to keep the unsupported field names not exposed to the web but
> I'm not sure if other browsers are following that pattern to support feature
> detection.
> 
After testing Chrome and Safari, it seems that they don't support feature detection[1][2]. Also, feature detection isn't part of specification definition[3]. I'm wondering that should we need to support feature detection? 

[1] http://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/forms/the-form-element/form-autocomplete.html#50-58
[2] http://w3c-test.org/html/semantics/forms/the-form-element/form-autocomplete.html
[3] https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-controls:-the-autocomplete-attribute

Comment 9

[Matthew N. [:MattN]]

(In reply to John Dai[:jdai] from comment #8)
> (In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are
> blocking you) from comment #0)
> > Currently dom.forms.autocomplete.experimental controls:
> > * whether newer @autocomplete tokens (other than on/off) are valid
> > * whether .autocomplete is exposed on <select> and soon <textarea>
> > 
> > For the Form Autofill project we will want to stop hiding the field names
> > and elements we support behind the pref.
> > 
> > We may want to keep the unsupported field names not exposed to the web but
> > I'm not sure if other browsers are following that pattern to support feature
> > detection.
> > 
> After testing Chrome and Safari, it seems that they don't support feature
> detection[1][2].

Chrome doesn't follow the spec in many ways so I suspect not much thought went into their implementation. See https://github.com/w3c/web-platform-tests/pull/5604 which demonstrates that they don't do proper token splitting or case normalization either which are clearly defined in the processing model[4].

If there was no intention to support feature detection then I don't really see why the spec wouldn't just have autocomplete IDL attribute mirror the attribute value.

> Also, feature detection isn't part of specification definition[3]. 

Sure, but it would be hard to define what is required to consider the field name "implemented" so I wouldn't expect it defined in the spec. Most web API specs I've seen don't define how one is allowed to expose partial support for the feature, it's assumed that browsers aren't going to stub APIs just to get points on sites like caniuse.com. I don't understand the value to websites of parsing and returning autocomplete field names that aren't relevant to Firefox e.g. "impp"

> I'm wondering that should we need to support feature detection? 

I can see feature detection being useful for sites to be able to detect if the browser can help fill a field and fallback to custom suggestions otherwise. E.g. In the case of autocomplete="new-password" it would be great if the spec defined that the token should only be exposed if the browser supports password generation. If page JS detects that "new-password" isn't supported then it can fallback to setting autocomplete="off" so that an existing saved password isn't auto-filled into a password creation field, for example. Another less important use case is for sites like caniuse.com to compare the quality of form autofill implementations.

I would like to get the opinion of the DOM owner for this. Peter, what do you think about whether we should pretend to do something useful with autocomplete tokens that won't affect autofill or any other features of Firefox?

[4] https://html.spec.whatwg.org/multipage/forms.html#autofill-processing-model

Comment 10

[John Dai[:jdai]]

 > Chrome doesn't follow the spec in many ways so I suspect not much thought
> went into their implementation. See
> https://github.com/w3c/web-platform-tests/pull/5604 which demonstrates that
> they don't do proper token splitting or case normalization either which are
> clearly defined in the processing model[4].
> 
I tested form-autocomplete.html which was updated a new patch by you[1]. Chrome and Edge don't do proper token splitting in the processing model. However, Safari 10.0.3 (12602.4.8) does proper token splitting. If we want to support feature detection, MDN page will need to update as well since it'll be the only one browser support this feature.

[1] http://w3c-test.org/html/semantics/forms/the-form-element/form-autocomplete.html

Comment 11

[Matthew N. [:MattN]]

We can file bugs with other browsers to ask them to support feature detection too.

Comment 12

[Anne (:annevk)]

FWIW, I think the feature detection approach makes sense. It might make sense to make that more explicit in the standard if we don't expect to ever support all values.

Comment 13

[John Dai[:jdai]]

Attachment: Bug 1340477 - Part1: Keep the unsupported field names not exposed to the web.

Hi Matthew,
Could you give me any feedback make sure I am in the right direction? Thank you.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=acbb23d3776062b6ea9a458fa3d0f63589a4490c&filter-tier=1&group_state=expanded

Comment 14

[John Dai[:jdai]]

Attachment: Bug 1340477 - Part2: Stop hiding the field names and elements we support behind the pref.

Hi Matthew,
Could you give me any feedback make sure I am in the right direction? Thank you.

Comment 15

[John Dai[:jdai]]

(In reply to Anne (:annevk) from comment #12)
> FWIW, I think the feature detection approach makes sense. It might make
> sense to make that more explicit in the standard if we don't expect to ever
> support all values.

Filed spec issue: https://github.com/whatwg/html/issues/2577

Comment 16

[Matthew N. [:MattN]]

Comment on attachment 8860958 [details] [diff] [review]
Bug 1340477 - Part1: Keep the unsupported field names not exposed to the web.

Review of attachment 8860958 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/base/nsContentUtils.cpp
@@ -591,5 @@
>    Preferences::AddBoolVarCache(&sIsFrameTimingPrefEnabled,
>                                 "dom.enable_frame_timing", false);
>  
> -  Preferences::AddBoolVarCache(&sIsExperimentalAutocompleteEnabled,
> -                               "dom.forms.autocomplete.experimental", false);

Nit: this hunk should be in part 2

@@ +938,5 @@
> +  if (!aAttr || aCachedState == eAutocompleteAttrState_Invalid) {
> +    return false;
> +  }
> +
> +  if(aCachedState == eAutocompleteAttrState_Valid) {

Nit: missing space after `if`

@@ +952,5 @@
> +  nsString tokenString = nsDependentAtomString(aAttr->AtomAt(index));
> +  nsAttrValue enumValue;
> +  bool result = enumValue.ParseEnumValue(tokenString,
> +                                         kAutocompleteUnsupportedFieldNameTable,
> +                                         false);

Nit: I think the `result` variable would be more clearly named `unsupported`

Comment 17

[Matthew N. [:MattN]]

Comment on attachment 8860959 [details] [diff] [review]
Bug 1340477 - Part2: Stop hiding the field names and elements we support behind the pref.

Review of attachment 8860959 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks a lot for the patch John. Sorry for the delay but I had to understand all the defines again and I had a work week last week.

::: dom/base/nsContentUtils.cpp
@@ -1093,5 @@
>      category = eAutocompleteCategory_NORMAL;
>    } else { // Check if the last token is of the contact category instead.
> -    // Only allow on/off if experimental @autocomplete values aren't enabled.
> -    if (!sIsExperimentalAutocompleteEnabled) {
> -      return eAutocompleteAttrState_Invalid;

Since we're doing feature detection we still need a pref to hide the supported field names unless form autofill is enabled. The form autofill system add-on can set the pref to true upon installation but otherwise only off/on should work. Maybe "dom.forms.autocomplete.formautofill"?

Comment 18

[John Dai[:jdai]]

(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #17)
> Comment on attachment 8860959 [details] [diff] [review]
> Bug 1340477 - Part2: Stop hiding the field names and elements we support
> behind the pref.
> 
> Review of attachment 8860959 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks a lot for the patch John. Sorry for the delay but I had to understand
> all the defines again and I had a work week last week.
> 
Thanks for your feedback. Do you have any feedbacks/concerns since you want to understand all the defines again?

Comment 19

[Matthew N. [:MattN]]

I understand how they work now and don't have suggestions for the defines.

Comment 20

[John Dai[:jdai]]

Attachment: Bug 1340477 - Part1: Keep the unsupported autocomplete field names not exposed to the web.

- Address comment #16.
- Add more tests.

The reason we need a unsupported field names list is because 
1) If we want to support unsupported fields in the feature, we can easily remove unsupported filed names entries.   
2) Per bug 1109188, getAutocompleteInfo() needs all the parsed results. We can skip unsupported field names filter when using getAutocompleteInfo().

Hi Olli, 
This is a firefox only feature, other browsers don't support this feature[1]. It's because spec didn't mention if there is some fields UA doesn't support what value should return[2]. Currently, we return empty string to user. May I have your review of this patch? Thank you.

[1] Spec issue: https://github.com/whatwg/html/issues/2577
[2] https://html.spec.whatwg.org/multipage/forms.html#autofill

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d0ffdf2a3131fea42bc775f176b73c8ae2cc37e4&filter-tier=1&group_state=expanded

Comment 21

[John Dai[:jdai]]

Attachment: Bug 1340477 - Part2: Rename autocomplete perf to dom.forms.autocomplete.formautofill.

- Address comment #17.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8864407 [details] [diff] [review]
Bug 1340477 - Part1: Keep the unsupported autocomplete field names not exposed to the web.

Why we need unsupported values?
Wouldn't it be simpler to just have the supported values, and if non-supported value is found, return "".
What if we have value which isn't in either supported or unsupported list?
Doesn't nsContentUtils::IsSupportedAutocompleteAttribute behave in that case rather weirdly.

Why nsContentUtils::IsSupportedAutocompleteAttribute doesn't go through all the atoms? only last and one before last

Maybe I'm missing something.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8864408 [details] [diff] [review]
Bug 1340477 - Part2: Rename autocomplete perf to dom.forms.autocomplete.formautofill.

I don't see reason for this, especially since the pref controls experimental, not quite yet ready autocomplete values. And changing the pref name doesn't really fix any issue.

     // Only allow on/off if experimental @autocomplete values aren't enabled.
-    if (!sIsExperimentalAutocompleteEnabled) {
+    if (!sIsAutocompleteEnabled) {
certainly looks wrong. If autocomplete isn't enabled, why on/off are?
At least the variable name needs to hint that it is only about some values,
and that is what the current sIsExperimentalAutocompleteEnabled hints.

Comment 24

[John Dai[:jdai]]

(In reply to Olli Pettay [:smaug] from comment #22)
> Comment on attachment 8864407 [details] [diff] [review]
> Bug 1340477 - Part1: Keep the unsupported autocomplete field names not
> exposed to the web.
> 
> Why we need unsupported values?
Please see comment #9 for more details.

> Wouldn't it be simpler to just have the supported values, and if
> non-supported value is found, return "".
Yes, it's simpler, I'll address them in next patch. The reason I moved to another function is because it's not part of currently spec define.

> What if we have value which isn't in either supported or unsupported list?
If that case, parser will not match anything, it'll return empty string. We have a testcase cover it[1].

[1] https://searchfox.org/mozilla-central/source/dom/html/test/forms/test_input_autocomplete.html

> Doesn't nsContentUtils::IsSupportedAutocompleteAttribute behave in that case
> rather weirdly.
> 
Hmmm...I think I should merge them into parse supported value function. It'll make less weirdly.

> Why nsContentUtils::IsSupportedAutocompleteAttribute doesn't go through all
> the atoms? only last and one before last
> 
It's because all the unsupported list are field names and contact types[2]. There are only first two atoms in the spec.

[2] See user story for more detail. 

> Maybe I'm missing something.
Thanks for valuable questions.

Comment 25

[John Dai[:jdai]]

(In reply to John Dai[:jdai] from comment #24)
> (In reply to Olli Pettay [:smaug] from comment #22)
> > Comment on attachment 8864407 [details] [diff] [review]
> > Bug 1340477 - Part1: Keep the unsupported autocomplete field names not
> > exposed to the web.
> > 
> > Why we need unsupported values?

I would like to explain more clearly. The reason is getAutocompleteInfo() wants to be able to parse all tokens as defined in the spec regardless of whether we support them for .autocomplete (exposed to the web). If we only have a list of supported, we don’t know a value is a valid value but it is an unsupported value. Ex: 
1) user set .autocomplete is “username”, which is a valid value, but unsupported. .autocomplete should return “”, getAutocompleteInfo() should return “username”. If we have a supported list, it can’t return “username” when calling getAutocompleteInfo().
2) user set .autocomplete is “unknown”, which isn’t a invalid value. .autocomplete should return “”, getAutocompleteInfo() should return “”. This is fine with a supported list.

Comment 26

[John Dai[:jdai]]

Hi MattN,
The bug title intends to said that we need a different autocomplete perf to contain all the supported values. Do we really need two perfs, e.g, one is dom.forms.autocomplete.experimental”, another is “dom.forms.autocomplete.formautofill”? I guess we only need one perf, and form autofill system add-on will turn on that perf. Could you clarify with that? Thank you.

Comment 27

[Matthew N. [:MattN]]

Comment on attachment 8864408 [details] [diff] [review]
Bug 1340477 - Part2: Rename autocomplete perf to dom.forms.autocomplete.formautofill.

Review of attachment 8864408 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Olli Pettay [:smaug] from comment #22)
> Why we need unsupported values?

What John says in comment 25 is correct. We need to be able to differentiate between a token we don't yet care about or support vs. a token that isn't valid.

For more context, we are going to flip this new dom.forms.autocomplete.formautofill pref to true in a system add-on soon and start supporting the listed tokens but we don't want to tell sites that we are supporting them (via feature detection with .autocomplete) before that is shipped to everyone since it won't necessarily be tied to a Gecko release.

::: dom/base/nsContentUtils.cpp
@@ +624,5 @@
>  
>    Preferences::AddBoolVarCache(&sIsFrameTimingPrefEnabled,
>                                 "dom.enable_frame_timing", false);
>  
> +  Preferences::AddBoolVarCache(&sIsAutocompleteEnabled,

As smaug said, this doesn't seem like a good variable name since it's not about enabling or disabling @autocomplete, only some autofill-related tokens.

Comment 28

[Matthew N. [:MattN]]

We only need one pref like your patches have.

Comment 29

[Matthew N. [:MattN]]

Attachment: Use case involving autofill with an example

I've attached an example page to try to explain that we don't want to run heuristics involving related text/labels on fields with valid but unsupported @autocomplete because our heuristics could find a nearby string mentioning "first name" and incorrectly think that the prefix field is a first name field. Since the author already told us it's autocomplete="honorific-prefix", there is no reason to guess wrong with heuristics, we should just know not to fill it at all.

Comment 30

[John Dai[:jdai]]

(In reply to John Dai[:jdai] from comment #25)
> (In reply to John Dai[:jdai] from comment #24)
> > (In reply to Olli Pettay [:smaug] from comment #22)
> > > Comment on attachment 8864407 [details] [diff] [review]
> > > Bug 1340477 - Part1: Keep the unsupported autocomplete field names not
> > > exposed to the web.
> > > 
> > > Why we need unsupported values?
> 
> I would like to explain more clearly. The reason is getAutocompleteInfo()
> wants to be able to parse all tokens as defined in the spec regardless of
> whether we support them for .autocomplete (exposed to the web). If we only
> have a list of supported, we don’t know a value is a valid value but it is
> an unsupported value. Ex: 
> 1) user set .autocomplete is “username”, which is a valid value, but
> unsupported. .autocomplete should return “”, getAutocompleteInfo() should
> return “username”. If we have a supported list, it can’t return “username”
> when calling getAutocompleteInfo().
> 2) user set .autocomplete is “unknown”, which isn’t a invalid value.
Correct a typo of this line. s/isn't/is/, "unknown" is a invalid value.

> .autocomplete should return “”, getAutocompleteInfo() should return “”. This
> is fine with a supported list.

Comment 31

[John Dai[:jdai]]

(In reply to Olli Pettay [:smaug] from comment #23)
> Comment on attachment 8864408 [details] [diff] [review]
> Bug 1340477 - Part2: Rename autocomplete perf to
> dom.forms.autocomplete.formautofill.
> 
> I don't see reason for this, especially since the pref controls
> experimental, not quite yet ready autocomplete values. And changing the pref
> name doesn't really fix any issue.
> 
>      // Only allow on/off if experimental @autocomplete values aren't
> enabled.
> -    if (!sIsExperimentalAutocompleteEnabled) {
> +    if (!sIsAutocompleteEnabled) {
> certainly looks wrong. If autocomplete isn't enabled, why on/off are?
> At least the variable name needs to hint that it is only about some values,
> and that is what the current sIsExperimentalAutocompleteEnabled hints.

Move this part to bug 1362290 which is to support non-experimental autocomplete perf.

Comment 32

[John Dai[:jdai]]

Attachment: Bug 1340477 - Support feature detection for autocomplete attribute.

- Address comment #22.

In this patch, the filter unsupported value's logic are in the nsContentUtils::InternalSerializeAutocompleteAttribute function.

Hi Olli,
May I have your review of this patch? Thank you.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=cd2a576fd3ce55033ef3323036b201d2df9962d3&filter-tier=1&group_state=expanded

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

Does the patch now not return unsupported values from getAutocompleteInfo()? Since I'm pretty sure MattN said yesterday that unsupported values should be there.
(but .autocomplete should be "" for them)

Comment 34

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8864767 [details] [diff] [review]
Bug 1340477 - Support feature detection for autocomplete attribute.

Sorry, this is weird stuff.

Comment 35

[John Dai[:jdai]]

(In reply to Olli Pettay [:smaug] from comment #33)
> Does the patch now not return unsupported values from getAutocompleteInfo()?
Returning unsupported values from getAutocompleteInfo() will be covered in bug 1109188. This bug mainly focus on autocomplete attribute.
Do you think we should merge bug 1109188 to this bug?

> Since I'm pretty sure MattN said yesterday that unsupported values should be
> there.
> (but .autocomplete should be "" for them)

Comment 36

[John Dai[:jdai]]

Per discussion with Olli, I'll merge bug 1109188 to this bug.

Comment 38

[John Dai[:jdai]]

Attachment: patch, v1

- Have a unsupported list which is for autocomplete attribute to filter out unsupported fields, and a valid list which is for getAutocompleteInfo() to get all valid values. 
- Separate cache value into two values, one is for @autocomplete, another is for getAutocompleteInfo(). The reason is because we need to consider if getAutocompleteInfo() is valid, but @autocomplete is invalid case. 
- In test_autocompleteinfo.html make sure no matter dom.forms.autocomplete.experimental pref is on or off we should get all valid values. 
- In test_input_autocomplete.html make sure unsupported values should return empty string to user.

HI MattN,
Could you give me feedback of this patch since I covered bug 1109188 in this bug? 
Note that this bug is mainly focus on dom portion, so I didn’t modify LoginManagerContent.jsm. Thank you.

Comment 39

[John Dai[:jdai]]

For more detail of this patch, I leveage nsContentUtils::SerializeAutocompleteAttribute() to support autocomplete attribute and getAutocompleteInfo() by introducing aGrantAllValidValue boolean value. The aGrantAllValidValue is true for getAutocompleteInfo() in order to allow all valid values, and the aGrantAllValidValue is false for autocomplete attribute to only allow supported values. In order to cache parsed value from different lists, I separate cache into two values, one is for autocomplete attribute named mAutocompleteAttrState, another is for getAutocompleteInfo() named mAutocompleteInfoState.

Comment 40

[Matthew N. [:MattN]]

Comment on attachment 8864999 [details] [diff] [review]
patch, v1

Review of attachment 8864999 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks

::: dom/html/test/forms/test_autocompleteinfo.html
@@ +154,5 @@
>  
> +// getAutocompleteInfo() should be able to parse all tokens as defined
> +// in the spec regardless of whether dom.forms.autocomplete.experimental pref
> +// is on or off.
> +add_task(function*() {

Nit: name the task functions so it's easier to see where a failure happens since the task names are included in the logs.

Comment 41

[John Dai[:jdai]]

Attachment: patch, v2

HI Olli,
Could you give me review of this patch since I covered bug 1109188 in this bug? 
Note that this bug is mainly focus on dom portion, so I didn’t modify LoginManagerContent.jsm. Please see comment #38 and comment #39 for more detail. Thank you.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6c9ba34b1a2b079f23493f040a7ad807c3282192&filter-tier=1&group_state=expanded

Comment 42

[John Dai[:jdai]]

Thanks for the review and feedback!

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2332eb92c85e
Support feature detection for autocomplete attribute. r=smaug

Comment 44

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2332eb92c85e

Comment 45

[John Dai[:jdai]]

Since this bug is fixed, we can cancel needinfo request.