CalendarDatePicker responds to the mouse wheel even when it is not focused

[koustubhmoharir]

Describe the bug

CalendarDatePicker responds to the mouse wheel even when it is not focused. This results in an unexpected change to the date when the user merely intended to scroll the page. It is very likely that the user will not even notice that the date has changed.

To Reproduce

Steps to reproduce the behavior:

1. Go to Avalonia Playground
2. Switch to the CalendarDatePicker in Samples
3. Set a date in one of the pickers and move focus to another control
4. Use the mouse wheel when the mouse pointer is on the picker with a date set but no focus. See that the date changes.

Expected behavior

The mouse wheel event should be ignored.

Environment

• OS: All
• Avalonia-Version: 11.0.7

[timunie]

@koustubhmoharir it's the same as ComboBox haves in WPF iirc. If you don't like it, you need to disable it on your own, for example:

  public MainWindow()
  {
      InitializeComponent();
      MyDatePicker.AddHandler(PointerWheelChangedEvent, MyDatePicker_OnPointerWheelChanged, RoutingStrategies.Tunnel);
  }

  private void MyDatePicker_OnPointerWheelChanged(object? sender, PointerWheelEventArgs e)
  {
      if (sender is CalendarDatePicker {IsKeyboardFocusWithin: false})
      {
          e.Handled = true;
      }
  }

You can also make this a behavior which can be attached to each Picker.

[koustubhmoharir]

@timunie I just checked this. ComboBox (both in Avalonia and in WPF) does not respond to the mouse wheel unless it has focus. It is good to have the relatively simple solution you have provided, but please reconsider changing the default behavior. The current behavior is very much unexpected.

[timunie]

If ComboBox behaves differently I agree it should be considered for 12.0 release. In 11.x timeframe can't be done I believe as it would be a breaking change.

[koustubhmoharir]

It may be a breaking change technically, but it is a severe problem and I don't think anyone would want this behavior.

1) The mouse pointer can come over a DatePicker even if it was not originally over the DatePicker when the user started scrolling. Suddenly the scrolling stops, and the date starts to change. If the user does not notice this, data has been corrupted. Even if the user does notice it, restoring it to the original value may be difficult since the user may not remember it. The user would just have to cancel the whole operation and begin afresh. If the application auto-saves changes, it is even worse. 2) Thinking about this in general, any control that modifies data without being focused is probably a spec violation.

I have implemented the suggested solution as a behavior, so I don't mind a 12.0 timeline. But if the only reason for pushing to 12.0 is that this is considered a breaking change, it should be safe to change it before then.