ContentPane setContent() complaining about creating duplicate popup widgets

[gid@…]

I have an application that uses a ContentPane? to replace the majority of the content of the site. Recently when upgrading from 0.9-release to the 1.0 beta I'm getting errors like this: "Couldn't create widgets in djRightPane Error: Tried to register widget with id=SearchHelp? but that id is already registered."

This happens when clicking on the various button on the site that switches the content. Basically what's happening is if I call setContent() with the html that contains the SearchHelp? widget, then swap out the content without something else, and then switch back to the first html with the SearchHelp? widget, it's complaining that SearchHelp? is already defined, this seems to make setContent() not quite as useful as it can no longer redefine an widget with the same id.

Shouldn't all the widgets contained in the ContentPane? go out of scope when setContent() is called so they can be redfined by the new html? Was something to this nature changed between 0.9 and 1.0 beta? Or maybe is this a hidden option somewhere that can alter the behavior of redefining widgets?

I realize this is kind of a vague description, I can try to cut up a quick proof of concept if need be. I'm using a custom build from svn r11285 if that makes a difference.

ttrenka reply on the forums: It shouldn't.

One of the main complaints about Dijits between 0.9 and now is that it was not preserving the attributes of HTML nodes passed to it; that was changed so that it would. Odds are, this is a side effect of what you're trying to do.

If you could file a ticket at trac.dojotoolkit.org (log in as guest/guest) with a description of the issue (probably you can just paste this forum post in), that'd be awesome.

[bill]

Yeah, we need a testcase. setContent() calls _setContent() which calls destroyRecursive(), so all the old widgets should be getting destroyed.

[guest]

test case: http://pimpbot.gifpaste.net/~gid/test/contentPane.html

click on any one of the links twice

[bill]

Hi, thanks for the test case. This is basically another manifestation of #4902. Dialog::postCreate() does:

dojo.body().appendChild(this.domNode);

which moves the Dialog's dom node from inside the ContentPane? to outside of it, thus ContentPane::destroyDescendants() doesn't find it.

I guess that's a bad design but not sure how to fix it. Maybe leave some stub pointer node where Dialog.domNode originally was, and/or only move the dialog node while the dialog is being displayed.

As for now it means that ContentPanes? (or anything that derives from them) have problems containing popup widgets.

[guest]

Hi, You guys went way over my head with some of your tech talk so, I'm sorry if this is a dumb question. I'm on .9, but when testing 1.0, I'm seeing the same "already registered" problem as a lot of people. I see you have this ticket scheduled for 1.1. I'm trying to figure out if I should upgrade to 1.0 and go through and try to figure out how I can fix these "already registered" problems or if perhaps these problems might disappear for me sometime around 1.1. I don't know if you need more detail, but does this sound like a safe bet? Or do I need to bite the bullet and figure out how to fix them on my end?

Thanks

[bill]

The problems will disappear for 1.1, and I guess fixing it for 1.0 isn't so easy, so you might want to wait to upgrade. It's up to you.

[bill]

Same root cause as #3300.

[bill]

Looks like this will be fixed by sfoster's conversion of ContentPane to use dojo.html.

[sfoster]

(In [14987]) Refs #5647 Refs #2056 Refs #4980

Refactored _setContent to use dojo.html._ContentSetter * a dojo.html._ContentSetter instance is created and stored on first use (at this._contentSetter) * each subsequent call to _setContent remixes in the config properties * _ContentSetter.empty() is called implicitly when you call this._contentSetter.set() - this will destroy any widgets from a previous set operation - including Menus, Dialogs etc, as the contentSetter.parseResults array keep widget references. This is partly redundant with the destroyDescendents() call in _setContent(), but catches this corner case. It does not fix the case where widgets have been created by the parser from inlined, initial content

* added a few unit tests to the test page to verify this behavior !strict

[bill]

The actual problem in the test case above is fixed, but as Sam said there's still a problem case with widget declarations inlined into the original page. See comments in #2056.

[bill]

See also umbrella ticket #6954.