PDA

View Full Version : Error after upgrade to ExtJS 4.2.3



alexvazquez
5 Sep 2014, 7:08 PM
I have downloaded ExtJS 4.2.3 version and I did my Sencha CMD upgrade process successfully.

Then I tried to run my application and I get the following error in my console:


Uncaught TypeError: Cannot read property 'isItemBoxParent' of undefined

This error comes from:

Ext.layout.ContextItem in the following line:


if (ownerCtContext) {
me.ownerCtContext = ownerCtContext;
me.isBoxParent = target.ownerLayout.isItemBoxParent(me);
} else {
me.isTopLevel = true; // this is used by initAnimation...
}


Any clue how to solve this? The application was working perfect in 4.2.1.

I just debug my application in the line:

me.isBoxParent = target.ownerLayout.isItemBoxParent(me);

and found that this error happens always when then
target is a loading mask:

componentCls: "x-component"
componentLayout: constructor
container: constructor
el: constructor
events: Object
external: false
frame: undefined
hasListeners: statics.prepareClass.HasListeners
hidden: false
hierarchyState: Object
id: "loadmask-1111"
initialCls: "x-mask-msg"





I commented two masks and the error disappear until a new mask is loaded. So seems is a BUG in this version 4.2.3

Appreciate any help.

Gary Schlosberg
8 Sep 2014, 4:11 PM
I haven't heard of that kind of error and couldn't find any similar reports. Any chance you can post a test case which reproduces the issue?
https://fiddle.sencha.com/#home

alexvazquez
8 Sep 2014, 4:21 PM
Hi Gary, I just create a ticket in my Support Portal and upload there a Test Case with all the instructions on how to reproduce the error. For your reference the Ticket # is 18962 and is tracked by Greg Barry. Hope can find the issue. Appreciate

wiilco
15 Sep 2014, 8:01 AM
I am also experiencing this issue on Ext JS 4.2.3 with a loading mask attached to a container. Has this issue been resolved?

infotacto
15 Sep 2014, 8:10 AM
Hi, yes I post the issue in my Support Portal with a test case and yes, they registered this as an issue: The bug id is EXTJS-15054. Don't know if this has been fixed yet, also don't know where to search if a bug has been fixed :). But if you know let me know please.

wiilco
15 Sep 2014, 10:54 PM
Thanks for your reply. I think the bug tracker is internal to sencha, so not visible for us. Anyways, could you give a heads up once the issue is resolved? Thanks!

renatorro
17 Sep 2014, 9:56 AM
I am having the same issue.Sadly i will have to downgrade to 4.2.2...

greg.barry
17 Sep 2014, 1:51 PM
There appears to be a timing issue that has been introduced. For the time being, try using "boxready" instead of render.

Thanks!
Greg

renatorro
17 Sep 2014, 6:02 PM
I was using afterrender.
I will try the boxready to see if this works, but this shouldn't be necessary right?
If i got any success i will post here.

Regards

matej.kenda
23 Sep 2014, 4:18 AM
The same problem appeared in plugin ext_ux_pdf_panel. LoadMask was created in afterrender.Replacing afterrender with boxready solved the problem in that plugin.

foex
2 Oct 2014, 3:42 AM
Here's a dirty workaround which I used to solve the issue in my case


Ext.define('Ext.layout.Context.patch', {
override: 'Ext.layout.Context',


queueInvalidate: function(item, options) {
var me = this,
comp, item, invalidQueue,
filteredQueue = [],
i, queueLength;


// Call the parent method we are overriding
me.callParent(arguments);


// MJN Change: we want to ignore Load Masks with no ownerLayout setting


invalidQueue = me.invalidQueue;
queueLength = invalidQueue.length;


for (i = 0; i < queueLength; i++) {
comp = invalidQueue[i];
item = comp.item;
if (item && item.id.indexOf("loadmask-") > -1 && !item.ownerLayout) {
//apex.debug("ignoring " + item.$className + " from layout refresh");
} else {
filteredQueue.push(comp);
}
}
// Set the invalidQueue to our filtered queue to excldue loadMasks that cause exceptions
me.invalidQueue = filteredQueue;
}
});

