ILIAS icon indicating copy to clipboard operation
ILIAS copied to clipboard
verified publisher icon ILIAS-eLearning

10/UI/Button/month Firefox fallback 43178

Open catenglaender opened this issue 7 months ago • 1 comments

https://mantis.ilias.de/view.php?id=43178

Issue

The month button in Firefox and Safari on desktop has no fancy month/year picker dropdown and shows a very confusing yyyy-mm string.

image

Change

The javascript setting up the EventListener, now also renders a fallback version on init for the browsers that do not have a user-friendly month picker:

month-picker

  • A flicker from the ugly, unwanted initial render to the fallback version is something we have to live with for now.
  • Firefox is recognized because it accepts any strings in the input. A browser with a good month input only accepts yyyy-mm strings
  • Safari on desktop technically has a month input, but it's also ugly and unusable so we check the user agent for Safari - but excluding iPhones and iPads which have a good month picker.
  • The fallback hides the original input and creates a month select dropdown and a year text input (not a number input so we can use html5 pattern validation and the very accessible invalid/valid mechanisms)
  • Styling is minimal on purpose as this is only a temporary solution.
  • The month select input fetches the names of the months from the user's client using DateTimeFormat, so they are localized to the user's OS, but might not be identical to the language selected in ILIAS
  • The year input uses html5 validation. Only numbers, two-digits or four-digits are valid. Two-digit numbers e.g. 24 are converted to four-digit years e.g. 2024.
  • Change fires the same event the original input would fire.
  • Note that rather than having another component modify the input using javascript value re-assignment, it's better to destroy the whole thing and fetch a new month button from the server - which is what the calendar views and sidebar block calendar do. Otherwise original input and fallback could go out of sync. I gave up syncing them because the original input with display: none; on it cannot listen to events and does not take value assignments. There are workarounds, but I didn't want to make it more complex than it has to be. Let me know if you want me to make this more fool-proof.

catenglaender avatar May 28 '25 13:05 catenglaender

Hi @thibsy and @Amstutz,

could you please look into this?

Kind regards!

klees avatar Jun 05 '25 12:06 klees

Hi @thibsy,

thanks for your input! Good questions that I also had to face during implementation.

In the end, I came to the perspective that we are not falling back because it's Firefox, but when there is no month picker shadow DOM (specifically one with input validation) being served. Firefox on some mobile devices for example serves the phone's month picker, so it shouldn't trigger the fallback despite being technically a Firefox User Agent. And the other great thing: If any browser or OS has or adds a month picker it will stop using the fallback. It feels to me like this is treating the actual problem rather than a correlation.

However, then I noticed that weird implementation of Desktop Safari... but at least that is one manual exception written in instead of many more that I cannot even test.

@klees and I deliberately decided against a solution served by php as this is only a hopefully temporary band aid and the php/html side is fully done and future proof. The responsibility to render a good month picker is now on the client and we stepped in on the client side, when the client doesn't do it.

In other news, there is some activity around the time and date picker in the Firefox community, so maybe this also leads to work being done on the other sibling inputs.

All the best :smile:

catenglaender avatar Jul 10 '25 14:07 catenglaender