View Full Version : [Solved] Creating a context menu with mouseout for gridpanel errors

2 Aug 2010, 12:32 PM
I was under the impression that the -debug and all.js files were the same. Someone told me before that "The debug version of the script is not compressed and easier to step through".
I am using a VM to run some older browser versions of IE and Firefox and every now and then I would notice a script error in IE. After playing around with the browser for awhile trying to figure out what it was caused by I found it.

so here is the scenario.
Using a gridPanel that uses the context menu that contains 1 button and when right clicking and moving off the menu and it disappears every now and then when it disappears it causes the error message.

Error message says

Line: 8
Char: 49891
Error: 'style' is null or not an object
Code: 0
Using NotePad++ I was able to locate in the ext-all.js file that position and found return H.style[J]. I needed to find this position so i could look into the ext-all-debug.js file to see what was going on.

However, when searching in the ext-all-debug.js file I could not locate that string or anything that was returning H.style or some other code that was near that area.

2 Aug 2010, 4:24 PM
The minfier renames variables so H is now x or some other one letter variable name and so is J. Try to look for another needle to search with. I don't think this is a good solution, but sometimes I am able to track down things by examining the -debug file and noticing something like ">= 12" and then searching for that with knowledge of the context I learned by reading the -debug file makes the hunt less blood-boiling. Sorry I don't have a quick, easy solution. Just some advice.

2 Aug 2010, 9:14 PM
Run your page using the debug version during development!!!!!!!!!!!!!!

3 Aug 2010, 2:51 AM
Another quick question. I see everyone saying to use the -debug file. Does it provide any additional feedback or am I to look into the actual .js file to decipher whats going on. Just unclear if its a tool or just an easier to read file. Thanks guys

3 Aug 2010, 2:55 AM
From the FAQ:

Stick with ext-all-debug.js during 'development' so that variable names will be meaningful and you can step through the code on errors.

3 Aug 2010, 3:49 AM
3 things.
#1 What editor are you all using to review the -debug file? I have IntelliJ and for it to look over 70k lines of code I have 2-5 second delays in typing responses. Any suggestions on free editor?

#2 If I move the mouse over the context menu buttons that appear then move the mouse out there is no error.
#2 If I move the mouse away from the menu when it opens the error is consistently occuring.
I can not see how this would be my code issue but rather a ExtJS code forgetting to check for undefined issue.

#3 I am failing to how in JavaScript you all keep saying to step through and put breaks into the code. How do you mean? console.info, alerts() what?

3 Aug 2010, 3:52 AM

3 Aug 2010, 4:07 AM
yeah i have firebug. However I still don't see how I am to correct the issue with the mouseout as I am not to change the ExtJS code. I'll look further into this and get back to you all.

3 Aug 2010, 6:59 AM
So for the past few hours I have been trying to figure out what is causing the issue in I.E. and also a dom undefined in Firefox.
In Firefox when using the -debug js if I modify the -debug.js file at around line #6091 to check for the dom

// the area is function getHeight: ....
// modified
h = MATH.max(dom.offsetWidth, hidden ? 0 : dom.clientWidth) || 0;
h = (dom)?MATH.max(dom.offsetWidth, hidden ? 0 : dom.clientWidth) || 0:0;
// In addition to this line of code the function that follows that sets the w in function getWidth I modified in the same fashion

This fixed the error that was occuring in FF which was dom is undefined.

In IE when using the -debug js if I modify the -debug.js file at around line #5980 to check for the style in the function block

return el.style[prop] || ((cs = el.currentStyle) ? cs[prop] : null);
return (!el)?null:el.style[prop] || ((cs = el.currentStyle) ? cs[prop] : null);

Now all I have done is put some checks in to ensure that the object/element or whatever you want to call it exists prior to trying to get at it or some structure within it. This does not change the functionality as far as I can tell only ensures that the item is not undefined.
Q: How do I update the non -debug file since the coding is not the same between the two of them?

