Opened 10 years ago

Closed 10 years ago

#9100 closed defect (fixed)

'already called' error when setting href for ContentPane after calling destroyRecursive

Reported by: Nick Fenwick Owned by: bill
Priority: high Milestone: 1.4
Component: DojoX Widgets Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:

Description

platform: Firefox 3.0.6, CentOS 5.3. dojo 1.2 from googleapis.com but also 1.3.0 rc 2 tested.

I'm rather confused by this one, being a bit of a dojo newbie. It may be irrelevant as it seems to be fixed in the final 1.3.0 release.

I've boiled it down to a simple pair of test pages. One is the main page, and it loads the second page into a ContentPane?. There are two buttons; each sets the 'href' attr on the ContentPane?, but the second calls destroyRecursive() on the ContentPane? widget before doing so.

source.zip contains:

simple_alreadycalled1.html - the master page, with the javascript
simple_alreadycalled2.html - a very simple html snippet

To reproduce the behaviour, load simple_alreadycalled1.html, click the first button, then click the second. The full error that firebug shows is "[Exception... "'Error: already called!' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no]".

I can click the first button repeatedly with no problems, so a simple 'href' is fine. It's only when using the second button that the problem appears. I pause a second or two between clicks, so I don't think in-flight cancellation issues are relevant.

It seems that the call to destroyRecursive() causes the error to be thrown, before the attr('href',..) is even attempted by the second button.

screenshots.zip contains two sets of screens, one done on a plain Firefox profile, the other on a profile with lots of addons loaded including firebug. Both sets display the problem, the plain one is harder to spot because the error doesn't seem to be printed to the console; however, the ContentPane? fails to refresh, so I presume the exception has occurred and isn't being reported.

The same behaviour seems to happen in Opera (9.62).

I've switched to the 1.3.0 release in the last hour, and the problem seems to have gone away. No errors occur and the setting of 'href' succeeds.

Attachments (2)

source.zip (1014 bytes) - added by Nick Fenwick 10 years ago.
the two source html files demonstrating the problem
screenshots.zip (207.2 KB) - added by Nick Fenwick 10 years ago.
some png files of the problem, in two different firefox profiles

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by Nick Fenwick

Attachment: source.zip added

the two source html files demonstrating the problem

Changed 10 years ago by Nick Fenwick

Attachment: screenshots.zip added

some png files of the problem, in two different firefox profiles

comment:1 Changed 10 years ago by bill

Happens for me on 1.3 too, pushing the first button once and the second button twice. FF3.0.8 mac.

comment:2 Changed 10 years ago by bill

Milestone: tbd1.4
Owner: changed from dante to bill

The error about "already called" is coming from the onUnloadDeferred (a read only attribute of dojox.layout.ContentPane). There needs to be a new onUnloadDeferred object created every time the page is unloaded, since Deferred's only work for a single notification. But with the current code that doesn't happen.

Currently, the "_setUpDeferreds" method creates two Deferred objects, one for load and one for unload. _setupDeferreds() is called from refresh():

refresh: function(){
	// summary:
	//		Sets up for a xhrLoad, load is deferred until widget is showing
	var defObj = this._setUpDeferreds();
	this.inherited(arguments);
	return defObj;	// dojox.layout.ContentPane.DeferredHandle
}

Anyway, the dojox.layout.ContentPane code could stand for a rewrite. I'll work on it. Previously I was thinking of moving the deferred object creation into dijit.layout.ContentPane, to avoid some nasty function overriding in dojox.layout.ContentPane, and this might be a good chance to do that.

comment:3 Changed 10 years ago by Nick Fenwick

Sorry to hear it still seems to be in 1.3.0. I haven't seen recurrence yet, but I've had little time for work this week. Wondered if this bug is related to http://bugs.dojotoolkit.org/ticket/7801?

Sounds like you're onto something, anyway :) Hope this is a fruitful bug report.

comment:4 Changed 10 years ago by bill

Resolution: fixed
Status: newclosed

(In [17524]) Refactor dijit.layout.ContentPane? and dojox.layout.ContentPane? so that attr('href', ...) returns a dojo.Deferred to monitor the load status. Previously dijit.layout.ContentPane? attr('href') didn't return anything, and dojox.layout.ContentPane? returned a custom Object to register callbacks to monitor both load and unload.

The reason for the switch to use a standard dojo.Deferred is that monitoring pane unload for a specific attr('href', ...) call is uncommon, and can still be achieved by creating a listener on ContentPane?.onUnload that disconnects itself after firing.

Fixes #9100 !strict

Note: See TracTickets for help on using tickets.