UX: uses native date picker when possible (eg: not safari) (PR #12668)

Note that this is only applied on {{date-input}} and not the old {{date-picker}} for now.

This commit is also slightly modifying admin report dates form to ensure the native picker is correctly used, as a result: it doesn’t auto refresh on date change and fixes a border bug.

GitHub

Code looks OK but tests are failing?

Code looks OK but tests are failing?

Yes sorry I warned penar it wasn’t actually ready for review, I thought I would have the time to finish it this morning but got other things to do.

@pmusaraj ok you can have a look when you have some time :+1:

Should the return value of this helper function be memoized? Otherwise we’re creating an input element every time useNativePicker getter is called, but I don’t think support for date picker changes that often. :stuck_out_tongue_winking_eye:

This is why I used it a property: useNativePicker or am I misunderstanding some behavior here ?

It’s a getter, not a static property, so it’s executed every time you access it. You could change it to a static one:

- get useNativePicker() {
-      return isInputDateSupported();
- },
+ useNativePicker: isInputDateSupported(),

ok cool didnt know it was a difference in this case, dont use get often :+1:

Looks great, and I think Safari support is just around the corner, I tested this with Safari Technology Preview, and it works there too.

Looks great, and I think desktop Safari support is just around the corner, I tested this with Safari Technology Preview, and it works there too.

yes I tried too it should work fine here too indeed