Closed Bug 1745005 Opened 2 years ago Closed 1 year ago

Add showPicker() to <input> elements


(Core :: DOM: Forms, enhancement)

Firefox 97



101 Branch
Tracking Status
firefox101 --- fixed


(Reporter: beaufort.francois, Assigned: evilpie)


(Blocks 2 open bugs)


(Keywords: dev-doc-complete)


(1 file)

Steps to reproduce:

The showPicker() method is a new addition to HTMLInputElement which addresses a very common request from web developers: programmatically showing a picker for controls like date etc.

<input id="dateInput" type="date">
<button onclick="dateInput.showPicker()">Show the date picker</button>


Component: DOM: Core & HTML → DOM: Forms
Blocks: html

Note that WebKit patch does not cover date pickers yet. Only file and color from what I've seen.

Assignee: nobody → evilpies
Ever confirmed: true
Attachment #9270546 - Attachment description: WIP: Bug 1745005 - Add showPicker() to <input> elements → Bug 1745005 - Add showPicker() to <input> elements. r?emilio
Blocks: 1764157
Pushed by
Add showPicker() to <input> elements. r=emilio
Depends on: 1764871

We seem to have some sort of mutex unlocking problem in the GTK code for the file picker. But this could also be some sort of problem with how tsan and GTK interact. I rather suspect we just have to disable the test in that case.

Not really sure about this, but this leak seems to be related to stencil maybe?

Running the test under verify mode exposes an already existing problem. The test failure is unrelated to showPicker.

Flags: needinfo?(evilpies)

The leaks in this try push might be caused by the opened file pickers. Apparently wpt actually uses platform native pickers even when testing. Do we have some way of closing or suppressing these pickers in wpt/test-driver?

Flags: needinfo?(james)

It's not fully clear to me how this is expected to interact with WebDriver in general. Usually for webapp testing the WebDriver API is to "send_keys" a path to a file input and have that become the uploaded path for that control. In this case, for standard WebDriver, it seems like we'd need to have some other way to specify how the automation should respond to the file picker? For WebDriver-BiDi one could obviously emit an event and allow a response.

Anyway, there's currently no support for this in WebDriver / testdriver / etc. It seems to me that we probably want to be setting some pref that disables the native control: what are we doing for other test harnesses, or are we not testing this outside wpt?

Flags: needinfo?(james)

Other tests override the platform native file picker using SpecialPowers.MockFilePicker.

Ah, so that's providing a full mock API. We could add something like that to the TestUtils spec (or to HTML!), but my impression is that this is going to be a thing that developers want and so should end up in WebDriver-BiDi. But that isn't a short term solution.

I'm not sure what the best course of action is in the short term. If it's "just" leaks, we could annotate the leaks as expected in the wpt metadata. If we're not actually managing to test the API correctly, we could also copy the tests into the gecko-specific wpt directory; tests in that directory have access to SpecialPowers so we could make our copy use the mock API to ensure we're not missing coverage in the short term (of course we may end up with missing coverage if the upstream tests are updated, so this isn't an ideal solution).

Pushed by
Add showPicker() to <input> elements. r=emilio
Created web-platform-tests PR for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch

Docs work in MDN:content:15591 adds some additional examples which you can see here.

This seems to indicate that of the "normally supported types" in the spec:

  • Firefox supports input types: color, date, datetime-local, file
  • Firefox does not support types: month, week, time and also does not support datalist or autocomplete options.

Is that correct?

FYI other FF101 docs for this can be tracked in Most of the work has been done in

Flags: needinfo?(evilpies)

Yes sounds correct.

Flags: needinfo?(evilpies)
Blocks: 1767228

Thanks @Tom. I've added to capture that.

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