PDA

View Full Version : [INFOREQ] Set visible fieldset in Chrome 4.1 (ExtJS 3.2)



brk11
9 Apr 2010, 8:58 AM
I have the next situation:


var dwhLoadCbx = new Ext.form.ComboBox({
id: 'dwh-load-'+idx,
hiddenName: 'dwhLoad',
fieldLabel: 'DWH Load',
store: [['yes','<?=_("Terminal Heat Exchanger")?>'],
['no','<?=_("Direct")?>']],
mode: 'local',
selectOnFocus: true,
triggerAction: 'all',
emptyText: '<?=_("Select a configuration...")?>',
forceSelection: true,
allowBlank: false,
hidden: true,
disabled: true,
listeners: {
'select': function() {
numModelFs.setVisible(true);
}
});


var numModelFs = new Ext.form.FieldSet({
title: '<?=_("Numerical Model")?>',
hidden: true,
defaults: {
layout: 'form',
columnWidth: .5,
border: false,
layoutConfig: {
trackLabels: true
}
},
items: [{
items: [k2Coef,frCorr,fraCorr,optEfficiency]
}]
});


Result: the numModelFs fieldset doesn't appear.

This problem affects ExtJS 3.2 using Google Chrome 4.1.249 (in my case). This works fine using IE8 and Firefox 3.6. Using ExtJS 3.1.1 works also fine in Google Chrome.

Jamie Avins
9 Apr 2010, 9:04 AM
So everything is configured hidden, then you do what to make them appear? I think you need to go into a bit more detail.

brk11
10 Apr 2010, 5:45 AM
I'm sorry, I copied a "bad" combobox... but imagine the combobox is not hidden... and enable, too...

brk11
10 Apr 2010, 6:23 AM
Here a full example ready to test:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Solarium</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></meta>
<link rel="stylesheet" type="text/css" href="/ext/resources/css/ext-all.css"></link>
<script type="text/javascript" src="/ext/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="/ext/ext-all-debug.js"></script>
<script type="text/javascript">
// Path to the blank image should point to a valid location on your server
Ext.BLANK_IMAGE_URL = '/ext/resources/images/default/s.gif';

Ext.onReady(function(){
var combo = new Ext.form.ComboBox({
hiddenName: 'cbx',
fieldLabel: 'Combo',
store: [['a','A'],
['b','B']],
mode: 'local',
selectOnFocus: true,
triggerAction: 'all',
emptyText: 'Select something...',
forceSelection: true,
allowBlank: false,
listeners: {
'select': function() {
fieldSet.setVisible(true);
}
}
});

var fieldSet = new Ext.form.FieldSet({
title: 'FieldSet',
hidden: true,
defaults: {
layout: 'form',
columnWidth: .5,
border: false,
layoutConfig: {
trackLabels: true
}
},
items: [{
items: [{
xtype: 'textfield',
fieldLabel: 'TextField'
}]
},{
items: [{
xtype: 'numberfield',
fieldLabel: 'NumberField'
}]
}]
});

var form = new Ext.FormPanel({
border: false,
padding: '10px',
labelWidth: 150,
renderTo: Ext.getBody(),
layoutConfig: {
trackLabels: true
},
defaults: {
autoWidth: true,
border: true,
collapsible: true,
layout: 'column'
},
items: [combo, fieldSet]
});
});
</script>
</head>
<body>
</body>
</html>

evant
10 Apr 2010, 6:51 PM
I tried your example with the SVN build and Chrome 4 and FF look exactly the same.

brk11
11 Apr 2010, 12:01 AM
I understand the SVN build has the lastest changes and fixes... Could this problem be fixed?

I'm running the released version.

BradHarbin
30 Apr 2010, 5:42 AM
I am having the same issue with Chrome 4.1 and fieldset.setVisible(true). IE and FF work just fine. The sample above still behaves the same in both EXT 3.2 and 3.2.1 released versions. The fieldset will not be displayed in Chrome 4.1

brk11
30 Apr 2010, 6:25 AM
Exactly! I've been waiting for ExtJS 3.2.1 and I still have the same problem...

5 May 2010, 1:23 PM
I have the same issue. I do not yet have a solution, but I'm working on it right now.

Apparently the in-line style: "display: none" is applied to the component if it has hidden: true in its config.

component.show() will remove the class, i.e. "x-hide-display", but not the in-line style.

In our tests the same is not true if the component is initially rendered, then hidden, then shown again... that seems to work fine.

I will keep this thread posted with my progress.

brk11
5 May 2010, 11:52 PM
Thank you very much to "join" this thread... It's happening the same in Safari (OSX and Windows).

rushman
7 May 2010, 7:40 AM
same problem on Linux and Chrome 5

UPD: I just filed a support ticket for this problem.

KirkOlson
10 May 2010, 12:12 AM
I'm experiencing the same problem. Showing then hiding works ok, hiding then showing not. A workaround or quickfix would be much appreciated.

Using Chrome 4.1 and Ext 3.2.1. Ext 3.1.x worked fine.

vmadman
10 May 2010, 12:50 PM
We have developed an override that seems to correct the issue.

More testing is needed, but its working for us so far.



// ExtJS 3.2 Webkit Hidden Component Fix
Ext.override(Ext.Component, {
onShow : function(){

this.getVisibilityEl().removeClass('x-hide-' + this.hideMode);

if(Ext.isWebKit) {
this.getVisibilityEl().show();
}
},
onHide : function(){

this.getVisibilityEl().addClass('x-hide-' + this.hideMode);

if(Ext.isWebKit) {
this.getVisibilityEl().hide();
}
}
});


Thanks,
Luke

dtex-lab
11 May 2010, 12:26 AM
I believe it is the same of my issue : http://www.extjs.com/forum/showthread.php?98812

Luke's override resolve also it

kbanks
8 Jun 2010, 11:43 AM
First, the fix:




Ext.Element.prototype.__getStyle = Ext.Element.prototype.getStyle;
Ext.Element.prototype.getStyle = function(prop) {
if (Ext.isWebKit && /margin/i.test(prop) && /right/i.test(prop)){
var old = this.dom.style.display;
var val = this.__getStyle(prop);
this.dom.style.display = old_display_style;
return val;
} else {
return this.__getStyle(prop);
}
};
And now a brief discussion



function(prop){
var el = this.dom,
v,
cs,
out,
display,
wk = Ext.isWebKit,
display;

if(el == document){
return null;
}
prop = chkCache(prop);
// Fix bug caused by this: https://bugs.webkit.org/show_bug.cgi?id=13343
if(wk && /marginRight/.test(prop)){
display = this.getStyle('display');
el.style.display = 'inline-block';
}
out = (v = el.style[prop]) ? v :
(cs = view.getComputedStyle(el, "")) ? cs[prop] : null;

// Webkit returns rgb values for transparent.
if(wk){
if(out == 'rgba(0, 0, 0, 0)'){
out = 'transparent';
}else if(display){
el.style.display = display;
}
}
return out;
}
(from http://www.extjs.com/deploy/ext/docs/source/Element.style.html#method-Ext.Element-getStyle)

Above is the offending ExtJS code. It was written to address a specific webkit bug and, unfortunately, introduced another. To see more about the webkit bug it attempted to fix, see the link in the code.

The ExtJS code above is likely to break whenever the following TWO conditions are true:
1. The code is run on a webkit browser.
2. The getStyle function tries to compute a "marginRight" property (happens a lot).

Looking carefully at the code, you'll see that whenever this function attempts to compute the "marginRight" value, it will also SET the style.display property to the computed display value of the element.

The author intended to set the style.marginRight property to 'inline-block' only for the lifetime of the function, using the display variable to save and restore the current value.

Sounds fine, but the author made at least one major error. The computed style value is often different from the actual style value, because a computed style will ALWAYS have a (computed) value, whereas accessing the value as element.style.property will only have a value if the value has been explicitly set. The ExtJS assigns the computed value of 'none' to the style.display property, which is equivalent in specificity to inline style declarations, which outweigh !important rules per the CSS definition.

So, any time ExtJS attempt to compute the marginRight value of a hidden component on webkit, it also explicitly sets the style.display property to 'none'. Later, when show() is called, ExtJS removes the CSS rule x-hide-display, but this leaves the explicitly set 'none' value on the style.display property. This is why show() appears to have no affect.

The workaround published calls show() on the containing Ext.Element, which called Ext.Element.prototype.show(), which will usually set the style.display property to 'block', but not always, specifically if the visibilityMode is set to something other than 'display'.

My workaround does what the author intended, by wrapping the getStyle function, saving the style.display value for the affected use case, and restoring it afterwards, making the getStyle function side-effect free.



2.

max_zoro
16 Jan 2013, 4:56 AM
Any updates guys?