View Full Version : Error after upgrade to ExtJS 4.2.3

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?

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

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?

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.

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!

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

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.


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.


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.

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

// 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 {
// Set the invalidQueue to our filtered queue to excldue loadMasks that cause exceptions
me.invalidQueue = filteredQueue;

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);

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) {

// 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) {

// 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) {

// 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 &&

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) {
if (me.heightModel.calculated) {
me.recoverProp('height', oldProps, oldDirty);
} else if ('height' in oldProps) {

// 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;

11 Jul 2016, 1:07 AM

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 :