Opened 9 years ago

Closed 8 years ago

#17329 closed enhancement (wontfix)

dijit.Dialog blocking tinyMCE dialogs (tinyMCE 4 Editor inside dijit.Dialog)

Reported by: m2b Owned by:
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.9.1
Keywords: Cc:
Blocked By: Blocking:


It seems that dijit.Dialog blocks input elements in tinyMCE 4 dialog windows if the tinyMCE4 Editor is placed inside the dijit.Dialog element. According to tinyMCE 4 bug tracker ( the problem could maybe resolved if dijit.Dialog would allow tinyMCE dialogs to gain selection/focus. As this is a dijit.Dialog bug and not a tinyMCE 4 bug, I have reported this here. I hope there is a way to give tinyMCE 4 focus/selection like a solution for jQuery UI dialog is already available ( Reproduction: put a tinyMCE dialog into a dijit.Dialog and try to add a link->result: you cannot type anything in the link dialog input fields.

Attachments (2)

editor.html (1010 bytes) - added by bill 8 years ago.
test case. click open to show the editor, and then the link icon to show the link dialog
editor_workaround.html (899 bytes) - added by bill 8 years ago.

Download all attachments as: .zip

Change History (3)

Changed 8 years ago by bill

Attachment: editor.html added

test case. click open to show the editor, and then the link icon to show the link dialog

comment:1 Changed 8 years ago by bill

Resolution: wontfix
Status: newclosed

In the future please attach a test case to your tickets using the "Attach file" button.

It's true that TinyMCE Dialogs don't work when spawned from a dijit/Dialog. It's because:

  1. Dijit isn't aware of TinyMCE's dialog framework
  2. To address complaints from the a11y community like #15370, dijit/Dialog is very aggressive about restoring focus whenever it leaves the dijit/Dialog unexpectedly.

I'm speaking specifically about this code:

// If focus was accidentally removed from the dialog, such as if the user clicked a blank
// area of the screen, or clicked the browser's address bar and then tabbed into the page,
// then refocus.   Won't do anything if focus was removed because the Dialog was closed, or
// because a new Dialog popped up on top of the old one, or when focus moves to popups"curNode", function(attr, oldNode, node){
	// Note: if no dialogs, ds.length==1 but ds[ds.length-1].dialog is null
	var topDialog = ds[ds.length - 1].dialog;

	// If a node was focused, and there's a Dialog currently showing, and not in the process of fading out...
	// Ignore focus events on other document though because it's likely an Editor inside of the Dialog.
	if(node && topDialog && !topDialog._fadeOutDeferred && node.ownerDocument == topDialog.ownerDocument){
		// If the node that was focused is inside the dialog or in a popup, even a context menu that isn't
		// technically a descendant of the the dialog, don't do anything.
			if(node == topDialog.domNode || domClass.contains(node, "dijitPopup")){ return; }
		}while(node = node.parentNode);

		// Otherwise, return focus to the dialog.  Use a delay to avoid confusing dijit/focus code's
		// own tracking of focus.

For now it doesn't seem feasible to fix this limitation, but you can workaround it in various ways, such as redefining Dialog.focus:

Dialog.prototype.focus = function(){};

I'll attach a test file with that workaround.

You could also do a more complex workaround that only disabled the focus method on the dialog w/the Editor, etc.

Changed 8 years ago by bill

Attachment: editor_workaround.html added
Note: See TracTickets for help on using tickets.