[Webkit-unassigned] [Bug 64160] Foward a non-bubbling event to related shadow host elements across relevant shadow scopes.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=64160





--- Comment #4 from Hayato Ito <hayato at chromium.org>  2011-07-10 20:14:02 PST ---
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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.