[webkit-dev] Adding reverse flag to Widget::SetFocus?

Yoshifumi Inoue yosin at google.com
Mon Sep 10 18:39:01 PDT 2012


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 <fsamuel at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120911/13a7741d/attachment.html>


More information about the webkit-dev mailing list