date/time inputs should not handle keyboard events if they aren't focused.

date/time inputs should not handle keyboard events if they aren't focused.

This fixes an assertion failure in ~PickerIndicatorElement.

We need to do rebaseline of many tests because these tests opened pickers
without focus.  openPicker() force to focus on <input> elements now.

We confirmed Win10 failures were trivial.  They were due to month
format change and minor font glitch.

BUG=529530
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=201962

[tkent, 2015-09-09 03:44:38]

Patchset #1 (id:1) has been deleted

[tkent, 2015-09-09 04:27:06]

tkent@chromium.org changed reviewers:
+ keishi@chromium.org

[tkent, 2015-09-09 04:27:06]

Keishi, would you review this please?

[keishi, 2015-09-09 05:00:10]

Is the focus the root cause for the crash?

In the clusteruzz test case
openPicker() does tCF1.appendChild(tCF1); which removes the body from the
document. I think it should call
- HTMLInputElement::removedFrom()
- BaseMultipleFieldsDateAndTimeInputType::closePopupView() 
- PickerIndicatorElement::closePopup()
- DateTimeChooserImpl::endChooser()
- WebViewImpl::closePagePopup()
- WebPagePopupImpl::closePopup()
- DateTimeChooserImpl::didClosePopup()
and Picker IndicatorElement should still be alive.

Is the problem something like
BaseMultipleFieldsDateAndTimeInputType::pickerIndicatorElement() not returning
the proper picker indicator?

[tkent, 2015-09-09 05:21:47]

On 2015/09/09 05:00:10, keishi wrote:
> Is the focus the root cause for the crash?

The situation is similar to https://codereview.chromium.org/1293953003 we fixed
last month.  The popup frame has the last reference of HTMLInputElement, and
we'd like to avoid it.
We want to close the popup before HTMLInputElement/PickerIndicatorElement
destructors.  We close the popup when
 - HTMLInputElement loses its layout object.
 - HTMLInputElement is removed from the Document tree.
However, the testcase opens the popup after the HTMLInputElement was removed
from the tree.  So, we have no chance to close the popup.
Adding focus() check is reasonable for keyboard event handling in general. 
Adding inDocument() check also works.

[keishi, 2015-09-09 05:36:31]

LGTM

[tkent, 2015-09-09 06:40:02]

The CQ bit was checked by tkent@chromium.org

[tkent, 2015-09-09 06:40:02]

The patchset sent to the CQ was uploaded after l-g-t-m from keishi@chromium.org
Link to the patchset: https://codereview.chromium.org/1311013012/#ps40001
(title: "update *-open-picker-with-f4-key.html")

[commit-bot: I haz the power, 2015-09-09 06:40:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1311013012/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1311013012/40001

[commit-bot: I haz the power, 2015-09-09 09:38:11]

Committed patchset #2 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=201962