Community
Participate
Working Groups
This appears to be a problem introduced by dojo 1.6.1 From navigator, choose the new folder/new file link OR From repositories, choose the clone link, etc.... If you dismiss the dialog with OK or enter, you can open the dialog again. But if you dismiss the dialog with Esc or the close box, the dialog is broken until page reload. I see this error in the console on FF4 exception in animation handler for: beforeBegin dojo.j...ssed.js (line 10907) [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLInputElement.selectionStart]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://localhost:8080/org.dojotoolkit/orion/orion.js.uncompressed.js :: <TOP_LEVEL> :: line 4783" data: no] console.error(e); dojo.j...ssed.js (line 10908) _t.curve is undefined [Break On This Error] var value = _t.curve.getValue(_t._getStep());
This is only on FF4. Chrome and IE are fine.
closest dojo bug I've found so far, blows up in similar place, i'm not convinced this is the exact cause of our problem but making a note to look later. http://bugs.dojotoolkit.org/ticket/12534
Mark fixed a similar FF-only problem in bug 339487. I wonder if we are being burned by timing changes in the way dialogs are destroyed in 1.6. See http://bugs.dojotoolkit.org/ticket/12436 I'm also generally worried about all the copied dialog code that we have. It seems like so much infrastructure to throw up a dialog. Are we widget-izing every single dialog in order to take advantage of templating? The downside seems to be that we would have to fix this bug in every dialog (in the same way that the fix for bug 339487 is copied everywhere).
*** Bug 345394 has been marked as a duplicate of this bug. ***
The dialogs were working around dojo bug 10654, involving dialogs that are launched from an unfocusable dom node (such as our command links). That bug was supposedly fixed in 1.6, but apparently between that fix and the change in timing of dialog onHide, you can still get the problem. This is now documented in dojo bug 12534. To fix the problem for us, I did the following: - removed workarounds for bug 10654 (no longer necessary) - added a workaround for bug 12534 - drank some dijit KoolAid and created an _OrionDialogMixin.js which will keep all our dojo workarounds in one place - modified existing dialogs to use the mixin and removed the old workarounds. What made this hard to figure out is that whether the dialog had the problem depended on how it was launched. Dialogs launched from command links had the problem, while dialogs launched from menus did not. It appears that 1.7 will fix this in a more robust way, and we may be able to remove the workarounds from _OrionDialogMixin.
