Open Bug 1535985 Opened 2 years ago Updated 9 days ago

`<datalist>` HTML element should display autocompletion drop-down UI

Categories

(GeckoView :: General, defect, P2)

68 Branch
Unspecified
Android

Tracking

(Webcompat Priority:P2, firefox66 unaffected, firefox67 wontfix, firefox68 wontfix, firefox69 affected)

Webcompat Priority P2
Tracking Status
firefox66 --- unaffected
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- affected

People

(Reporter: phil.mozilla, Assigned: m_kato)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: leave-open)

Attachments

(5 files)

Steps to Reproduce

Observed behavior:

  • No dropdown UI appears to show the children of the <datalist> element.

Expected behavior:

  • Dropdown UI should display matching elements from datalist, as per e.g. Firefox desktop 66:

We should fix this for Fenix M4.

Does the datalist dropdown work in Fennec? Is this a regression in GeckoView?

OS: All → Android
Priority: -- → P1
Whiteboard: [geckoview:fenix:m4]
Version: 64 Branch → 68 Branch

(In reply to Chris Peterson [:cpeterson] from comment #1)

We should fix this for Fenix M4.

Does the datalist dropdown work in Fennec? Is this a regression in GeckoView?

Yes, Fennec shows dropdown list, but GV doesn't.

67=wontfix. Fenix MVP will use GeckoView 68, so we don't need to uplift this fix to 67 Beta.

Hi Makoto, any idea why GV is broken here?

Flags: needinfo?(m_kato)
Flags: needinfo?(m_kato)

So we need to add API to pass the list to browser.

Assignee: nobody → m_kato

This is example implementation for GeckoView example.

Depends on D32987

Fennec's auto complete support is implemented by native UI and desktop's one
is into toolkit with original UI.

Since GeckoView doesn't have own Android's layout, we need to expose APIs to
show and hide suggestion list.

  • onShowAutoCompleteSuggestion to show suggestion list by <datalist>. And when updating value of input element or potion of it, this is also called
  • onHideAutoCompleteSuggestion to hide this list

When selecting item of list, it has callback interface as AutoCompleteCallback.
If application wants to set value, call autoComplete method of this interface.

Flags: needinfo?(snorp)

Fenix MVP is going to release with or without this fix, so it's not technically a Fenix MVP blocker. I'll move this bug to a later Fenix milestone. Makoto says Fennec shows dropdown list, but GV doesn't.

Whiteboard: [geckoview:fenix:m4] → [geckoview:fenix:p2]

I think we should just have something in PromptDelegate to handle <datalist>, similar to what we have for <select>.

Flags: needinfo?(snorp)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #13)

I think we should just have something in PromptDelegate to handle <datalist>, similar to what we have for <select>.

Thanks, I will update it

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9

Priority: P1 → P2
See Also: → 1575444
Rank: 25
Whiteboard: [geckoview:fenix:p2]
Blocks: input-list

Makoto, do you have any idea when the patches for this might land. I notice that they are already a year old. Fenix would like to see this issue resolved.

Flags: needinfo?(m_kato)

(In reply to Emily Toop (:fluffyemily) from comment #16)

Makoto, do you have any idea when the patches for this might land. I notice that they are already a year old. Fenix would like to see this issue resolved.

I will try autofill framework based implementation, but I guess that most autofill service may not support this situation... After implanted, I research services.

Flags: needinfo?(m_kato)

This is an old bug and the implementation no longer fits the latest GV API.
We have two GV APIs serving autofill/autocomplete situations:

  1. The Autofill API for integration with Android's AutofillManager.
  2. The Autocomplete API to expose Gecko autocomplete mechanics.

The datalist options are best exposed via the Autocomplete API, either as a generic string option (combined with form history later) or as a specific new option type.
We should not introduce a new API for it. Rendering the options should be delegated to the app, as with the rest of the autocomplete elements, for consistency (e.g, autocomplete selections are not going to be positioned relative to the input field).

However, this case differs from the other autocomplete situations since the options are provided by content. We might want to have a default implementation for this in GV in the case when the app doesn't implement the delegate.

(In reply to Eugen Sawin [:esawin] from comment #18)

This is an old bug and the implementation no longer fits the latest GV API.
We have two GV APIs serving autofill/autocomplete situations:

  1. The Autofill API for integration with Android's AutofillManager.

View.AUTOFILL_TYPE_LIST won't be supported most autofill services (I cannot find it). When I install custom autofill service using Google's sample + adding View.AUTOFILL_TYPE_LIST dump, autofill service can recognize it.

We should not introduce a new API for it. Rendering the options should be delegated to the app, as with the rest of the autocomplete elements, for consistency (e.g, autocomplete selections are not going to be positioned relative to the input field).

Hmm, we should port custom element version of popup to GV if we don't add an API?

(In reply to Makoto Kato [:m_kato] from comment #21)

We should not introduce a new API for it. Rendering the options should be delegated to the app, as with the rest of the autocomplete elements, for consistency (e.g, autocomplete selections are not going to be positioned relative to the input field).

Hmm, we should port custom element version of popup to GV if we don't add an API?

I've extended the Autocomplete API doc with a selection delegate callback for strings. We should be able to unify all string-based selections like form history and <datalist> with this.

We should not introduce a new API for it. Rendering the options should be delegated to the app, as with the rest of the autocomplete elements, for consistency (e.g, autocomplete selections are not going to be positioned relative to the input field).

Since browser level doesn't scan DOM tree, browser doesn't know suggestions from <datalist> . So I think that we need any API (previous fix, https://phabricator.services.mozilla.com/D32989 has onShowAutoCompleteSuggestion etc for it) to show/hide popup or notify browser of suggestions by <datalist>. from GV. Login data and form history can be fetched from browser's storage (via Firefox sync data) without DOM tree. But <datalist>'s suggestion items are in DOM tree.

Firefox desktop uses custom element to popup items, then popup UX uses XUL element in browser's XUL for popup. But GV doesn't have it, you know. So browser side requires UI implementation like prompt delegate.

I've extended the Autocomplete API doc with a selection delegate callback for strings. We should be able to unify all string-based selections like form history and <datalist> with this.

Gecko's autocomplete code uses index of item to fill item, but it will be OK to set string only. (After implementation is completed, I need some tests for compatibility)

Keywords: leave-open

Android 11+ has new API for InlineSuggestions (https://developer.android.com/reference/android/view/inputmethod/InlineSuggestion), but no sample and no info except to class.

Depends on: 1679248

I don't know whether this is the right place to ask for that, but in the meantime at firefox for android 88.1.2 the datalist bug is still present.
Is there any chance this issue got fixed?

setting webcompat priority to P2.
This is a major UI difference with other browsers and right now it is not very intuitive.
Note that chrome displays a drop-down on focus and Firefox nothing (on desktop).

Webcompat Priority: --- → P2

I just installed the version 90.1.1 build 2015820751 in android 8.1 and try the: https://w3schools.com/html/tryit.asp?filename=tryhtml5_datalist and still nothing happens. I am surprised how this basic feature of HTML5, defined several years ago, does not work in firefox.
Is there any workaround?

You need to log in before you can comment on or make changes to this bug.