3 Aug 2010, 7:48 PM
Don't edit the Ext source files. Period.

First off, the odds that what you've done is actually a valid fix to the core of Ext is virtually zero. Something like that would affect every app out there, and people would be screaming about it. I can almost guarantee that the root issue is somewhere in your code.

Secondly, you'd have to go back in and edit Ext source after every single time you upgraded, which is asking for a world of hurt.

Finally, assuming that there really is a bug in Ext, the appropriate way to address that is to create an override for the offending functionality and apply it after the base Ext library is loaded. Look up the Ext.override function for how to do that.

You really should figure out what the underlying issue is. If you can post a link to a page that demonstrates your issue, I bet someone can help you figure it out. If it really has nothing to do with your code, it should be an easy matter to put together a very simple test page that has just enough code on it to demonstrate the issue in a reproducible way. That would also help to prove that it really is a bug in Ext, if indeed that's the case.

4 Aug 2010, 6:01 AM
:">You are so RIGHT!

Okay I found the culprit. I had a listener to close the context menu but was not escaping out after the x closed the menu.

mouseout: function(thisMenu, thisMenuEvtObj, thisMenuItem){
var mouseX = thisMenuEvtObj.getXY()[0];
var mouseY = thisMenuEvtObj.getXY()[1];
// if the mouse is moved within 1 px or outside of the X bounding area destroy menu
if( mouseX <= (menuX+1) ||
mouseX >= ((menuX-1) + thisMenu.getWidth())
return; // I needed this here to prevent the Y check from occurring. Without it I get the errors.
// if the mouse is moved within 1 px or outside of the Y bounding area destroy menu
if( mouseY <= (menuY+1) ||
mouseY >= ((menuY-1) + thisMenu.getHeight())

Is there an easier way to debug this JavaScript crud? That was just a pain for something so insanely small.

4 Aug 2010, 6:19 AM
For stuff like this where the error bubbles up from internal Ext framework code and is hard to trace, I'll usually set a breakpoint directly on the line within ext-all-debug that's throwing the error (or a conditional breakpoint if it's common code that gets hit a lot). That way when the debugger breaks you can examine the stack trace -- somewhere up the line there is usually application code that is the real culprit and it's usually easy to spot that way.

In this case, since the error was directly related to your menu opening/closing, and I suspect that there's not that much code in your app related to that, I would have definitely started with that code and scrutinized it very heavily. You could also add breakpoints and/or logging into those related methods if you can already narrow it down like that.

BTW, any reason you are destroying the menu, rather than simply hiding it and reusing it later?

4 Aug 2010, 6:30 AM
Not all to sure about how they are handled differently other than the obvious destroy hide.
However if I were to hide it and then close the gridPanel that it is used in will the code destroy it automatically so its not using resources?

4 Aug 2010, 6:39 AM
No, you would have to add a destroy listener to the grid that would destroy the menu.

4 Aug 2010, 6:40 AM
As for your ext-all editing and use of Overrides, you might want to give my blog post on the subject a quick read.


4 Aug 2010, 6:51 AM
No, you would have to add a destroy listener to the grid that would destroy the menu.
Well, I have 4 grids right now loading into tabs in a tab panel.
So would I handle the destruction of the grids and their context menu along with anything from the tab panel listener like this?

destroy: function(){

or would I want to use something like

destroy: function(){

4 Aug 2010, 6:53 AM
As for your ext-all editing and use of Overrides, you might want to give my blog post on the subject a quick read.

One of you showed me this link the other day. I have it in my homepage listing for browser so I can read up on it. But that will have to wait until next week so I can wrap up things this week for an initial code freeze for testing Monday. After Monday I'll be able to look into this as it seems to be the way I need to go.

Thanks for the post.

4 Aug 2010, 7:07 AM
or would I want to use something like

No, I would make each grid responsible for destroying their own context menu.

(maybe even create a custom grid component that has a context menu build-in)