Hi Fady,
DateTimeEditElement::focusByOwner() is called on HTMLInputElement::focus()
function == JavaScript focus() method.
Other than other input types, input type "time" isn't focusable, but
DateTimeFieldElement, field, is focusable. So, Focus controller moves focus
around fields.
In other words, DateTime{Edit,Field}Element don't manage focus.
Thanks.
-yosi
On Wed, Sep 12, 2012 at 12:41 AM, Fady Samuel <fsam...@chromium.org> wrote:
> 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 <yo...@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 <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
