Bug 64160 – Foward a non-bubbling event to related shadow host elements across relevant shadow scopes.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: DOM

[Hayato Ito]

Let me explain using the following example:

Document
  Component-A
    Component-B
      Component-C
      Component-D
        Input-E (* new-focused-node)
    Component-F
      Input-G
      Component-H
        Input-I
      Component-J
        Input-K (* old-focused-node)

'Component' here means a focusable shadow host element.
Suppose that a focused node has just been changed from 'Input-K' to 'Input-E'. 

In this case, which components should receive a 'focus' event? Remember that a 'focus' event is a non-bubbling event.

It seems that XBL2 spec says a boundary element should receive a 'focus' event if a focusable element underneath get focused.
- http://dev.w3.org/2006/xbl2/#the-focus-domfocusin-blur-and-domfocusou

My initial rough idea is:

 * B and D (and Input-E) should receive a 'focus' event.
 * F and J (and Input-K) should receive a 'blur' event.
 * Each event should be fired as in a Event Target phase, which means:
   - event.target is always same to the element itself.
     e.g. A focus event listener on Component B will receive a event whose target is set to 'Component-B'.
   - event.stopPropagation() doesn't take an effect. That doesn't make sense.

Although I use a 'focus' event as an example, I guess we can apply the same discussion to all non-bubbling events.
Any opinion are welcome.


I referred to these documents.
- http://dev.w3.org/2006/xbl2/#event-handlers
- http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Focus_and_Shadow_Subtrees
- http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

[Hayato Ito]

If we should treat a 'component' like a 'iframe', we don't need to do anything in the mentioned case.
All we have to do is just calling 'focus' event on 'Input-E' and calling 'blur' event on 'Input-K'. That's all.

But I don't think we can treat a 'Component' and a 'iframe' in the same fashion in this case.

[Dimitri Glazkov (Google)]

