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

[Fady Samuel]

Hi Youifumi,

I'm a little bit confused about what you did. It seems like youalways
select the first subelement in your elemnt.

void DateTimeEditElement::focusByOwner()
{
if (DateTimeFieldElement* field = fieldAt(0))
field->focus();
}

I don't understand how Shift+Tab works in your code?

Thanks,

Fady

On Mon, Sep 10, 2012 at 9:39 PM, Yoshifumi Inoue <yosin at google.com> wrote:

> 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/6fc1d8c0/attachment.html>