-
29 Feb 2012 8:27 AM #1
Change in validation state causes form to scroll
Change in validation state causes form to scroll
REQUIRED INFORMATION
Ext version tested:
- Ext 4.1.0 beta 2
Browser versions tested against:
- Internet Explorer 9.0.8.16421
- Firefox 9.0.1 (Firebug 1.9.0)
- Chrome 16.0.912.75m (does not suffer from issue)
- Safari 5.1.2 (7534.52.7)
- Opera 11.60(build 1185)
DOCTYPE tested against:
- <!DOCTYPE html>
Description:
- The form scrolls when the validity of a field changes
Steps to reproduce the problem:
Using the sample below:
- Scroll to the bottom of the form
- Delete the text in the "Setting to edit" field, changing the 'is valid' state of the field
- Observe that the form jumps upwards, such that the field is now near the bottom of the page
- Scroll back to the bottom of the form
- Enter some text in the "Setting to edit" field, changing the 'is valid' state of the field
- Observe that the form jumps again
The result that was expected:
- The field validation is updated
- No other activity occurs
The result that occurs instead:
- The form scrolls, causing the fields to move whilst the user is interacting with them
Test Case:
Code:<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Scroll-on-change bug report</title> <link rel="stylesheet" type="text/css" href="ext/resources/css/ext-all.css"/> <script type="text/javascript" src="ext/ext-debug.js"></script> <script type="text/javascript"> Ext.define('OptionsForm', { extend: 'Ext.form.Panel', alias: 'widget.optionsform', bodyPadding: 10, items: [], initComponent: function () { var i; for (i = 0; i < 40; i = i + 1) { this.items.push({ xtype: 'textfield', fieldLabel: 'textfield' }); } this.items.push({ xtype: 'textfield', fieldLabel: 'Setting to edit', allowBlank: false, value: 'delete this text' }, { xtype: 'checkbox', boxLabel: 'checkbox', hideLabel: true }, { xtype: 'container', layout: 'hbox', items: [{ xtype: 'container', flex: 1 }, { xtype: 'container', flex: 20, layout: 'anchor', items: [{ xtype: 'textarea', fieldLabel: 'textarea', labelAlign: 'top', height: 500, }] }] }); this.callParent(); }, }); Ext.application({ launch: function () { Ext.create('Ext.container.Viewport', { layout: 'border', items: [{ region: 'center', xtype: 'tabpanel', activeTab: 0, items: [{ title: 'Options', xtype: 'container', layout: 'border', items: [{ xtype: 'optionsform', region: 'center', autoScroll: true }] }] }] }); } }); </script> </head> <body></body> </html>
HELPFUL INFORMATION
Debugging already done:
The problem only seems to occur if the text area is indented using the hbox container layout in the example. On the proper form for my application, I'm using indentation like this to indicate that one setting only applies when another is selected. The inner setting is enabled/disabled based on whether or not the checkbox is selected. If there is a better way of achieving this that does not suffer from this problem I'd be interested to hear it.
Additional CSS used:
- only default ext-all.css
Operating System:
- Windows 7 x64
-
29 Feb 2012 12:44 PM #2Sencha - Senior Forum Manager
- Join Date
- Mar 2007
- Location
- St. Louis, MO
- Posts
- 33,714
- Vote Rating
- 438
Thanks for the report.
Mitchell Simoens @SenchaMitch
Sencha Inc, Senior Forum Manager
________________
http://www.JSONPLint.com - Source to lint your JSONP!
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
https://github.com/mitchellsimoens
Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/
Need more help with your app? Hire Sencha Services services@sencha.com
Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is almost in print!
When posting code, please use BBCode's CODE tags.
-
7 Mar 2012 5:44 AM #3
Discovered a workaround (possible fix)
Discovered a workaround (possible fix)
I've just discovered Ext.form.FieldContainer. Using it with a config of { labelWidh:20, labelSeparator: '', fieldLabel: ' '} achieves the same indented effect without as much scaffolding and isn't affected by the reported bug when the validation state changes. I guess this is what I should have been using this all along.
-
23 Jul 2012 1:18 PM #4
Bug status?
Bug status?
I upgraded to Extjs 4.1.1, and this bug still exists (assuming I'm building my app up soundly).
I was just wondering if this was ever going to be addressed. It's a pretty annoying bug, so I'm surprised there haven't been been more complaints about it.
For me at least, I wasn't able to get rhamflett's workaround to work. It didn't seem to matter what type of containers the validating fields were nested in.
Thanks in advance for any help with this!
-
4 Oct 2012 5:13 AM #5
Not necessarily due to change in validation state
Not necessarily due to change in validation state
See my example in here:
http://www.sencha.com/forum/showthread.php?244755-textarea-content-change-causes-form-to-scroll-up-hiding-the-input-area
My debugging in there showed that this happens in the autoSize call on the change event (ext-all-debug.js l.84351, for ExtJS 4.1.2) for textarea field. If the text area has grow:true it calls updateLayout(), which results in updateLayout() being done for the form.Yaron Yogev
IT Software Developer
-
4 Nov 2012 5:32 AM #6
Same problem happens also with bug tree on exapnd in lower part when maxHeight is use
Same problem happens also with bug tree on exapnd in lower part when maxHeight is use
Yaron Yogev
IT Software Developer
-
16 Apr 2013 8:32 PM #7
Any update n this bug? It's extremely annoying. I'm hitting it all the time due to the hbox issue: if you want a text or number field that has a units label after the input field, you're going to run I to this. For example, to show a "Speed" in put field with a "mph" label after it, you need to use a field container with an hbox layout. The container would contain a number field followed by a display field (for the units).
-
8 May 2013 12:25 PM #8
The bug is still open? Any solution? I've the same problem...
You found a bug! We've classified it as
EXTJSIV-5491
.
We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.


Reply With Quote