Hi Fady, I have same experience about focus in internal element within container element. I tried to do same thing for multiple fields time input UI for <input type=time>. In the implementation, fields are implemented in shadow DOM hosted by input element. We call fields are DateTimeFieldElement and container for them as DateTimeEditElement.
On first implementation, DateTimeEditElement controlled focus. When input element focused, DateTimeEditElement sets the first field. It worked fine except for Shift+Tab. http://trac.webkit.org/changeset/125263 I studied FocusController and EventHandler::defaultTabEventHandler. http://trac.webkit.org/browser/trunk/Source/WebCore/page/FocusController.cpp http://trac.webkit.org/browser/trunk/Source/WebCore/page/EventHandler.cpp I thought two options: 1. Factor out defaultTabEventHandler. => FocusController::advanceFocus requires keyboard event object for Option+Tab on Mac. 2. Create fake-keyboard event containing Shift+Tab then pass to defaultEventHandler. It seems making fake-keyboard event is little bit ugly. So, our conclusion is making DateTimeEditElement not to manage focus == FocusController manages focus. http://trac.webkit.org/changeset/127226 As of this experiment, setFocus() with direction parameter doesn't solve controlling focus by container. Container wants to know direction of focus navigation from event object. The pseudo code can be written as: TimeInputElement::defaultEventHandler(Event* event) { if (event->isFocusEvent()) { if (event->focuseDirection() == FocusDiectionForward) setFocusToField(0); else setFocusToField(m_lastFieldIndex); // Not sure about FocusDirectionUp/Down // Need RTL support for FocusDirectionLeft/Right. Move focus Left/Right on physical location. } } On Tue, Sep 11, 2012 at 4:32 AM, Fady Samuel <fsam...@chromium.org> wrote: > Hi all, > > I'm working on a plugin that needs to deal with focus. I'd like this > plugin to look an feel just like any other DOM element including the way it > deals with focus. The problem that I have is Widgets know about focus but > not focus direction (forward/reverse). My plugin has several logical > subelements. The initial subelement to select is based on the direction > taken to arrive to the plugin by keyboard (Tab v.s. Shift-Tab). > > I'd like to add a new parameter with a flag or enum three states perhaps: > Foward Reverse, Neither to Widget::SetFocus. > > This is going to require many one-line changes throughout a number of > files throughout WebCore. > > Before I embark on such a change, I'd like to get some feedback at this > point. Is this a reasonable thing to add? Does anyone oppose this change? > Is there a cleaner way to add this support? > > Thanks, > > Fady > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
