Throw on showPicker() when the <input> is not mutable

[domenic]

Closes #7767.

• At least two implementers are interested (and none opposed):
  • Gecko (presumably, per opening Interaction between showPicker() and disabled / readonly. #7767)
  • Chromium (Interaction between showPicker() and disabled / readonly. #7767 (comment))
• Tests are written and can be reviewed and commented upon at:
  • Throw on showPicker() when the <input> is not mutable web-platform-tests/wpt#33465
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=939561 (original showPicker issue)
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1745005 (original showPicker issue)
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=239302

(See WHATWG Working Mode: Changes for more details.)

@emilio, could you review this? Also maybe you are thinking of writing the tests? :)

---

/input.html ( diff )

[emilio]

So... I just realized that the spec already accounts for mutability, here: https://html.spec.whatwg.org/#show-the-picker,-if-applicable

So I guess the issue I filed is a Chromium bug. However I think I prefer throwing rather than silently doing nothing for this case, tbh.

Also, I just realized while going through the tests and spec that we do not enforce that the element is rendered, i.e., that you can call input.showPicker() on a detached element, and per spec that should show a picker (somewhere? some pickers do need positioning information).

I think we should consider also throwing on non-rendered elements, what do you think?

[domenic]

Oh, huh. I guess we considered that. Indeed I feel like louder failure is probably better. In this case I should delete the extra check from "show the picker, if applicable".

As for whether it's in the DOM or not, I think in #6909 (comment) we considered this and decided it was OK to show pickers for elements not in the DOM, since that generally works for existing elements. (Especially on mobile.)

[emilio]

Hmm, so color and file at least in Firefox are special because they use the OS window system and aren't positioned relative to the element. But other elements like date / datetime need an element to get positioned, and would feel a bit weird in the middle of nowhere, IMO, since there would be no OS window toolbar, etc.

[beaufortfrancois]

FYI I've started a Chromium CL at https://chromium-review.googlesource.com/c/chromium/src/+/3563070/

[beaufortfrancois]

Chromium has been updated: https://chromiumdash.appspot.com/commit/ee9a0b48b84c1ad754ef263ac8d9288140694c4f
And I've updated web platform tests: web-platform-tests/wpt#33465

[domenic]

In this case I should delete the extra check from "show the picker, if applicable".

I went a different direction. Now "show the picker, if applicable" early-returns on some various error conditions. These are useful for callers like the input activation behavior. But showPicker() checks those same conditions, and throws explicit exceptions.

[annevk]

Maybe mention that this includes an editorial change in the commit message as that was a bit confusing at first.