tree bug: firebug gives "bd has no properties"

[glauff]

Hello Support Team,

don't know if this was reported before, but my searches inside the forum gave me no result. If this ist solved, sorry for opening a thread.

Now to the issue I found:

When I quickly click several times on different leafs before the page has entirely loaded firebug gives me this error:

bd has no properties
EventManager()ext-all.js (line 17)
Observable()ext-all.js (line 15)
EventManager()ext-all.js (line 17)
[Break on this error] Ext.EventManager=function(){var _1,_2,_3=false;var _4,_5,_6,_7;var E=Ext.lib.Eve...

bd has no properties
(no name)()ext-all-debug.js (line 1667)
fire()ext-all-debug.js (line 1387)
fireDocReady()ext-all-debug.js (line 1416)
[Break on this error] bd.addClass(cls);

You can reproduce this easily on the online documentation. Just click on the nodes like a madman.

Gaetan

[neongrau]

you say: "before the page has entirely loaded"

i guess you AREN'T making sure the previous request gets properly processed or at least cancelled.

[glauff]

Thx for your reply.

Don't think that this is the problem, because the online documentation has the same problem and I didn't implemented it. I think that it has something to with the page load. If you use the tree with an iframe scenario you have the same problem. If the details page load takes more time you get this error and the tree is not reloaded.
The Requests are properly handled but server response takes a longer time, a second or two.

But if you know a good woraround, suggestions are always welcome

[neongrau]

checking for the behavior with the documentation confirms my first suspicion but it seems there isn't much you could do to fix it.

the error doesn't come from the tree or becaue of just a longer response from the server but because of the page in your iframe, or more precisely:

you request a new page in an iframe that itself uses Ext widgets and before it's fully done you interrupt the rendering randomly somewhere you can't possibly control.

try triggering the bug by clicking just back and forth between the api docs (whithin the "API Reference" node) that just have plain html, you won't see it there. then try again by switching back and forth at the live "Examples and Demos" nodes and you'll see the error after just a few clicks.

and in fact i do know a good workaround: ditch iframes totally! after all that's what JSON-Views,Templates and the UpdateManager were made for.

for me iframes are so web1.5'ish

[glauff]

Yes you're right with the Iframes. And any new application shoulb be built without i think
But we have a ton of applications here, running this caveman's approach. If I tell the developers that they have to implement a completly new interface just to use Jack's fantastic new tree component, I think they will tar and feather me.
Anyway, thanks for taking the time to track this down.
Perhaps there's another way to fix it.
I'll investigate a little bit what's happening exactly.

Thx
Gaetan

[neongrau]

even for the existing stuff you don't need iframes. the updatemanager of a contentpanel can load any page and execute the JS code inside.

no need to rewrite the existing stuff,
so no need to be afraid of getting tarred and feathered

[JeffHowden]

If I tell the developers that they have to implement a completly new interface just to use Jack's fantastic new tree component, I think they will tar and feather me.

You do realize that the problem you're describing with the docs has nothing to do with the TreePanel, right? The docs don't use an Ext widget to render the links on the left.

More importantly, rapidly loading, unloading, and loading an iframe isn't standard user behavior. Even if it were, 99.9% of your users aren't going to have JavaScript error reporting turned on. Most importantly, this error doesn't keep things from functioning. It's simply a timing issue of the browser trying to parse something as it's being told to unload it to answer another request.

[glauff]

More importantly, rapidly loading, unloading, and loading an iframe isn't standard user behavior. Even if it were, 99.9% of your users aren't going to have JavaScript error reporting turned on.

I included ext in one of our applications, and the first thing that happened was that someone reported me this "bug". In Firebug you just get a message in the console but in IE you get an ugly message box saying that something went "horribly" wrong :-)
My experience is to never underestimate what users a capable of. And if you implement enterprise class applications and only one user in the whole world is reporting that he gets a javascript error because he/she by accident has turned debugging on in the browser, the company you work for is giving you hell

So for now I'm just experimenting with ext and if the problem is avoidable if I use the UpdateManager, so be it.
Ext is by far the best thing that happened over the last few years. I have to move and see things, to choose neongrau's words, more web2.0ish not web1.5ish.

Gaetan

[jack.slocum]

While I agree this is strange behavior, I have added a check to the onReady function to make sure bd exists. This should squash any errors.

[glauff]

That's great news.
Thank you very much Jack !