64160 2011-07-08 05:16:39 -0700 Foward a non-bubbling event to related shadow host elements across relevant shadow scopes. 2011-08-18 21:55:41 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 59805 1 hayato webkit-unassigned dglazkov dominicc morrita rolandsteiner oldest_to_newest 434008 0 hayato 2011-07-08 05:16:39 -0700 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 434014 1 hayato 2011-07-08 05:29:23 -0700 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. 434104 2 dglazkov 2011-07-08 09:31:24 -0700 (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 434657 3 hayato 2011-07-10 19:57:11 -0700 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 434659 4 hayato 2011-07-10 20:14:02 -0700 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 434994 5 dglazkov 2011-07-11 10:41:57 -0700 (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. 435474 6 hayato 2011-07-11 21:35:26 -0700 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. 453631 7 hayato 2011-08-18 21:55:41 -0700 I'd like to make this 'WONTFIX' until we have a significant need for this idea,