Re: [w3c/uievents] Propose the new navbeforefocus UIEvent (#246)

I've noticed many requirements on the cancellable focusin/focusout events from JS developers, but it hasn't been supported yet. I guess there are some reasons in terms of browser engine implementation. I would like to propose a couple of expected issues on it as follows:

**1. How to do rollback once focusin event is canceled. (preventDefault)**
Assume that authors can specify event.preventDefault inside a B.focusin event handler and it works. (A: current focus target, B: next focus target) In that case, browser engines might need to handle some rollback logics for what's already executed such as A.focusout for styling or JS execution. The reason is that the focus-related events works as a synchronized order as follows.
> Event order: A.keydown -> A.blur -> A.focusout -> B.focus -> B.focusin (Chrome v78)
> Event order: A.keydown -> A.focusout -> B.focusin -> A.blur -> B.focus (UI Events spec)
> Reference: https://www.w3.org/TR/uievents/#events-focusevent-event-order
> Test page: https://codepen.io/anawhj/pen/pooPOZz

**2. What's the difference between preventDefault in B.focusin and focus() in A.focusout**
Assume that authors want to override the next focus target when she presses a tab key. It can be supported by the cancellable B.focusin event handler, but also supported by the non-cancellable A.focusout event handler. I wonder some use case that needs the cancellable B.focusin. You could see an example code at the following link.
https://codepen.io/anawhj/pen/jOOmveg

Could someone explain any opinion on them above or provide a real use case that needs the cancellable focusin/focusout? For example, if we specify event.preventDefault() in A.focusout and B.focusin handler, what should it happen?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/246#issuecomment-546200048