(In reply to comment #0)
> Let me explain using the following example:
> 
> Document
>   Component-A
>     Component-B
>       Component-C
>       Component-D
>         Input-E (* new-focused-node)
>     Component-F
>       Input-G
>       Component-H
>         Input-I
>       Component-J
>         Input-K (* old-focused-node)
> 
> 'Component' here means a focusable shadow host element.
> Suppose that a focused node has just been changed from 'Input-K' to 'Input-E'. 
> 
> In this case, which components should receive a 'focus' event? Remember that a 'focus' event is a non-bubbling event.
> 
> It seems that XBL2 spec says a boundary element should receive a 'focus' event if a focusable element underneath get focused.
> - http://dev.w3.org/2006/xbl2/#the-focus-domfocusin-blur-and-domfocusou

Where exactly does it say that? Focus event doesn't bubble, but it still propagates through the ancestor chain during capture.

> 
> My initial rough idea is:
> 
>  * B and D (and Input-E) should receive a 'focus' event.

Why would B and D need to to get a focus event? Can you explain this a bit more? In my mind, only Input-E should be getting it.

>  * F and J (and Input-K) should receive a 'blur' event.

Similarly, only Input-K should be getting it.

>  * Each event should be fired as in a Event Target phase, which means:
>    - event.target is always same to the element itself.
>      e.g. A focus event listener on Component B will receive a event whose target is set to 'Component-B'.
>    - event.stopPropagation() doesn't take an effect. That doesn't make sense.
> 
> Although I use a 'focus' event as an example, I guess we can apply the same discussion to all non-bubbling events.

I don't understand why we need to re-fire non-bubbling events. Can you explain your thinking a bit more?

> Any opinion are welcome.
> 
> 
> I referred to these documents.
> - http://dev.w3.org/2006/xbl2/#event-handlers
> - http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Focus_and_Shadow_Subtrees
> - http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

[Hayato Ito]

Hi, Dominic

Thank you for the comment.

Okay, let me explain the rationale behind.
Suppose the current <input type="file"> element, which might be implemented as a 'Component', which has one internal 'button' element.
If we focus the internal button, the outside host element, <input>, get 'focus' event in a TARGET phase in the current implementation, which uses a custom logic, I guess.

So far, so good.

Suppose further that this internal button itself is implemnted as another 'Component'. Say:

  Component-A <Input type='file'>
   Component-B (Button)
    Internal element C (something internal)

If we try to focus this Component-A by <tab> key, should Component-A receive a 'focus' event as TARGET phase?

I agree that we should fire 'focus' event only on Internal element C in TARGET phase. That makes implementation much simpler.
If Component-A really want to know it is 'focused', it should use 'focusin' event or add listener on capturing phase.

But we have to fire a 'focus' event on Component-A as TARGET phase in this case to keep an compatibility.
So I am in a annoying situation. I don't want to make exceptional rules to each components.

I prefer a simple and general rule. If you have any idea, that's highly welcome.



(In reply to comment #2)
> (In reply to comment #0)
> > Let me explain using the following example:
> > 
> > Document
> >   Component-A
> >     Component-B
> >       Component-C
> >       Component-D
> >         Input-E (* new-focused-node)
> >     Component-F
> >       Input-G
> >       Component-H
> >         Input-I
> >       Component-J
> >         Input-K (* old-focused-node)
> > 
> > 'Component' here means a focusable shadow host element.
> > Suppose that a focused node has just been changed from 'Input-K' to 'Input-E'. 
> > 
> > In this case, which components should receive a 'focus' event? Remember that a 'focus' event is a non-bubbling event.
> > 
> > It seems that XBL2 spec says a boundary element should receive a 'focus' event if a focusable element underneath get focused.
> > - http://dev.w3.org/2006/xbl2/#the-focus-domfocusin-blur-and-domfocusou
> 
> Where exactly does it say that? Focus event doesn't bubble, but it still propagates through the ancestor chain during capture.
> 
> > 
> > My initial rough idea is:
> > 
> >  * B and D (and Input-E) should receive a 'focus' event.
> 
> Why would B and D need to to get a focus event? Can you explain this a bit more? In my mind, only Input-E should be getting it.
> 
> >  * F and J (and Input-K) should receive a 'blur' event.
> 
> Similarly, only Input-K should be getting it.
> 
> >  * Each event should be fired as in a Event Target phase, which means:
> >    - event.target is always same to the element itself.
> >      e.g. A focus event listener on Component B will receive a event whose target is set to 'Component-B'.
> >    - event.stopPropagation() doesn't take an effect. That doesn't make sense.
> > 
> > Although I use a 'focus' event as an example, I guess we can apply the same discussion to all non-bubbling events.
> 
> I don't understand why we need to re-fire non-bubbling events. Can you explain your thinking a bit more?
> 
> > Any opinion are welcome.
> > 
> > 
> > I referred to these documents.
> > - http://dev.w3.org/2006/xbl2/#event-handlers
> > - http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Focus_and_Shadow_Subtrees
> > - http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

[Hayato Ito]

My facing problem is a <keygen> element, which has one internal select element.
In current implementation, if we focus that using <tab> key, only internal select element get 'focus' event on TARGET phase. A <kengen> element itself won't get 'focus' event on TARGET phase. That doesn't look natural to me. I'd like to solve the issue without making any exceptional rules.

But I am thinking that my initial idea is too radical and complex. I am not sure that's worth implementing... Maybe we should have better approach.


(In reply to comment #3)
> Hi, Dominic
> 
> Thank you for the comment.
> 
> Okay, let me explain the rationale behind.
> Suppose the current <input type="file"> element, which might be implemented as a 'Component', which has one internal 'button' element.
> If we focus the internal button, the outside host element, <input>, get 'focus' event in a TARGET phase in the current implementation, which uses a custom logic, I guess.
> 
> So far, so good.
> 
> Suppose further that this internal button itself is implemnted as another 'Component'. Say:
> 
>   Component-A <Input type='file'>
>    Component-B (Button)
>     Internal element C (something internal)
> 
> If we try to focus this Component-A by <tab> key, should Component-A receive a 'focus' event as TARGET phase?
> 
> I agree that we should fire 'focus' event only on Internal element C in TARGET phase. That makes implementation much simpler.
> If Component-A really want to know it is 'focused', it should use 'focusin' event or add listener on capturing phase.
> 
> But we have to fire a 'focus' event on Component-A as TARGET phase in this case to keep an compatibility.
> So I am in a annoying situation. I don't want to make exceptional rules to each components.
> 
> I prefer a simple and general rule. If you have any idea, that's highly welcome.
> 
> 
> 
> (In reply to comment #2)
> > (In reply to comment #0)
> > > Let me explain using the following example:
> > > 
> > > Document
> > >   Component-A
> > >     Component-B
> > >       Component-C
> > >       Component-D
> > >         Input-E (* new-focused-node)
> > >     Component-F
> > >       Input-G
> > >       Component-H
> > >         Input-I
> > >       Component-J
> > >         Input-K (* old-focused-node)
> > > 
> > > 'Component' here means a focusable shadow host element.
> > > Suppose that a focused node has just been changed from 'Input-K' to 'Input-E'. 
> > > 
> > > In this case, which components should receive a 'focus' event? Remember that a 'focus' event is a non-bubbling event.
> > > 
> > > It seems that XBL2 spec says a boundary element should receive a 'focus' event if a focusable element underneath get focused.
> > > - http://dev.w3.org/2006/xbl2/#the-focus-domfocusin-blur-and-domfocusou
> > 
> > Where exactly does it say that? Focus event doesn't bubble, but it still propagates through the ancestor chain during capture.
> > 
> > > 
> > > My initial rough idea is:
> > > 
> > >  * B and D (and Input-E) should receive a 'focus' event.
> > 
> > Why would B and D need to to get a focus event? Can you explain this a bit more? In my mind, only Input-E should be getting it.
> > 
> > >  * F and J (and Input-K) should receive a 'blur' event.
> > 
> > Similarly, only Input-K should be getting it.
> > 
> > >  * Each event should be fired as in a Event Target phase, which means:
> > >    - event.target is always same to the element itself.
> > >      e.g. A focus event listener on Component B will receive a event whose target is set to 'Component-B'.
> > >    - event.stopPropagation() doesn't take an effect. That doesn't make sense.
> > > 
> > > Although I use a 'focus' event as an example, I guess we can apply the same discussion to all non-bubbling events.
> > 
> > I don't understand why we need to re-fire non-bubbling events. Can you explain your thinking a bit more?
> > 
> > > Any opinion are welcome.
> > > 
> > > 
> > > I referred to these documents.
> > > - http://dev.w3.org/2006/xbl2/#event-handlers
> > > - http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Focus_and_Shadow_Subtrees
> > > - http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

[Dimitri Glazkov (Google)]

(In reply to comment #4)
> My facing problem is a <keygen> element, which has one internal select element.
> In current implementation, if we focus that using <tab> key, only internal select element get 'focus' event on TARGET phase. A <kengen> element itself won't get 'focus' event on TARGET phase. That doesn't look natural to me. I'd like to solve the issue without making any exceptional rules.
> 
> But I am thinking that my initial idea is too radical and complex. I am not sure that's worth implementing... Maybe we should have better approach.

No, I think you're onto something. The keygen and input[type=file] as implemented today demonstrate, that event retargeting is not always enough for non-bubbling events, specifically the focus/blur events.

However, we should understand what this means. Does this mean that all non-bubbling events should start acting as focus/blur on keygen? It seems that would be odd.

[Hayato Ito]

Hi Dimitri,

I feel the subject of this bugzilla entry is scaring. I should have focused only on a 'focus' event, not all non-bubbling events.
It might not be a good idea to try to handle all non-bubbling event equally in this early stage.

Let me concentrate on a 'focus' event, forgetting other non-bubbling events.


(In reply to comment #5)
> (In reply to comment #4)
> > My facing problem is a <keygen> element, which has one internal select element.
> > In current implementation, if we focus that using <tab> key, only internal select element get 'focus' event on TARGET phase. A <kengen> element itself won't get 'focus' event on TARGET phase. That doesn't look natural to me. I'd like to solve the issue without making any exceptional rules.
> > 
> > But I am thinking that my initial idea is too radical and complex. I am not sure that's worth implementing... Maybe we should have better approach.
> 
> No, I think you're onto something. The keygen and input[type=file] as implemented today demonstrate, that event retargeting is not always enough for non-bubbling events, specifically the focus/blur events.
> 
> However, we should understand what this means. Does this mean that all non-bubbling events should start acting as focus/blur on keygen? It seems that would be odd.

[Hayato Ito]

I'd like to make this 'WONTFIX' until we have a significant need for this idea,