[date-picker] does not close overlay when clicking today if custom font-size is used

[knoobie]

Description

Title says it all :) It drives me crazy

https://github.com/user-attachments/assets/d046b623-1dd7-41d2-9ed6-72cd4ea4f5ef

Expected outcome

Overlay is closed

Minimal reproducible example

public class GermanDatePicker extends DatePicker {

  private static final DatePickerI18n DATEPICKER_GERMAN = new DatePickerI18n()
    .setWeekdays(List.of("Sonntag", "Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag"))
    .setWeekdaysShort(List.of("So", "Mo", "Di", "Mi", "Do", "Fr", "Sa"))
    .setMonthNames(List.of("Januar", "Februar", "März", "April", "Mai", "Juni", "Juli", "August", "September", "Oktober", "November", "Dezember"))
    .setCancel("Schließen")
    .setToday("Heute")
    .setFirstDayOfWeek(1) 
    .setDateFormats("dd.MM.yyyy", "ddMMyyyy", "yyyy-MM-dd");

  public GermanDatePicker() {
    super();
    setI18n(DATEPICKER_GERMAN);
    setAutoOpen(false); 
    setWeekNumbersVisible(true); 
  }

  public GermanDatePicker(String label) {
    this();
    setLabel(label);
  }
}


add(new GermanDatePicker());

Steps to reproduce

.

Environment

Vaadin version(s): 24.4.10

Browsers

No response

[web-padawan]

Possibly related to #7438, see my comment https://github.com/vaadin/web-components/issues/7438#issuecomment-2132993100. It needs further investigation why the date isn't selected in this specific case but apparently this._scrollToCurrentMonth() is called even though there is no need to scroll.

[knoobie]

Thanks for checking! What I find really strange: it works in the docs https://vaadin.com/docs/latest/components/date-picker so I was wondering if it is related to some of my customizing e.g. i81n or other settings

[DiegoCardoso]

I also copied your snippet into one testing app I have locally and couldn't reproduce the issue.

[knoobie]

That sounds really weird.. I could produce it with the snippet in two apps with Firefox on MacOS. Gonna try it tomorrow with a project from start.vaadin.com to ensure all moving things are gone

Edit: funny note.. just tested one of my apps from my mobile phone with safari.. there it also works.. so it could be a browser specific problem 😕

[knoobie]

I can't create a reproducer in a starter after one hour of trying.. Copied all our styles.. tried to re-create some of the DOM structure.. no luck. We don't have customizing of the date picker styling (except the color) so no idea what is confusing the logic here.

Might be just me.. but why is the logic there to begin with? If people click on "today" they want to use "today" so I would expect that the value is selected and the overlay closed. The scrolling is not really needed IMHO or do I miss an important use-case here? This even forces people to click twice, to scroll to the date and afterwards to close the picker which feels counterintuitive in a fast paced business application.

[yuriy-fix]

We probably won't be able to fix the issue in this particular use-case since we cannot get it reproduced, but we might consider changing the overall behaviour within next major (since it will be behaviour altering) to be "1 click to select Today"

The intention behind the current behaviour is to provide the user with a simple way to return to the current day or month after scrolling away, otherwise, the user would need to do it manually. (or re-open the date-picker)

[yuriy-fix]

Closing the issue in favour of https://github.com/vaadin/web-components/issues/7438

[knoobie]

@web-padawan I think I can reproduce the problem.. it looks like it is related to font sizes..

Adding the following css to a start.vaadin.com project allows me to reproduce the problem on Firefox and Chrome on MacOS

html {
  --lumo-font-size-l: 1.1rem;
}

It works every time when you open the page (without a value selected); click today -> date gets selected but not closed

[web-padawan]

Thanks, confirmed the issue using the web components dev page. I'll reopen this ticket (renamed the one referenced above to be specifically about scrolling into view - as in this case it shouldn't be needed at all).

[web-padawan]

Looks like changing --lumo-font-size-l affects calculating monthScroller.position: it's supposed to return 0 by default if "today" is scrolled into view but instead it returns -0.0014357501795108085 in Chrome and Firefox. Interestingly, in Safari the returned value is significantly smaller: 3.241851231905457e-14 - so the selection works.