[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 #3 from Hayato Ito <hayato at chromium.org>  2011-07-10 19:57:11 PST ---
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.