Bug 64160
| Summary: | Foward a non-bubbling event to related shadow host elements across relevant shadow scopes. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Hayato Ito <hayato> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | dglazkov, dominicc, morrita, rolandsteiner |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 59805 | ||
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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,