View Full Version : floatParent changed?

5 Jan 2012, 4:16 AM
Something changed wrt floatParent's?

I have a static method in my menu class that I use to determine its ultimate floatParent, which I can then use component query to get the owning grid, say.

* Retrieves the ultimate float parent for the specified menu.
* In most cases this will be the button that was used to launch the menu.
* @param {Object} menu The menu whose float parent to determine.
* @return {Object} The float parent control for the menu, or undefined if not found.
getFloatParent: function(menu) {
var floatParent = undefined;

if (menu) {
// Go up until we do not have a parentMenu, in case we are on a menus sub-menu.
var parentMenu = menu;
while (parentMenu.parentMenu) {
parentMenu = parentMenu.parentMenu;

floatParent = parentMenu.floatParent;

return floatParent;

I'm seeing floatParent always being undefined, despite floating being true.

Edit: I can probably work around using ownerButton, but that won't work for context menus off grids and trees for instance.

5 Jan 2012, 9:25 AM
May need to post a bug.

6 Jan 2012, 1:13 AM
Oh right, what is this forum for then if not bugs?

6 Jan 2012, 3:14 AM
I've also seen floatParent undefined in LoadMask.afterRender.

It's not always though, otherwise nothing would be masking... hmm...

Edit: Correction, floatParent is not undefined in afterRender, it's an Ext.Layer that has no getContentTarget method.

Getting it when launching a particular form; will try and figure out what's up.

After getting the error the list dropdown for a combobox on the form renders very oddly; also once the error has occurred no other context menus will work on my tree until I reload the page. Gives endless owner.isDescendantOf is not a function errors in Firebug.

Ah, when that occurs the owner is an Ext.Layer as well, which has no isDescendentOf method.

6 Jan 2012, 6:08 AM
Looking at this a bit more, Ext.Layer inherits from Element, but getContentTarget is a method in Component, and overridden in Panel and FieldSet it seems.

This says to me that there are some core issues with the 4.1 codebase that no amount of my tinkering and investigation is going to solve or workaround. That would also explain why I keep hitting floatParent is undefined, or floatParent.method is not a function issues in many different places.

Therefore I'm going to have to knock it on the head for now, and continue with 4.0.7 until there's another 4.1 version to look at, which I hope will be more complete and ready for evaluation.
I simply can't upgrade to this version and pass the system onto our testers, it's not even close in my opinion.


27 Jan 2012, 10:37 PM
There seems to be a dedicated thread for posting bugs: http://www.sencha.com/forum/forumdisplay.php?80-Ext-Bugs

21 Feb 2012, 8:50 AM
From here (http://www.sencha.com/forum/showthread.php?182234-Ext-4.0.x-vs-4.1&p=738796&viewfull=1#post738796):

There is only bug/performance changes now, no new features or API changes.


Still no responses to my posts in this beta forum concerning this floatParent issue that made me give up on 4.1, and on the clientId use in models that caused a lot of issues.

I'm still reluctant to spend the time upgrading to 4.1 to be honest, the lack of communication is disturbing.

22 Feb 2012, 2:14 AM
OK, looking at the code in post 1...

Going "upwards" can be quite difficult depending on the relationship. What does "up" mean?

For Menus, parentMenu is the correct pointer until you get to the top Menu.

Then where?

Well, if it's popped up from a Button, there's no ownerCt, no parentMenu, it's ownerButton.

Sounds inconsistent, but the relationships are different. ownertCt is for real Container parents, floatParent is for floaters. parentMenu for Menus, and ownerButton for the top Menu (if initiated from a button)

If it's a context menu, there is no upward link. How could there be? Your code created a Menu and showed it, and that's it. If you need there to be some upwards relationship, you must provide it. You could poke in an ownerCt.

Then simply use the up() method which traverses the class's known upward links.

The up() method uses the getBubbleTarget implementation to find an upward link (bubbling events go upwards, and need that upward link)

Menu's implementation looks at all 3 possibilities.

AbstractComponent's just looks at ownerCt.

So maybe add a pseudo:

// Matches the topmost Component going up the up() axis.
// Pseudos usually test an array of children. If we are testing on up(), there'll only be one.
Ext.ComponentQuery.pseudos.top = function(items) {
if (!items[0].getBubbleTarget()) {
return true;


topMost = myMenu.up(':top');

Off the cuff code, no testing, YMMV etc... But you're smart enough to fix it all up! ;)

22 Feb 2012, 2:17 AM
I think Ext.util.Floater needs a getBubbleTartget implementation which returns this.floatParent so that up() will work on Windows...

22 Feb 2012, 2:21 AM
findParentBy obviously also needs to use getBubbleTarget to go upwards in the correct way for whatever object is using it...

A few issues here. I'll create a ticket to encompass all these issues.

22 Feb 2012, 2:27 AM
OK, I have EXTJSIV-5416 which covers the topic of "upward" links and how to reconcile all methods which need an upward link.

22 Feb 2012, 3:06 AM
Excellent, thanks Nige :)

I understand your point about the ownerCt, ownerButton, etc.
I'm normally using my getFloatParent to get at the button that's docked to a grid panel from the buttons child menu; can then go from the button up to the grid. Can tweak as needed for this case.

What about the issues I'm seeing with Ext.Layer being treated like a component (posts 4 & 5 in this thread)?
That was more worrying, and was caused me to give up on 4.1 until a later version was posted...

I've almost got through my current workload so should find some time to try the upgrade to 4.1 again soon. Guessing I should try beta 2, or is there a new drop imminent?
Would hope to be able to get it running before you drop the final release in case have issues; it's a very large application so would expect to get some...


22 Feb 2012, 5:11 AM
A Layer should never be treated like a Component.

LoadMask can either be asked to use an Element or a Component as its "target", but it should treat each differently.

If anything is getting confused between a Layer (which is just a fancy Element), and a Component, then something's been switched, and it's a separate bug issue.

Beta 3 is being stabilized now, so no possibly destabilizing bug fixes are being allowed in.

29 Feb 2012, 7:32 AM
OK, I have fixed the upward axis for Floating components. The upward axis follows ownerCt if available, or floatParent.

Menus already have a getBubbleTarget implementation which tries

this.parentMenu || this.ownerButton || this.callParent(arguments);

So if you have a menu of a grid column, you can find its grid by using CQ:


1 Mar 2012, 1:05 AM
Excellent, thanks.