adobe / react-spectrum

A collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.
https://react-spectrum.adobe.com
Apache License 2.0
12.59k stars 1.09k forks source link

FocusManager.focusNext() Not working properly. #6934

Open RajaTheKing826 opened 3 weeks ago

RajaTheKing826 commented 3 weeks ago

Provide a general summary of the issue here

Im trying to build a date range picker using react aria components. In my usecase i need to show DateInput at trigger place and in dailouge too. But the next focus behaviour on date change is working properly at trigger level, but at popover level the popover getting closed automatically.

๐Ÿค” Expected Behavior?

I should be able to add date input in dialouge too by not closing dialouge on date change.

๐Ÿ˜ฏ Current Behavior

On date change popover getting closed automatically

๐Ÿ’ Possible Solution

No response

๐Ÿ”ฆ Context

No response

๐Ÿ–ฅ๏ธ Steps to Reproduce

https://codesandbox.io/p/sandbox/react-spectrum-range-picker-rgc5c9?file=%2Fsrc%2FDateTimePicker.tsx%3A48%2C12-48%2C21

Peek 2024-08-23 16-37

Version

3.12.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

Ubuntu 22.04

๐Ÿงข Your Company/Team

No response

๐Ÿ•ท Tracking Issue

No response

RajaTheKing826 commented 3 weeks ago

@devongovett @LFDanLu any insights in this?

snowystinger commented 3 weeks ago

We thank you for your patience. We will get to your issue as soon as we are able.

snowystinger commented 2 weeks ago

Probably have to block a bunch of contexts that we send down to all the components inside a date range picker and just create a date range field inside.

For what it's worth, I'm not seeing any issues with Tabbing. Do you have more specific steps to reproduce?

This is more what I'd expect:

<DateRangePicker>
  <Label>Trip dates</Label>
  <Group>
    <DateInput slot="start">
      {(segment) => <DateSegment segment={segment} />}
    </DateInput>
    <span aria-hidden="true">โ€“</span>
    <DateInput slot="end">
      {(segment) => <DateSegment segment={segment} />}
    </DateInput>
    <Button>โ–ผ</Button>
  </Group>
  <Popover>
    <Dialog>
      <BlockVariousContext> // move this wherever needed?
         ... Create a DateRangeField? two DateFields? this way there are no additional popovers and overlay state
         ... Maybe a DateRangePicker that can't be opened?
         ... or does this even need to be an editable area?
      </BlockVariousContext>
      <RangeCalendar>
        <header>
          <Button slot="previous">โ—€</Button>
          <Heading />
          <Button slot="next">โ–ถ</Button>
        </header>
        <CalendarGrid>
          {(date) => <CalendarCell date={date} />}
        </CalendarGrid>
      </RangeCalendar>
    </Dialog>
  </Popover>
</DateRangePicker>
upender7270 commented 2 weeks ago

Can you elaborate on how to block context? and what are the contexts that need to be blocked to make this work as expected?

snowystinger commented 2 weeks ago

Sure, the contexts that are used are listed here https://react-spectrum.adobe.com/react-aria/DateRangePicker.html#custom-children And you clear/block them by creating a new context provider for that context and set its value to null

upender7270 commented 2 weeks ago

Thanks for the quick response, I have tried setting the context to null but still getting the same issue. You can check the implementation here - https://codesandbox.io/p/sandbox/react-spectrum-range-picker-forked-74nls7?file=%2Fsrc%2FDateTimePicker.tsx

RajaTheKing826 commented 2 weeks ago

Sure, the contexts that are used are listed here https://react-spectrum.adobe.com/react-aria/DateRangePicker.html#custom-children And you clear/block them by creating a new context provider for that context and set its value to null

How this is related to context, focus manager should get next focusable element and it should transfer the focus right?

snowystinger commented 2 weeks ago

Again, I'm not really sure what you're referring to. I cannot reproduce your described issue

For what it's worth, I'm not seeing any issues with Tabbing. Do you have more specific steps to reproduce?

As for why the context clearing might help, my understanding was that the popover was closing unexpectedly. If you have something using the overlay state context, such as a second date range picker, then it may be calling set close on that state accidentally.

RajaTheKing826 commented 2 weeks ago

Steps to reproduce,

  1. In that code sandbox output open date range picker dialouge by clicking on chevron icon (trigger).
  2. There youll find a date segment.
  3. Try to enter a complete date that is date, month, year (or any order but all values has to be filled). After entering a valid date in date segment the dialouge will get closed automatically. which is unexpected.

if you're able to enter complete date (date month year) by not closing dialouge please gimme a gif of it.

snowystinger commented 2 weeks ago

https://github.com/user-attachments/assets/ac20b691-8a6a-4cca-be57-a967a896bbda

RajaTheKing826 commented 2 weeks ago

Peek 2024-08-23 16-37

This is the result im getting im using ubuntu Ubuntu 22.04.3 LTS chrome latest version

can you please tell me where you are testing

snowystinger commented 2 weeks ago

Chome 127.0.6533.120 (Official Build) (arm64) On MacOS 14.6.1

RajaTheKing826 commented 2 weeks ago

I've checked it in Chome 127.0.6533.120 (Official Build) (arm64) On MacOS 14.5.0 Still im getting the issue

RajaTheKing826 commented 2 weeks ago

@snowystinger did you fork my codesandbox and did any changes to that or you're just testing in my codesandbox? as im still getting the issue i dont know how its happening and how do you able to enter total year in input at a time means instead of 2,0,2,4 im seeing 2024 directly in single change how its happend?

snowystinger commented 2 weeks ago

Ah, I see, I was using the arrow keys to quickly fill in a date. Trying to type it out causes the popover to close.

RajaTheKing826 commented 1 week ago

@snowystinger do we have any update in this?

snowystinger commented 1 week ago

No, we've not had time to dive into it. The fastest way to get an update on it is to start debugging more on your own. Otherwise, it'll be when we have time and decide it's a priority. Given that this is a pretty unusual use case, I don't think it'll be high on our priorities for quite some time.

Thanks for understanding.