Bug 216005

Summary: [macOS] Add disabled and readonly behaviors to date inputs
Product: WebKit Reporter: Aditya Keerthi <akeerthi>
Component: FormsAssignee: Aditya Keerthi <akeerthi>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, changseok, esprehn+autocc, ews-watchlist, glenn, gyuyoung.kim, hi, macpherson, menard, mifenton, m.kurz+webkitbugs, thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Mac   
OS: Unspecified   
Bug Depends on: 215938    
Bug Blocks:    
Attachments:
Description Flags
Patch
hi: review+
Patch for landing none

Description Aditya Keerthi 2020-08-31 08:31:18 PDT
...
Comment 1 Aditya Keerthi 2020-09-01 09:34:30 PDT
Created attachment 407686 [details]
Patch
Comment 2 Devin Rousso 2020-09-01 11:07:06 PDT
Comment on attachment 407686 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=407686&action=review

> Source/WebCore/html/shadow/DateTimeFieldElement.cpp:64
> +        if (!isFieldOwnerDisabled() && !isFieldOwnerReadOnly()) {

`readonly` inputs are still able to receive events.  They basically are the same as regular inputs except that typing doesn't update the `value`.  Is that still possible with this?  Am I reading this code wrong?
Comment 3 Aditya Keerthi 2020-09-01 11:28:24 PDT
(In reply to Devin Rousso from comment #2)
> Comment on attachment 407686 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=407686&action=review
> 
> > Source/WebCore/html/shadow/DateTimeFieldElement.cpp:64
> > +        if (!isFieldOwnerDisabled() && !isFieldOwnerReadOnly()) {
> 
> `readonly` inputs are still able to receive events.  They basically are the
> same as regular inputs except that typing doesn't update the `value`.  Is
> that still possible with this?  Am I reading this code wrong?

Keyboard events are still dispatched on the element. This code just prevents editability – `handleKeyboardEvent` is a virtual method that the editable fields use to respond to keyboard events.
Comment 4 Devin Rousso 2020-09-02 14:27:03 PDT
Comment on attachment 407686 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=407686&action=review

r=me, nice works!

> Source/WebCore/css/html.css:520
> +input[disabled]::-webkit-datetime-edit-year-field,

NIT: should these be `input[type="date"]`?

> Source/WebCore/html/BaseChooserOnlyDateAndTimeInputType.cpp:318
> +    return element()->isDisabledFormControl();

NIT: should this have `ASSERT(element())` too?

> Source/WebCore/html/shadow/DateTimeFieldElement.cpp:119
> +bool DateTimeFieldElement::isFocusable() const

(for my own knowledge) is this what's used to determine whether or not the `<input type="date">` is mouse-interactable?  I ask because `disabled` should prevent all interaction but `readonly` should still allow mouse interaction.
Comment 5 Aditya Keerthi 2020-09-02 14:43:26 PDT
Created attachment 407818 [details]
Patch for landing
Comment 6 Aditya Keerthi 2020-09-02 14:49:39 PDT
(In reply to Devin Rousso from comment #4)
> Comment on attachment 407686 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=407686&action=review
> 
> r=me, nice works!

Thanks for the review!
 
> > Source/WebCore/css/html.css:520
> > +input[disabled]::-webkit-datetime-edit-year-field,
> 
> NIT: should these be `input[type="date"]`?

They probably should. I've added a FIXME to address this in a follow-up, since there are existing instances that should also be updated.
 
> > Source/WebCore/html/BaseChooserOnlyDateAndTimeInputType.cpp:318
> > +    return element()->isDisabledFormControl();
> 
> NIT: should this have `ASSERT(element())` too?

Added an assertion.
 
> > Source/WebCore/html/shadow/DateTimeFieldElement.cpp:119
> > +bool DateTimeFieldElement::isFocusable() const
> 
> (for my own knowledge) is this what's used to determine whether or not the
> `<input type="date">` is mouse-interactable?  I ask because `disabled`
> should prevent all interaction but `readonly` should still allow mouse
> interaction.

Partially.

If by mouse-interaction, you mean the ability to select the individual components of the control using a mouse, the answer is yes.

If by mouse-interaction, you mean the dispatching of mouse events, that is handled in existing code in Node::handleLocalEvents, which does not dispatch events if Element::isDisabledFormControl is true.
Comment 7 EWS 2020-09-03 07:40:11 PDT
Committed r266514: <https://trac.webkit.org/changeset/266514>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 407818 [details].
Comment 8 Radar WebKit Bug Importer 2020-09-03 07:41:18 PDT
<rdar://problem/68278191>