LWC lightning-record-form Time field edit

Question

I have a lightning-record-form for a custom object, which I show and allow to edit with the basic element's features:

<lightning-record-form record-id={opId} object-api-name="Operation__c" layout-type="Full" mode="view" style="padding: 0 10px;">
        </lightning-record-form>

The viewing and editing works well, EXCEPT for a Time type field, which for some reason I cannot edit, when in edit mode. The field somehow shows the time value in it's long form: '02:00:00.000Z' instead of '02:00' in the object's creation form, and it's not possible to type/add/change/paste any text in the field. But you can delete the field's content...

This is quite problematic, as my users need to be able to edit this field in the form. I couldn't find any documentation or help regarding this.

Does anybody know how to fix this?

Thanks for your help,

Daniel

Answer 1

I suspect (but have no firm documentation link) that time fields are simply not (yet) supported in lightning-record-form. It does appear that lightning-record-form uses lightning-input-field for editing (and you can see this in the open-source copy of lightning-record-form). lightning-input-field is not yet open-source, but the docs include a list of supported fields types; that list includes 'Date' and 'Date/Time', but does not include 'Time'.

There is an Idea posted to add this support, but like many good Ideas, it has little support so far... just 2 votes (and one of them mine). You will likely need to switch to lightning-edit-form and build a custom editor component for your Time fields. Edit to add: As @naga points out, lightning-input can handle time input, and if it meets your needs is simpler than a custom editor component. You will still need to switch to lightning-edit-form.

Answer 2

I have experienced the same in my record-edit-form. The workaround I use is to hide the time lightning-input-field and display a lightning-input field with type="time" and populate the lightning-input-field value with an onchange event of the lightning-input value. Using the input time field instead of the standard one is a waste of time everytime I need a time field. But the input version gives more flexibility in controlling the range and step value etc.

Code form my LWC:

HTML:

<lightning-input-field class="slds-hide" field-name="Time__c"
   value={sessionTime}>
</lightning-input-field>
<lightning-input
   type="time"
   name="sessTime"
   label="Time"
   field-level-help="Time of delivery"
   required
   value={sessionTime}
   min="06:00:00.000Z"
   max="21:00:00.000Z"
   variant="label-inline"
   onchange={handleTimeChange}></lightning-input>

JS:

handleTimeChange(event) { this.sessionTime = event.detail.value; }

Answer 3

We use the Lightning Record Form in an LWC where the form's content is obtained from a Full layout for the child object, thus:

<lightning-record-form
        object-api-name="ChildObject__c"
        layout-type="Full"
        mode="edit"
        onsubmit={handleFormSubmit}
        onsuccess={handleFormSuccess}
        onerror={handleFormError}
        oncancel={handleFormCancel}>
</lightning-record-form>

As you can see, we directly use the form in edit mode. This was working fine** in earlier versions of the Salesforce Platform but is currently broken. You may see that you can delete characters from an existing time value but you cannot enter new values. When you try to, if you open the browser's console, you will see errors like:

Refused to run the JavaScript URL because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-xxxxxxxxxxxxxxxxxxx' chrome-extension: 'unsafe-eval' *.canary.lwc.dev *.visualforce.com ...". Either the 'unsafe-inline' keyword, a hash ('sha-256-...'), or a nonce ('nonce-...') is required to enable inline execution.

I believe this is a Lightning Platform bug. I am awaiting feedback on the partner forums from the Salesforce LWC Base Components product manager about this apparent bug (I raised this back in January and I'm still waiting for a response). I repeated this question here, on SFSE too. I will update this answer if/when I get a reply.

**: By fine I mean a user could enter an ISO formatted time (it had to be at least hh:mm:ss, hh:mm did not work). It would always format up as hh:mm:ss.sssZ, which is a bit rubbish, but we could live with it.

UPDATE:

Please see the new answer against this Q&A.