`crossFrame={false}` has cross-browser Safari issues about react-focus-lock HOT 7 CLOSED

Released as v2.9.5.

Change is not yet propagated to https://github.com/theKashey/react-focus-on, please help me understand theKashey/react-focus-on#74 (comment) first

from react-focus-lock.

bug confirmed 😭

from react-focus-lock.

Thanks for the quick repro Anton!

Not sure if this is helpful or not, but @tkajtoch and I were testing crossFrame in react-focus-on locally in our codebase's Storybook, and were also getting that same behavior as well even in Chrome and FF and couldn't figure out why or what was happening (code was almost identical to the above CodeSandbox). We eventually figured out it was the setTimeout 0 in onWindowBlur race condition:

https://github.com/theKashey/react-focus-lock/blob/master/src/Trap.js#L185-L187

We changed the above setTimout duration from 0 to 1 and the crossFrame behavior started working for us locally. Maybe give it a shot on your end and see if it fixes Safari behavior as well? 🤞

from react-focus-lock.

😲 onBlur is executed "a little later" using a deferAction helper of mine - https://github.com/theKashey/react-focus-lock/blob/master/src/util.js#L7
It works exactly via setTimeout(..,1) - you have found the root case.
Well, it uses setTimeout only in the absence of setImmediate, which may or may not be polyfilled by a bundler.

from react-focus-lock.

Oooh! It all makes sense now 🤦 All the credit goes to @tkajtoch for figuring out that changing setTimeout fixed the behavior!

Would changing onWindowBlur to use deferAction be a clean solution, or would just changing the 0 to a 1 on its timeout suffice? 🤔

from react-focus-lock.

deferAction is a way to go. Tested in Chrome and safari - works great.

from react-focus-lock.

I think @tkajtoch is working on that - will keep you posted! Thanks as always for being amazingly responsive and speedy Anton!

from react-focus-lock.