Success! Looks like we've fixed this one. According to our records the fix was applied for
EXTJS-5389
in
a recent build.
-
Ext JS Premium Member
Form gets dirty if a textarea field contains a leading line break
Ext version tested:
Browser versions tested against:
Description:
- If a textarea form field's initial value contains a leading \n line break, that line break is removed and the form is marked as dirty
Steps to reproduce the problem:
- create a form panel with a text area field
- set the textarea's value config to '\nline1\nline2'
- render the form
The result that was expected:
- the text area field shows three lines: <empty>, 'line1', 'line2'
- form.isDirty() returns false
The result that occurs instead:
- the text area field shows two lines: 'line1', 'line2'
- form.isDirty() returns true
Test Case:
Code:
Ext.onReady(function () {
Ext.create('Ext.form.Panel', {
frame: true,
title: 'Leading line break (\\n)',
width: 350,
renderTo: Ext.getBody(),
items: [{
xtype: 'textarea',
anchor: '100%',
value: '\nline1\nline2'
}],
buttons: [{
text: 'Is Dirty?',
handler: function(button) {
Ext.Msg.alert('Is form dirty?', button.up('form').getForm().isDirty() ? 'yes' : 'no');
}
}]
});
HELPFUL INFORMATION
This worked in 4.0.7
-
Thank you for the report.
-
Ext JS Premium Member
This bug was reported as fixed on the RC1 release notes, but the scenario described here is still broken in RC1 & RC2.
-
FYI this is fixed in 4.1.0 final. You also raised another issue with regards to carriage returns, it will be fixed in 4.1.1.
The problem is that some browsers will automatically strip out '\r', so when you get the value out of the field it appears as though it's dirty. To normalize it, we now strip out every '\r' when setting the value, since we can't reasonably try and re-insert the '\r'.
Twitter - @evantrimboli
Former Sencha framework engineer, available for consulting.
As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.
-
Ext JS Premium Member
It appears that the scenario from this bug as well as a similar scenario described here are still broken in IE8. Tested in 4.1.1 GA.