raphael.franchet
21 Jan 2015, 1:23 AM
Personally, I temporarily have overridden the whole method to fix the problem.
Of course, when upgrading to the future 4.2.4, I will have to check and remove the patch

You will see I just replaced:

me.isBoxParent = target.ownerLayout.isItemBoxParent(me);
by

me.isBoxParent = target.ownerLayout ? target.ownerLayout.isItemBoxParent(me) : false; // BUG FIX HERE





Ext.define("Ametys.layout.ContextItem", {
override: 'Ext.layout.ContextItem',

// FIX http://www.sencha.com/forum/showthread.php?291412-Error-after-upgrade-to-ExtJS-4.2.3
init: function (full, options) {
var me = this,
oldProps = me.props,
oldDirty = me.dirty,
ownerCtContext = me.ownerCtContext,
ownerLayout = me.target.ownerLayout,
firstTime = !me.state,
ret = full || firstTime,
children, i, n, ownerCt, sizeModel, target,
oldHeightModel = me.heightModel,
oldWidthModel = me.widthModel,
newHeightModel, newWidthModel,
remainingCount = 0;


me.dirty = me.invalid = false;
me.props = {};


// Reset the number of child dimensions since the children will add their part:
me.remainingChildDimensions = 0;


if (me.boxChildren) {
me.boxChildren.length = 0; // keep array (more GC friendly)
}


if (!firstTime) {
me.clearAllBlocks('blocks');
me.clearAllBlocks('domBlocks');
}


// For Element wrappers, we are done...
if (!me.wrapsComponent) {
return ret;
}


// From here on, we are only concerned with Component wrappers...
target = me.target;
me.state = {}; // only Component wrappers need a "state"


if (firstTime) {
// This must occur before we proceed since it can do many things (like add
// child items perhaps):
if (target.beforeLayout && target.beforeLayout !== Ext.emptyFn) {
target.beforeLayout();
}


// Determine the ownerCtContext if we aren't given one. Normally the firstTime
// we meet a component is before the context is run, but it is possible for
// components to be added to a run that is already in progress. If so, we have
// to lookup the ownerCtContext since the odds are very high that the new
// component is a child of something already in the run. It is currently
// unsupported to drag in the owner of a running component (needs testing).
if (!ownerCtContext && (ownerCt = target.ownerCt)) {
ownerCtContext = me.context.items[ownerCt.el.id];
}


if (ownerCtContext) {
me.ownerCtContext = ownerCtContext;
me.isBoxParent = target.ownerLayout ? target.ownerLayout.isItemBoxParent(me) : false; // BUG FIX HERE
} else {
me.isTopLevel = true; // this is used by initAnimation...
}


me.frameBodyContext = me.getEl('frameBody');
} else {
ownerCtContext = me.ownerCtContext;


// In theory (though untested), this flag can change on-the-fly...
me.isTopLevel = !ownerCtContext;


// Init the children element items since they may have dirty state (no need to
// do this the firstTime).
children = me.children;
for (i = 0, n = children.length; i < n; ++i) {
children[i].init(true);
}
}


// We need to know how we will determine content size: containers can look at the
// results of their items but non-containers or item-less containers with just raw
// markup need to be measured in the DOM:
me.hasRawContent = !(target.isContainer && target.items.items.length > 0);


if (full) {
// We must null these out or getSizeModel will assume they are the correct,
// dynamic size model and return them (the previous dynamic sizeModel).
me.widthModel = me.heightModel = null;
sizeModel = target.getSizeModel(ownerCtContext &&
ownerCtContext.widthModel.pairsByHeightOrdinal[ownerCtContext.heightModel.ordinal]);


if (firstTime) {
me.sizeModel = sizeModel;
}


me.widthModel = sizeModel.width;
me.heightModel = sizeModel.height;


// if we are a container child (e.g., not a docked item), and this is a full
// init, that means our parent was invalidated, and therefore both our width
// and our height are included in remainingChildDimensions
if (ownerCtContext && !me.isComponentChild) {
ownerCtContext.remainingChildDimensions += 2;
}
} else if (oldProps) {
// these are almost always calculated by the ownerCt (we might need to track
// this at some point more carefully):
me.recoverProp('x', oldProps, oldDirty);
me.recoverProp('y', oldProps, oldDirty);

// if these are calculated by the ownerCt, don't trash them:
if (me.widthModel.calculated) {
me.recoverProp('width', oldProps, oldDirty);
} else if ('width' in oldProps) {
++remainingCount;
}
if (me.heightModel.calculated) {
me.recoverProp('height', oldProps, oldDirty);
} else if ('height' in oldProps) {
++remainingCount;
}

// if we are a container child and this is not a full init, that means our
// parent was not invalidated and therefore only the dimensions that were
// set last time and removed from remainingChildDimensions last time, need to
// be added back to remainingChildDimensions. This only needs to happen for
// properties that we don't recover above (model=calculated)
if (ownerCtContext && !me.isComponentChild) {
ownerCtContext.remainingChildDimensions += remainingCount;
}
}


if (oldProps && ownerLayout && ownerLayout.manageMargins) {
me.recoverProp('margin-top', oldProps, oldDirty);
me.recoverProp('margin-right', oldProps, oldDirty);
me.recoverProp('margin-bottom', oldProps, oldDirty);
me.recoverProp('margin-left', oldProps, oldDirty);
}


// Process any invalidate options present. These can only come from explicit calls
// to the invalidate() method.
if (options) {
// Consider a container box with wrapping text. If the box is made wider, the
// text will take up less height (until there is no more wrapping). Conversely,
// if the box is made narrower, the height starts to increase due to wrapping.
//
// Imposing a minWidth constraint would increase the width. This may decrease
// the height. If the box is shrinkWrap, however, the width will already be
// such that there is no wrapping, so the height will not further decrease.
// Since the height will also not increase if we widen the box, there is no
// problem simultaneously imposing a minHeight or maxHeight constraint.
//
// When we impose as maxWidth constraint, however, we are shrinking the box
// which may increase the height. If we are imposing a maxHeight constraint,
// that is fine because a further increased height will still need to be
// constrained. But if we are imposing a minHeight constraint, we cannot know
// whether the increase in height due to wrapping will be greater than the
// minHeight. If we impose a minHeight constraint at the same time, then, we
// could easily be locking in the wrong height.
//
// It is important to note that this logic applies to simultaneously *adding*
// both a maxWidth and a minHeight constraint. It is perfectly fine to have
// a state with both constraints, but we cannot add them both at once.
newHeightModel = options.heightModel;
newWidthModel = options.widthModel;
if (newWidthModel && newHeightModel && oldWidthModel && oldHeightModel) {
if (oldWidthModel.shrinkWrap && oldHeightModel.shrinkWrap) {
if (newWidthModel.constrainedMax && newHeightModel.constrainedMin) {
newHeightModel = null;
}
}
}


// Apply size model updates (if any) and state updates (if any).
if (newWidthModel) {
me.widthModel = newWidthModel;
}
if (newHeightModel) {
me.heightModel = newHeightModel;
}


if (options.state) {
Ext.apply(me.state, options.state);
}
}


return ret;
},
});

xavier.folch
11 Jul 2016, 1:07 AM
Hi,

I met the same problem when upgrading from 4.2.2 to 4.2.5.
In the controller changing 'render' to 'boxready' did the trick but it is not a nice solution.

I found another problem linked to the Loading Mask as well :
https://www.sencha.com/forum/showthread.php?312027-Ext-4.2.5-LoadingMask-and-Ext.tab.Panel&p=1139554#post1139554