Opened 4 years ago

Last modified 2 years ago

#18807 new defect

Inconsistency of dijit.form.SimpleTextArea value (displayed- or not) when @maxLength > actual data length

Reported by: Claude Guyomard Owned by: bill
Priority: undecided Milestone: 1.14
Component: Dijit Version: 1.10.4
Keywords: Cc:
Blocked By: Blocking:

Description

Because legacy database may serve text data larger than the client-side data length specification currently deployed. Considering this scenario, I observed the following :

Testcase 1 [RW]: Given a SimpleTextArea? declared with @maxLength and an initial srcRefNode content (understand "ctor param value") larger than @maxLength :

  • OBS-1 After creation and startup, the widget displays the whole value after startup.

Neither the widget creation, nor its startup apply @maxLength and reducts the displayed value.

  • OBS-2 When this widget is focused and the user presses a key (not necessarily a printable char, e.g. down-arrow), then the value and the displayed-value loose characters.

=> Inconsistency between OBS-1 and OBS-2

Testcase 2 [RO]: Given the same SimpleTextArea? declaration as TC1, with @readonly :

  • The widget behaves exactly the same as in TC1 and is not affected by the readOnly=true specification.

=> More inconsistent because an user action may change the value of a "read-only" widget.

My expectations about Testcase TC1

C11- if the length reduction of the received (ctor param) value is considered as acceptable, I think that this reduction should be applied before the widget becomes visible (the end of startup typically)

C12- if the length reductionof the received (ctor param) value is considered as UN-acceptable, this reduction could affect only the new chars typed by the user (inter-char insertion or char selection overwrite).

  • inter-char insertionchar -> no result,
  • char selection overwrite -> removal of the selected char sequence.

My expectations about Testcase TC2

C21- The comment C11 apply here too: "if the truncation of the received (ctor param) value is considered as acceptable, this truncation should be applied before the widget becomes visible".

C22- Variation of comment #C12: "if the reduction of the received (ctor param) value is considered as UN-acceptable, no user action may result in a value char loss".

Scope

  • Observed wit

Change History (4)

comment:1 Changed 4 years ago by Claude Guyomard

Scope

  • Observed with 1.10.
  • Exists probably in later versions too (In master/dijit, diijit.form.SimpleTextArea? _onInput(event) still considers neither this.readOnly, neither this.disabled)

Possible directions

  • the browser-native behaviour of the html TEXTAREA element can help : The behaviour in Chrome is similar to C12 and C22. It gives initially the priority to the pre-parsing data safety over the brutal application of @maxLength. Then it leaves the control to the user (whether to modify or not).
  • addition of a new ctor boolean param 'strictMaxLength' for some backward compatibility
  • diijit.form.SimpleTextArea? _onInput(event) : the guard "if(this.maxLength)" should be "if(!this.readOnly && !this.disabled && this.maxLength)"
  • user typing, copy-pasting, ...

comment:2 Changed 4 years ago by bill

Component: GeneralDijit
Owner: set to bill

Yes, I agree it would be better to truncate the text when the initial value is set, or to not truncate at all.

Having an initial text length > Textarea#maxlength seems like an exceptional case though.

comment:3 Changed 3 years ago by dylan

Milestone: tbd1.13

comment:4 Changed 2 years ago by dylan

Milestone: 1.131.14
Note: See TracTickets for help on using tickets.