Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345292

Summary:	[client] [FF4] escaping out of a dialog breaks it until page reload
Product:	[ECD] Orion	Reporter:	Susan McCourt <susan>
Component:	Client	Assignee:	Susan McCourt <susan>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	P3	CC:	malgorzata.tomczyk, mamacdon
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Susan McCourt

2011-05-10 12:18:14 EDT

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());

Comment 1 Susan McCourt

2011-05-10 12:20:33 EDT

This is only on FF4.  Chrome and IE are fine.

Comment 2 Susan McCourt

2011-05-10 12:40:37 EDT

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

Comment 3 Susan McCourt

2011-05-10 13:04:38 EDT

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).

Comment 4 Susan McCourt

2011-05-11 12:48:04 EDT

*** Bug 345394 has been marked as a duplicate of this bug. ***

Comment 5 Susan McCourt

2011-05-24 14:35:10 EDT

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.