Completed
Last Updated: 09 Jun 2023 14:11 by ADMIN
Release R3.2023-Increment.1(19.July.2023)
Created by: Stephen
Comments: 0
Category: TextArea
Type: Bug Report
0

If you configure a TextArea to be resizable, it simply is not.

https://docs.telerik.com/kendo-ui/api/javascript/ui/textarea/configuration/resize

This last worked in 2023 R1(2023.1.117): https://dojo.telerik.com/@Stephen/IqePaHim

And is first broken in 2023 R1 SP1(2023.1.314): https://dojo.telerik.com/@Stephen/UWUpoxUw

And is still broken in 2023 R1 SP2(2023.1.425): https://dojo.telerik.com/@Stephen/OnoKiboM

Notice that the resize handle is not even rendered anymore.

Unplanned
Last Updated: 27 Feb 2023 14:53 by Paweł Korczak

Bug report

If the splitter container has 100%, the height of the Splitter panes is changed when the splitbar is moved to the right or left.

Reproduction of the problem

  1. open the following example: http://dojo.telerik.com/EXOFEYon
  2. move the splitter to right and left
  3. height of panes is different depending on moving the Splitbar to the left or right

Current behavior

The panes of the splitter have the wrong height when it is moved to the left and the correct one when it is moved to the right.

Expected/desired behavior

Splitbar panes should have the same height regardless of splitbar moving.

Tip for fixing

When the splitbar is moved to the left, the left position of the second splitbar pane should be updated before its width. For now, it is updated after it, which causes showing a horizontal scrollbar of the Splitter parent for a moment. As result, the Splitter pane height is calculated wrongly.

Environment

  • Kendo UI version: 202x.r.ddd
  • jQuery version: x.y
  • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Unplanned
Last Updated: 22 Feb 2023 15:46 by Paweł Korczak
Created by: Paweł Korczak
Comments: 0
Category: TextArea
Type: Feature Request
0

Currently, attributes of an initial element are copied to a dynamically created outer element. This behavior is common for widgets from the "Editors" group (and not only). This causes multiple confusing results as applying styles or classes to the outer and inner elements at the same time. For example in this Dojo sample, when width or height is defined by percentage units, this causes a broken appearance.

Consider removing such attributes from the initial element and keeping them only on the generated outer one. A similar issue is caused when a custom class is applied to the initial element. The class is applied to both elements (outer and inner), so an additional selector should be used to target an exact element.

Completed
Last Updated: 26 Jan 2023 12:14 by ADMIN
Release R2.2023-Increment.1(15.Mar.2023)
Created by: Michael D
Comments: 2
Category: TextArea
Type: Bug Report
0

As described in https://docs.telerik.com/kendo-ui/api/javascript/ui/textarea/configuration/overflow, the TextArea widget supports customizing it's overflow behavior. However, setting this option to e.g. "scroll" has no effect as can be seen in this DOJO: https://dojo.telerik.com/etapAfaC.

If you check the applied styles in the browser's DEV-Tools, you can see that the internal class "k-input-inner" overrides the value set using the overflow option. 

Completed
Last Updated: 18 Nov 2021 09:27 by ADMIN
Release 2021.R3.SP.next

Dear Support,

I have some forms that is bind to MVVM and I am binding the VM's change event to check for any pending changes on the form.  The issue I am having is for textarea that is bind to null value, if I tab/click on the textarea and leave without making any changes, it will still trigger the VM's change event. 

https://dojo.telerik.com/IDotuWOl 

What is the solution for this?