View Full Version : [OPEN] [UNKNOWN][3.x/2.x] Several CSS/Event bugs in IE6/FF for one example

18 Sep 2009, 7:16 AM
Hi, I've recently seen several issues existing in both Ext3 (3.0.0) and 2 (2.2.1) and I compiled an example to show most of them:

<title>Test page</title>
<script type="text/javascript" src="/extjs/3/src/core/core/Ext.js"></script>
<script type="text/javascript" src="/extjs/3/adapter/ext/ext-base-debug.js"></script>
<script type="text/javascript" src="/extjs/3/ext-all-debug.js"></script>
<script type="text/javascript">
Ext.onReady(function() {
var test = {
region: 'west',
width: 500,
split: true,
defaultType: 'textfield',
items: [
{ fieldLabel: 'test', name: 'test' },
{ fieldLabel: 'test1', name: 'test1' }
var test1 = {
region: 'center',
width: '100%',
defaultType: 'textfield',
items: [
{ fieldLabel: 'test2', name: 'test2' },
{ fieldLabel: 'test3', name: 'test3' }
test1 = { region:'center', listeners: { resize: resizeTest1 }, items: test1 };
new Ext.Viewport(
layout: 'border',
items: [ test, test1 ]
function resizeTest1()
<link rel="stylesheet" type="text/css" href="/extjs/3/resources/css/ext-all.css">
</html>Now here are the issues/bugs:
1. In IE6, if you don't have the 'margin:1px' on line 36, the bottom border for the textfields will disappear (just view the example in IE6 you'd see that the textfields in "test" do not have bottom border while "test1"'s have.
2. If you do use 'margin:1px' on textfield but do not use padding on container sometimes that causes the textfield's right border disappear in IE6 (not shown in the example).
3. If you use 'margin:1px' AND use 'anchor:'100%'' on line 36, the whole textfields disappear from IE6. Setting anchor to 99% or lower fixes it.
4. If you comment out line 43, and then resize "test" and "test1" by moving the split bar in between, all the textfields in test and test1 resize correctly due to anchor + form. But, if you do NOT comment out line 43, you'll find:
a. If you comment out listener on line 43, then textfields in "test1" no longer resize. This shows that when a form is not the direct target of resize, it will not respect anchor settings. In this case, the form's parent was the direct target of resize, so one would have to manually set a listener and fire a resize event on the form for the anchor setting to work. But it seems to me that Ext's event model should respect DOM event model and create a capture phase by firing resize on the children? That would at least be the desired situation - any developer in this situation would like to see when user moves the split bar, the textfields automatically resize. This is an issue for both IE and FF.
b. Even if you do set a custom resize function that fixes resize issue, it still has some issue: when user resizes using the splitbar, if user move the splitbar a relatively long distance (exactly how long depends on anchor setting, see further below) to the RIGHT side quickly, the textfields in "test1" disappear (it seems to be the same content too wide issue seen in IE6 in the point 3 above). This doesn't happen when user moves to the LEFT side. VERY INTERESTINGLY, if you refresh the page so that the textfields in "test1" are showing, then move the splitbar slowly, a little bit by little bit, to the RIGHT side, you'll find the textfields do not disappear in IE6 at all (until it's too far to the right). And the resize was done correctly too. How little this "little bit by little bit" depends entirely upon the anchor size set on line 36. If you set it to 99%, you need to move really small; if it's 90%, you can move a bit bigger distance every time. Clearly it's again due to content too wide right AFTER split bar movement. For some reason, if the content's too wide right after split bar moved, test1 form does not resize any more or does not resize correctly (maybe not taking browser's default handling into account?). Yet if user moves the split bar short enough that the content does not overflow container yet, the resize will resize correctly to what was set in anchor, preventing the textfields from disappearing.

The issues/bugs above are very frustrating and not uncommon (as demo-ed by the very simple example). I hope they could be fixed soon. Thanks.